[fetter-devel] [Fwd: Re: Verrazano rising?]

[Rayiner Hashem]

Verrazano's IR is quite well-seperated from both its front-end and its
back-end (and IIRC documented somewhere), so if there is interest in a
front-end other than GCC-XML, it would be quite doable. There is also
a provision for annotating the IR to encode details to guide the
translation, though such annotations are neither generated nor used at
the moment.

If Luis could comment more precisely on what benefits he sees from
another front-end, I could comment more specifically.

Sincerely,
    Rayiner Hashem

On 12/19/06, Ken Tilton <kentilton at gmail.com> wrote:
> Luís Oliveira wrote:
>
> > On 12/14/06, Ken Tilton <kentilton at gmail.com> wrote:
> >
> >> -------- Original Message --------
> >> Subject: Re: Verrazano rising?
> >> Date: Wed, 13 Dec 2006 20:54:19 -0500
> >> From: D Herring <dherring at at.tentpost.dot.com>
> >
> > [...]
> >
> >> P.S.  How does VZN compare to KDE's Smoke interface?
> >> http://developer.kde.org/language-bindings/smoke/index.html
> >
> >
> > I just had an idea about this. Verrazano should support multiple
> > backends other than GCC-XML.
>
> Do you mean front-end? As in input? Backends would be outputs, UFFI vs
> CFFI for example (tho a bad one since CFFI has eclipsed UFFI (tho I see
> KR has just released an upgrade)).
>
> > For instance, it would be nice to have a
> > backend that parses the OpenGL specs (we have some of that in
> > cl-opengl already)
>
> What added value do those specs offer? (Asking, not arguing.) Is it that
> we do not have the source to OpenGL, so we need something else to tell
> us how various parameters are used? Makes sense.
>
> > and something that uses or mimics Smoke.
> >
> I will have to look at that again, did not quite get the drift.
>
> Vzn is designed, IIRC, to have an intermediate representation formed by
> reading gcc_xml output, used to produce bindings. So your idea could
> work, just make a diff front-end to read the OpenGL specs to produce or
> enrich the intermediate representation, which I am getting tired of
> typing and will call UCL (Universal C api descriptor Language). We have
> talked all along about leveraging work done on SWIG that hardcodes api
> stuff, and I had great fun with the Antlr parser getting right down into
> the C source (where we could look for str* functions operating on
> strings or assigning to dereferenced parameter pointers)... haha, talk
> about metaprogramming and macros and processing source. :)
>
> kenny tilton
>
>
> _______________________________________________
> fetter-devel mailing list
> fetter-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
>
>
>
>