Re: On C SEXP representation

[Rob Browning]

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):

  (%function "do_stuff_to_fixnum" "SCM" (("SCM" x))
    (if ("SCM_INUMP" x)
        (%begin
          (auto int c_x ("SCM_INUM" x))
          (%set|= (- (* c_x c_x) c_x))
          (return ("SCM_MAKINUM" ("some_other_c_func" c_x))))
        (return #f)))

And spit out (roughly):

  SCM
  do_stuff_to_fixnum (SCM x)
  {
    if (SCM_INUMP (x))
    {
      int c_x = SCM_INUM (x);
      c_x |= (c_x * c_x) - c_x;
      return SCM_MAKINUM (some_other_c_func (c_x));
    }
    return SCM_BOOL_F;

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.

Also note that the syntax was not designed as the most convenient
syntax.  There's no syntactic sugar for things like a "C let".  That's
because at the time I wanted to make sure that CSE allowed you to
express anything you could normally express in C, and when I looked at
the C grammar again (for the first time in a long time), even though
I've been programming in C for a long time, I found that some
surprising things were legal :> The nastiest part is the type syntax.

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.

> Note that the specs are not really used; at least PyGTK2 and
> guile-gobject use the above-mentioned h2def.py script to extract API
> information from the headers. This is a rather simple task, since the
> headers are written in a quite regular way (so IMHO they solved the
> problem by using a coding convention).

Ahh, ok.  I didn't realize that.

> |   To some extent CIL ties in with my speculations about CSE above.
> |   If you have some way to translate from C to a syntax that's easier
> |   to work with (like sexps), it may be a lot easier to do many kinds
> |   of fancy analysis and manipulation (precise gc, redundant type
> |   check elimination, etc.).
> | 
> I've also looked a bit into CIL, and it should indeed be not difficult
> to come up with a piece of code that generates CSE. However, I don't
> know OCAML, and I'd prefer not to rely on an external tool that
> requires yet another language runtime...

Heh, true :>

> |   Some notable points about my conversation with with the openmcl
> |   developer:
> | 
> |     - they would be very interested in working with us on breaking
> |       out their parser as a standalone .h->sexp converter and
> |       adjusting the sexp API syntax if necessary to be both common
> |       lisp and scheme friendly.  He may also have some interest from
> |       other common lisp groups.
> | 
> Yes, that would be a nice tool indeed.

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.

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.

> 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]): 
>
>    CIL removes all local scopes and moves all variables to function
>    scope. It also separates a declaration with an initializer into a
>    declaration plus an assignment. The unfortunate effect of this
>    transformation is that local variables cannot have the const
>    qualifier.

Interesting.

-- 
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