This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Translators again (Re: Python transformer for Guile?)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]