Re: Translators again (Re: Python transformer for Guile?)

[Lalo Martins <lalo at webcom dot com>]

On Sat, Jan 22, 2000 at 02:24:32PM +0000, Neil Jerram wrote:
> Lalo Martins writes:
> 
> 1. The result of "translation" is a stream of Scheme expressions (as
> though returned by "read") that are to be evaluated in a specified
> environment.

I believe the original design was to munch the whole thing and
return the corresponding guile-scheme code.


>    1: how are translated scripts executed?
> 
> Normally they are translated and evaluated at the same time, by
> "load".

Is this a good idea? I think ``load'' should be left pure-r*rs.
Anything else would probably piss off a lot of scheme-heads :-)

One good way to still use ``load'' is using generics - if it
has an extra argument (for language, with some special flag for
autodetection) then it's the translation-powered version,
otherwise it's the r*rs scheme-only traditional one.


>       Is the ``client'' application responsible to finding out the
>       language, or is it Guile (libguile)? [...]
> 
> This is a detail, IMO.  We can implement any reasonable combination of
> -    client specification
> -    looking at file extensions
> -    simple source code analysis.

It's an important detail. Try to design an application that
supports translation without knowing this detail and you'll
see. :-)

Still, I think you give the best answer. I'd futher boil it to:

1: the client chooses the language, but it can choose ``detect''

2: the detector first tries to search for a string in the first
few lines (bytes?).

3: if that fails, it looks at the filename suffix (extension).

4: if even that fails, should it issue an error (exception) or
   return ``scheme''?


>    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).
> 
> Well in my suggestion it's a module containing a reader class
> implementation for the target language.  The module can of course be
> partly written in C.

I'm all for OOP. But isn't it overkill for this task? As I
said, all we need is a procedure, a string to search for, and
now a filename suffix (or a list of suffixes).

Using OOP could give us the benefit of abstracting the check;
instead of passing a string (both for first-few-bytes (FFB) or
filename), the translator can provide methods. Still, I'm not
sure it's an OOP case; there is nearly no need for inheritance,
nearly no chance for code reuse, and AFAICS no need for
polymorphism (there isn't really a lot of instance data involved).

[]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