This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Design sketch for Ior---a new type of Scheme interpreter


The file guile-core/devel/vm/ior/ior.text which I've just committed
contains some wild and unsorted, but hopefully interesting, ideas
about a new type of Scheme interpreter.

It might be interesting for you two to have a look at, because some of
it is ideas for a VM design.  The text is cut out from various emails
and is not complete.

If there is something unclear which you would like me to clarify,
please let me know.

guile-core/devel/vm/ior/ior-intro.text
----------------------------------------------------------------------
I've always thought that the idea of translating other languages to
Scheme is good.  The idea of translating other languages to a
Scheme-like intermediary representation has recently become popular in
research about compilation techniques.  See for example:

http://www.neci.nj.nec.com/homepages/jagannathan/papers/tic98.ps

But, already Scheme itself is slow when interpreted by current
interpreters.  It is slow enough that people often choose not to write
their more time critical code in Scheme.  The translation of other
languages into Scheme will add extra overhead.

But note that the idea of the compiler writers is that a Scheme-like
language is a suitable *intermediate* representation.

I've now made the initial parts of the design of a new Scheme
interpreter which has an entirely new form of internal architecture.
While it is an interpreter, it lacks an evaluator in the common sense.
It is based upon incremental compilation into a very efficient
bytecode which avoids many of the common sources of overhead in an
interpreter.  In particular, it avoids most type checking, type
dispatch, unboxing and boxing of data.

My current estimate is that it will be approximately ten times faster
than the current Guile and seven times faster than MzScheme.

Also, while the language which the interpreter implements looks like
Scheme to the user, and is R5RS-compliant, it is in fact explicitly
typed.  For example, `(lambda (V1 ...) FORM1 ...)' will expand into
something which is very similar to typed lambda calculus.

Since these tools are made available explicitly in the language, it is
very suitable as a target for translation of other languages.  Also,
there are great opportunities to learn from research such as that
referred to above for doing advanced kinds of optimizations.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]