guile-devel
[Top][All Lists]
Advanced

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

Translator and R5RS


From: Keisuke Nishida
Subject: Translator and R5RS
Date: 06 Oct 2000 19:30:46 -0400
User-agent: T-gnus/6.14.4 (based on Gnus v5.8.6) (revision 02) SEMI/1.13.7 (Awazu) Chao/1.14.0 (Momoyama) Emacs/20.7 (i686-pc-linux-gnu) MULE/4.1 (AOI)

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.

I guess translating into a customized/simplified version of Scheme is
better, as long as the translated code can be evaluated by a R5RS
interpreter by some means.  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.  These
functionalities can directly be implemented by a VM once they are
considered to be primitives (optionally selected).

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.  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?

Thanks,
Keisuke Nishida



reply via email to

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