Re: On C SEXP representation

[Rob Browning]

Andreas Rottmann <address@hidden> writes:

> I tend to think that it's still more convinient that what we have
> now.

Agreed -- the current string trees aren't all that friendly, either to
manipulate or to read when written.

> Hmm, given our goal of generating bindings for scheme and not
> writing full-featured C programs in CSE, a syntax more tailored
> towards ease of use really makes sense.

Well, as you hint at below, I have some potentially overlapping ideas
here.  I may have mentioned all these before, but to summarize, at
various times, I'd thought about:

  * g-wrap's purposes (i.e. mingling C code and scheme code in a
    scheme file)

  * an "inline asm" for guile, so that you can write scheme code with
    some bits that are CSE where performance is critical.

  * a hypothetical compiler backend, i.e. compiler goes from scheme
    -> CSE -> C (perhaps with optimizations at the CSE stage --
    though a more tailored sub-language might be better here).

  * C analysis - go from C -> CSE, then do analysis and manipulation
    of C code with a scheme program (add precise GC, optimize, do
    data-flow-analysis, etc.).

  * general C API specs as sexps for scheme/lisp/whoever.

  * alternative syntax for C with a really good sexp -> C
    pretty-printer -- just in case you'd rather write sexps instead of
    C :>

Of course, I'm not sure which, if any of these are actually worth
pursuing, but if we can easily do something that helps us, and doesn't
preclude some of the above, that'd be nice.

> Note that there also seems to be some intent, coming from the
> Pika[0] developers (I lurk on the pika-dev mailing list) to put out
> a "standard" scheme API for C. I've a message (which also touches
> G-Wrap a bit) for a thread over there still in my Drafts
> folder. I'll Cc: g-wrap-dev when I send the message out.

How are they planning to handle errors?  As you probably saw, Tom Lord
popped up on guile-dev to ask about Marius' work on frames (allowing
you to install unwind/rewind handlers inline on the C side for
segments of C code).  The issues regarding the handling of errors,
especially given call/cc and the possibility that you may need to take
actions on the C side that have to be {un,re}done on {un,re}wind are
tricky, and I suspect are likely to directly affect your available API
choices.

> Indeed. I think we have two different problems at hand, and a uniform
> CSE syntax might not be the "right" way to solve them. 

No argument here.  It'd be really nice if we could have one syntax (or
collection (tower?) of syntaxes) that could address whichever of the
purposes listed above that are worth pursuing, but that may or may not
be possible, and it's probably too early to tell.

> I tend to think a single notation will not play nice with both, since
> the requirements are quite different...

You may well be right.  I suppose there's the possibility that we
might be able to have one of the syntaxes be related to (perhaps built
on, or a super/subset of) the other.  We'll just have to see what
makes sense.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4