"Gary V. Vaughan" <g...@gnu.org> writes:
> I think we are misunderstanding one another somewhere :( > > I'm talking about this: > > 1. user writes some Guile Scheme, and feeds it to Lua Zile > 2. Lua Zile runs zlc to translate Guile Scheme to Lua > 3. Lua Zile runs luac to compile output of (2) to Lua bytecodes, and > saves the result to disk > 4. Lua runtime executes file of Lua bytecodes. > > I really don't see how Tree-IL fits in here, or makes loading and executing > Guile > Scheme sources from Lua Zile any easier. > > What am I missing? Two observations: 1. The frequent references to Guile Scheme (as opposed to just Scheme) imply that Guile compatibility is desirable. 2. The most compatible Scheme implementation with Guile is, quite obviously, Guile. So, then, my advice is quite simply to maximise the use of Guile, and minimise the use of new code when writing this Guile-Scheme->Lua compiler. Since Guile is written as a hierarchy of translators, you don't need to implement Scheme per se, but can instead implement one of the languages to which we can compile Scheme already, and ask Guile to compile Scheme to that for you. e.g. guild compile foo.scm --to=tree-il --output=foo.tree-il Tree-IL is the "default" option, as it is relatively close to Scheme, but you won't have to deal with things like hygienic macro expansion. However, you can pick whichever one you find easiest to translate to Lua or Lua Bytecode. I actually intend to follow a similar approach with a guile-in-the-browser project I would like to write, however, I am probably going to implement a vm, and have it interpret Guile's assembly language directly. I'm not sure I can be clearer than that. If it wasn't enough, well, just pretend I didn't say anything :) -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
