This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
>>>>> "felix" == felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes: felix> It's absolutely unnecessary to specify which C-level forms are macros, felix> or which are functions. Leave that to the implementors, and allow all felix> the forms to be macros instead. That certainly was our intention. Do we overspecify anything by saying "Note that most functionality on the C side is implemented by macros."? felix> Moreover, it might be helpful to change the felix> references of "scheme_define_exported_binding" and felix> "scheme_enter_pointer" to uppercase, since obviously the felix> macro-versions are meant here. That's a typo pure and simple. Will get fixed. Thanks for pointing it out! felix> Defining bindings from C is allowed, and the SRFI-document felix> specifically points out the C init-code may run before Scheme felix> init-code. Yet, SCHEME_DEFINE_EXPORTED_BINDING may GC, even felix> before Scheme init-code has run? Weird. Sure. Could you specify where this is causing problems for you? felix> I find it a bit tricky to exactly specify what may GC and what felix> not. Yeah, me too. :-) felix> For example: mutations (a la "SCHEME_RECORD_SET") may very well felix> allocate storage (if the write-barrier involves allocating something felix> on the heap, that describes the mutated slot). The life-time of data felix> on the heap may be extremely short - what happens if GC or finalizers felix> run in a different OS-level thread? The authors would do good by not felix> assuming every Scheme implementation does it like S48 or PLT. It certainly wasn't our intention---we looked at a lot more Scheme implementations than just those two. However, even writing up the current draft was difficult enough. I'm happy to hear suggestions on how to improve it. felix> Alternative approaches would be: felix> 1) Selectively switch GC on/off in sections of C code (just like felix> critical sections, really). Is this really practical in all conceivable environments? felx> 2) Allocate *once* a complete chunk that will be felix> able to hold all felix> data needed subsequently without triggering a GC. That certainly seems impractical to me if you need to limit space usage. felix> Numeric types: complex numbers are not required by R5RS. I would felix> propose making accessors and constructors for extended number types felix> optional. Good point. felix> SCHEME_CALL: "For example, suppose Scheme procedure s0 captures felix> continuation a and then calls C procedure c0, which in turn calls felix> Scheme procedure s1. Procedure s1 can safely call the continuation a, felix> because that is a downward use. When a is called Scheme will remove felix> the portion of the C stack used by the call to c0." felix> How do you know that? Why do you specify this? Does this mean a is a felix> special kind of continuation, one that uses longjmp()? What if felix> continuations are explicit (in a CPS manner)? Those aren't continuations in the sense of the SRFI. (How you you tell from looking at one?) felix> "On the other hand, if s1 captures a continuation, that continuation felix> cannot be used from s0, because by the time control returns to s0 the felix> C stack used by c0 will no longer be valid. An attempt to invoke an felix> upward continuation that is closed over a portion of the C stack will felix> raise an exception." felix> Why should it raise an exception? We are interfacing Scheme with C, so felix> probably speed is the matter. Since C is an unsafe language, I propose felix> to remove all superfluous safety-checks. If I want to write safe code, felix> I use Scheme. I suspect that, in practice, the performance impact of this check will be minuscule. What do others think? felix> Unfortunately it appears to me that this is just a polished up felix> version of the S48 FFI, dragging in a lot of unnecessary (and felix> implementation- dependent) details which may or may not fit felix> other implementations. I don't think so. In fact, historically, it was the other way around: The first draft of this was written with other Scheme implementations in mind, and then implemented on Scheme 48. The actual historic ancestor is Elk (referenced in the document), not Scheme 48. It *is* the stated intention of this SRFI to be Scheme-implementation-agnostic. However, of course our take on the matter is limited by what we know. So I suggest that, whenever you say that we're being overly Scheme-48-specific, you make a concrete suggestion on how to be more general. We've put significant thought into most of the issues you mention, so any lack of generality above that probably reflects more a limit of our abilities than a limit of our willingness to improve things. felix> Why have countless macros that access and create Scheme data? Some felix> basic forms for defining code callable from Scheme (and vice versa) felix> would be more than enough, together with a simple system of specifying felix> Scheme->C->Scheme type mappings. This would also remove the GC-related felix> problems (mostly). I'll be glad to see a concrete writeup of this idea. :-) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla