guile-devel
[Top][All Lists]
Advanced

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

Re: Planning work


From: Keisuke Nishida
Subject: Re: Planning work
Date: Sun, 06 May 2001 20:07:55 -0400
User-agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.0.102 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 06 May 2001 13:28:00 -0500,
Rob Browning wrote:
> 
> > I think translating into an intermediate representation is more
> > convenient.  Is there a really good reason for a translator to
> > target Scheme?
> 
> Well, in Hobbit's case, at least, that's the language it speaks, plain
> old scheme. :>

Right, but we could translate any intermediate representation into
Scheme code at the codegen phase.

> Further, if we really do get a very smart compiler (where by compiler,
> I'm using my terminology from the diagram above -- i.e. the front end,
> post-translation compiler) with technologies from hobbit and/or
> stalin, etc., then *all* translation languages may benefit whenever we
> make the compiler smarter.  Also, adding an optimization to that
> compiler is then just a matter, for some cases, of adding a new
> transformation rule, and IMO parse-tree rewriting seems like something
> scheme is particularly well suited for.

Right, but this applies to any intermediate language we will have.

> So what are the disadvantages to using lists as you see them, or more
> to the point, what would be the characteristics of a superior
> representation?  BTW, I'm not trying to be argumentative here, I think
> trying to enumerate what we need/want is a good idea.

I use structures (or records) in my compiler.  For example, the
following Scheme code

  (define foo 1)

is translated into the following intermediate representation

  #<ghil-define var: #<ghil-var name: foo> val: #<ghil-quote obj: 1>>

and then compiled.  This structure is created as follows:

  (make-ghil-define (make-ghil-var 'foo) (make-ghil-quote 1))

I, in practice, add some extra slots, like source properties, in this
structure.  I realized that this representation is easier to work
with than the ordinary list representation when I was writing a
Scheme->GHIL translator.

There is another advantage.  Since structures have distinct data
types, a compiler may detect type errors at compilation time.
I think this is the real advantage, since it eliminates trivial
errors.

Consider translating the following code

  foo = 1;

into Scheme code:

  (define foo 1)

You may want to do that like this:

  (define (translate-= var val)
    `(define ,var ,val))

However, you could make a mistake like this:

  (define (translate-= var val)
    `(define ,val ,var))         ;; exchanged var and val

In this case, the error is detected at run time, not at compile time
of this translator.  On the other hand, if you write this

  (define (translate-= var val)
    (make-define val var))

the compiler detects the error if this code is statically typed.

From my short experience of writing a compiler, I realized that 
static typing would really help me write something like a compiler.
List representation is hard to debug; I am really considering
writing my VM compiler in ML :)

> Well, I still tend to fell like having it be something that you can
> manipulate as scheme forms may be a big win.  I.e. being able to do
> things like this is really nice:
> 
>   Presume that the previous definition of and, was not so smart and
>   didn't recognize at compile time, obvious short-circuits.  If the
>   first compilation phase is scheme based, then we can just re-write
>   and to add a new first clause like this:
> 
>   (define-syntax and
>     (syntax-rules ()
>       ((and #f other-value ...) #f)
>       ...))
> 
>   Now, at compile time, any construct of the form (and #f x y z) gets
>   immediately rewritten as just #f.

Hmm, this is a job of the compiler, and you don't want to use
define-syntax to do optimization...

I think one advantage of a list representation is that it is easy
for humans to manipulate.  So, we should always be able to convert

  #<ghil-define var: #<ghil-var name: foo> val: #<ghil-quote obj: 1>>

into

  (define foo (quote 1))

and vice versa.  I am thinking of an intermediate language like this.

Keisuke



reply via email to

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