Re: Issue with compiling to scheme

[mark]

Thien-Thi Nguyen <address@hidden> writes:

> Maybe the simplest way is to completely separate code generation from
> compilation.  This also gives you an opportunity to do compilation in
> two places (of the code that generates the code, and of the generated
> code).  So your Makefile would look like:
>
>  gen: gen.scm
>          $(COMPILE) -o $@ $(COMPILEFLAGS) $<
>          chmod +x gen
>  
>  %.generated : %.xml
>          ./gen -o $@ $(GENFLAGS) $<
>  
>  %.go : %.generated
>          $(COMPILE) -o $@ $(COMPILEFLAGS) $<

That's kind of what I wound up doing via abuse of the language's #:read
property. Instead of providing a function that just gives the result
of xml->sxml to the compiler, I have it break some xml tags into
multiple tags so each one can be treated as a separate expression. 

Eg. The file looks like this:

<xcb header="xproto">
  <struct name="struct" />
</xcb>

And the reader would return each of the following expressions in turn:

'(xcb (@ (header "xproto")))
'(xcb-2 (@ (header "xproto")))
'(struct (@ (name "struct")))

That way the <xcb> tag gets compiled into the (define-module ...)
expression and the fictitious <xcb-2> tag gets compiled into the (begin
...)  statement that contains some module-wide definitions and so forth.

This approach stays inside of the guile 2 compiler infrastructure but it
has the disadvantage of turning what's supposed to be a simple,
single-purpose function into a bit of a stateful mess.

It would be nice if the compiler could handle multiple-value returns
from read-and-parse (assuming that doesn't harm performance... I might
try it out and see what it does).

> I am very much looking forward to learning what you discover, and
> applying it to all the projects i maintain.  (For example, Guile-SDL
> test/gfx.scm is a dog under Guile 2.x, blech.)  Fingers crossed...

I'll be happy to do that if I come up with something!

Thanks

-- 
Mark Witmer