[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: language translator help
From: |
Neil Jerram |
Subject: |
Re: language translator help |
Date: |
28 Apr 2002 19:21:51 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "John" == John W Eaton <address@hidden> writes:
John> On 27-Apr-2002, Neil Jerram <address@hidden> 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
- Re: language translator help, (continued)
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/28
- Re: language translator help, John W. Eaton, 2002/04/28
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/29
- Re: language translator help, John W. Eaton, 2002/04/29
- Re: language translator help, Thien-Thi Nguyen, 2002/04/29
- Re: language translator help, MJ Ray, 2002/04/30
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/30
- Re: language translator help, Neil Jerram, 2002/04/28
- Re: language translator help, Thomas Bushnell, BSG, 2002/04/28
- Re: language translator help, Per Bothner, 2002/04/28
- Re: language translator help,
Neil Jerram <=
loop translations (was: Re: language translator help), John W. Eaton, 2002/04/27
Re: loop translations (was: Re: language translator help), Marius Vollmer, 2002/04/28
Re: loop translations (was: Re: language translator help), John W. Eaton, 2002/04/28
Re: loop translations (was: Re: language translator help), Marius Vollmer, 2002/04/28
Re: loop translations (was: Re: language translator help), Marius Vollmer, 2002/04/28
Re: loop translations (was: Re: language translator help), Clinton Ebadi, 2002/04/29
Re: loop translations (was: Re: language translator help), Eric E Moore, 2002/04/29