Re: On C SEXP representation

[Andreas Rottmann]

Rob Browning <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> |   Along these lines, I've actually written a simple grammar that
>> |   should represent all of C (at least according to the ANSI C
>> |   grammar), along with an associated renderer, but it's just a toy
>> |   right now.
>> | 
>> Could you please share the code? I might come up with a parser based
>> on (parse lalr) from [0], which is , based on the LALR parser
>> generator on [1].
>
> Sure, if you think it'd be useful, but bear in mind what I had so far
> is *really* simple grammar, i.e. nearly a straight translation of the
> C grammar to sexps, with some disambiguations that make it so that you
> need little if any lookahead to render it.
>
> And also note that the only thing that I'd written was the recursive
> descent renderer that could take a CSE like this (off the top of my
> head, so may not be exactly right):
>
[snip example]

> In any case, if we think it's worth pursuing, then there are
> definitely some issues we should discuss, because what I have right
> now was the quickest possible hack that covered most (if not all) of C
> -- it's definitely a toy.  I make no claim it's the syntax we might
> eventually want.
>
I tend to think that it's still more convinient that what we have now.

> If one were just trying to capture a clean, scheme programmer friendly
> subset of what's possible in C, then they might well have a very
> different solution.  Even what I have now might be made cleaner if we
> were willing to require lookahead in the parser/renderer.  Also, at
> least at the time I also wanted to make sure it would be relatively
> straightforward for someone to figure out how to map any given C
> expression to CSE without having to re-map it in their head to a
> substantially different syntax.
>
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.

[OpenMCL ffigen]

> Yep, if there is a way we can work with others in the lisp/scheme
> community to provide more generally useful infrastructure, at least on
> the "API spec" front, then I think that'd be great.
>
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.

[0] 
http://www.talkaboutprogramming.com/group/comp.lang.scheme/messages/55673.html

> It might be worth looking more closely at what they have.  In the end,
> if we could have a "preprocessed-C -> standard-sexp-api-rep" tool that
> produced sexps that were parsable by both lisp and scheme, then that
> might be useful.  If it were able to map all of C to a standard sexp
> rep, that'd be even better.
>
I agree. I'll have a look at this stuff in my Semester break.

>> The vague worry I have about using CIL is that it might be not expressive
>> enough for conveniently writing CSE that will be spit put by g-wrap,
>> e.g. consider this (from [2]): 
>>
[snip]

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

At the one hand, we have the need for C API info extraction, where we
primarily strive to end up with a data structure easy to deal with
programatically and accuratly describing the C API.

On the other hand we (probably, at least I think so) want a way to
conviniently express C code from Scheme, but also carrying enough
semantic information to make certain optimizations and transformations
possible.

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

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/