[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Translator and R5RS

From: Michael Livshin
Subject: Re: Translator and R5RS
Date: 07 Oct 2000 01:51:44 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

Keisuke Nishida <address@hidden> writes:

> Hello,
> Guile is going to translate several languages to Scheme, and Guile is
> supporting R5RS.  My question is whether the translated code should be
> R5RS or not.

IMHO, no.  Guile should support R5RS, but it shouldn't be limited to
it.  some concepts common in other languages are better off with a
"native" implementation by some extra-R5RS primitives.

> For example, since Emacs Lisp has dynamic scoping, we would want to
> translate the Emacs Lisp code
>   (let ((foo "hello"))
>     (insert foo))
> into a Scheme code
>   (dynamic-let ((foo "hello"))
>     (elisp:insert (dynamic foo)))
> and to implement `dynamic-let' and `dynamic' in some way.


> As another example, someone would translate the following C-like
> code
>   foo (flag)
>   {
>     if (flag) return 1;
>     /* something */
>   }
> into
>   (define-function-with-block (foo flag)
>     (if flag (return 1))
>     ;; something
>     )
> and implement `return' by using a continuation or throw.

implementing `return' in terms of `throw' is workable, I guess.  fwiw,
Common Lisp has a `return-from' primitive, which is supposed to be
understood by the compiler and to not require an extra-lexical
run-time mechanism (i.e. throw) to implement.

> These functionalities can directly be implemented by a VM once they
> are considered to be primitives (optionally selected).

the above two are certainly good candidates.

I'm of the firm opinion that _if_ Guile is as wildly successful as a
universal language substrate as is hoped, then the day will come when
somebody will want to translate Common Lisp to it.  remember that and
plan accordingly. ;)

> On the other hand, I guess macro expansion is something that has to
> be taken care of by a translator.  For example, translating
>   #define BUFSIZ 1024
> into
>   (define-syntax BUFSIZ (syntax-rules () ((_) 1024)))
> doesn't work.

syntax-case has symbol macros.  but that's nit-picking, in general I
think your point is right.  after all, translators implement syntaxes,
and syntax extensions properly belong there and not below.

> So, I guess the translated code should be "restricted syntax
> extension + additional control functions" version of Scheme (Let's
> call it iScheme, where `i' represents "internal" or "ignoble").
> R5RS can be implemented as an extension language, which is
> translated into iScheme.


> I'm thinking about the design of a new compiler for my VM, which works
> in 3 steps:
>   1. Read
>     Read an expression from a port and build a parse tree.
>     Different syntax may produce the same parse tree.
>   2. Translate
>     Translate the parse tree into iScheme.  Macro expansion is
>     done at this level.
>   3. Compile
>     Compile the iScheme code into bytecode.
> iScheme consists of primitive syntaxes and primitive procedures.
> A translator may choose which primitives to use (e.g., the R5RS
> translator does not want to use the `return' procedure).  All
> primitives are statically compiled as efficient as possible.
> What do you think?

looks good, except I don't really understand why macro expansion
should be done in the "translate" phase.  indeed, the "read" and
"translate" phases are begging to be one phase, unless I'm missing
something.  I mean, what language needs the Scheme macro facility
except for Scheme itself?

also, unrelatedly, perhaps you could try to make your new compiler
(the "translate" phase at least) support some extendable GOOPS'y
protocol, so people could plug in new optimizations and stuff.

Purely applicative languages are poorly applicable.
                -- Alan Perlis

reply via email to

[Prev in Thread] Current Thread [Next in Thread]