This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Translators again (Re: Python transformer for Guile?)
- To: guile at sourceware dot cygnus dot com
- Subject: Translators again (Re: Python transformer for Guile?)
- From: Lalo Martins <lalo at webcom dot com>
- Date: Sat, 22 Jan 2000 10:37:54 -0200
- References: <E12BoUY-00045z-00@mdj.nada.kth.se>
On Sat, Jan 22, 2000 at 01:33:26AM +0100, Mikael Djurfeldt wrote:
>
> Guile doesn't currently have a framework for language transformation.
> Hopefully, we'll begin working on this after other high priorities,
> such as the module system. But it's probably still a good idea to
> start looking into supporting Python already now.
I have more than once declared on the list my interest on this
matter, but somehow the thread always dies out :-) I think most
of the people who _are_ working in Guile today are scheme-heads
and don't really care a lot for translators, despite the
emphasis placed on them on Guile's ``advertisements''.
Let me try once again :-) What we need, IMHO, is to ``spec'',
as in ``settle'', a few basic things:
1: how are translated scripts executed? Is the ``client''
application responsible to finding out the language, or is
it Guile (libguile)? In the former case, it's a matter of
calling some ``*eval'' function in the translator module.
Otherwise, will language detection be added to load/gh_load
or will a ``load-and-translate'' procedure be added?
There is a third approach, which is making _the script_
responsible for setting the language; it would have to start
as Scheme, and then run some procedure (or evaluator
command) to switch. IMHO this would be a PITA for translator
writers (who would have to ignore the scheme portion
somehow), for whoever will modify the evaluator, and for
script writers.
2: assuming Guile/libguile is responsible for finding the
language out, how will it do that trick? I have spend a day
or two pondering about this while on vacation and couldn't
come up with any sollution that didn't suck.
My best suggestion is... well, rationale: translators will
hopefully be used for extension always, never scripting. If
you want to run a python script, you'll probably use python,
and so on. Assuming you want to write a script in a language
that exists only as a Guile translator (CTAX, Sonya,
whatever), your best bet is to write an interpreter and use
a shebang; #! /usr/bin/ctax-run (and ctax-run would be a
very small program, a REPL that has CTAX as the default
language.)
So perhaps our best bet is to set a standard for the first
line (actually, the first string; you terminate it with \n
if you want it to be a whole line); each translator module
(or whatever for a translator ships in) supplies the
expected first line, then the evaluator builds a table and
checks this table to find out which translator it should
dispatch the file to. This approach lets each language
define the first line in a form that is a valid line
(presumably a comment) in its language - so a PS reader can
register ``%!PS''.
3: and what form should translators ship in. I suggest a module
with a well-defined API (there isn't a lot to it actually,
IIRC it's a ``magic-string'' variable or somesuch and a
``translate'' procedure).
> about the license. Also, I started a fairly rough hack
> aimed at using the flex/bison parsers but with Scheme level
> specifiable tables some time ago. I'll gladly give you what I
> have.)
I firmly believe this is the best approach for most
translators. Of course if you can rip the original parser (as
seems to be the case with python) it will usually be better;
but for writing from scratch I'd go with your approach.
I didn't do CS college, but I made a couple of courses in
compilation, parsing etc. So if nobody volunteers to take over
your code I can do it. It's a personal interest... those with a
long term memory (and who are here long enought) will remember
I joined this list to lear about the translation framework and
module system for my FEAST project, and then put FEAST on hold
because the module system just couldn't cope with what I needed
to do.
[]s,
|alo
+----
--
I am Lalo of deB-org. You will be freed.
Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com
pgp key in the web page
Debian GNU/Linux --- http://www.debian.org
Brazil of Darkness -- http://zope.gf.com.br/BroDar