Re: language translator help

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "John" == John W Eaton <jwe@bevo.che.wisc.edu> writes:

    John> On 27-Apr-2002, Neil Jerram <neil@ossau.uklinux.net> wrote:
    John> | If Elisp is a guide [...]

    John> I think it performance might be better in most cases because Octave's
    John> interpreter is known to be really slow for many operations.

OK, let's hope so.

    John> | - You have to believe that implementing your language constructs in
    John> |   Scheme is easier to maintain than implementing them in C.

    John> Well, I'm not sure.  But it is a lot of work to write an maintain an
    John> interperter for a special language, and much of that effort is
    John> duplicated by every scripting language.  People using Octave and Guile
    John> both want access to OS system calls and library functions (from basic
    John> stuff to GUI toolkits) so it seems wasteful to me that we build many
    John> interfaces to all these different libraries.  I think it would be much
    John> better to take advantage of existing work that's already been done.

Agreed - there is duplication that can be removed, and it will be cool
to have, e.g., a gnuplot interface available in Guile in general.

But I think the point about Scheme vs. C is still important.  If your
language has a `for' construct, you have to implement it somehow,
unless you are lucky enough that the target language already has an
identical construct.  IMO, Scheme is easier for this than C in
individual cases (e.g. compare unwind-protect in CVS
guile-core/lang/elisp/primitives/syntax.scm and in the Emacs source
eval.c).  And, where there is a pattern in the way that a group of
constructs maps from your language to the target, Scheme has more ways
than C of allowing you to express that pattern in your construct
definitions.

    John> | [...] might end up wanting to
    John> |   keep it in C anyway (but switch to using Guile data types).

    John> Along with a way to call Guile functions, this would offer a lot, but
    John> I would still like to get away from having to maintain the low-level
    John> details of an interpreter.

Agreed.  The low-level details I can think of that Guile could handle
for you are:

- memory allocation and GC

- evaluation, function and macro dispatching

- having to have a representation for the code that you have read in

- bignums, if Guile's bignum meet Octave's existing needs

- other basic data types like numbers and strings

- arrays, if you think that Guile's uniform array implementation is
  suitable.

Any others?

    John> | Right, but this is just a matter of wrapping existing code, isn't it?

    John> Yes and no.  There is the opportunity to correct some of the mistakes
    John> of the past too, which might mean more than just wrapping the current
    John> Octave classes.

OK.

    John> |     John> [...] having the translator is essential.
    John> | 
    John> | Totally agree; this is what Guile is supposed to be about: providing
    John> | language flexibility to its users.

    John> Yes, but there seem to be no fully functional examples of actually
    John> doing this yet.  If that's correct, why not?  What's keeping people
    John> from doing this?

    John> One problem that I can imagine is that for languages like Perl, or
    John> Python, which are starting to be quite large, it's not enough to just
    John> translate the syntax to scheme, you need the run-time.  Integrating
    John> all of that could be a lot of work.  But I think that a bigger problem
    John> is that there is no standard for these languages, so the language
    John> definition is whatever the real Perl or Python interpreters do today.
    John> Unless the authors of those tools integrate the Guile interpreter in
    John> their own code, the fork becomes difficult to maintain.

    John> These sorts of problems would not cause trouble for Octave, because I
    John> would be integrating Guile completely.  I'm just trying to understand
    John> what might be the reasons that we don't have many translators.

This is my analysis too.  In the Elisp case, FWIW, it's certainly true
that you need the runtime to have a useful system, and that the best
way to get (most of) it is to build the Emacs source in a modified
form.  This is what Ken Raeburn's Guile-based Emacs project is doing.

Therefore, it's a codebase management issue (or, equivalently, a
not-wanting-to-fork issue).  Tracking a separately managed project is
already very hard even if your aim is only to copy its syntax and
semantics.  When you want to reuse a lot of that project's source code
as well, but in a modified form, but also stay in sync as new releases
come out, it gets harder.  Cf. Ken's project, which was put back some
way by Emacs 21 coming out.

Ideally, serious political will is needed on the part of the project
that you are trying to track.  (Note that this does not exist in the
Emacs case, AFAIK.)  Barring that, I imagine it helps if the target is
standardized or changing very slowly.

My guess is that writing a good translator without full Guile
integration may prove impossible.  But perhaps Thomas Bushnell's
Python will provide a counter-example - I hope so.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user