>>>>> "felix" == felix  <xxxxxx@call-with-current-continuation.org> 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