guile-devel
[Top][All Lists]
Advanced

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

New module system and VM


From: Keisuke Nishida
Subject: New module system and VM
Date: Tue, 06 Feb 2001 21:35:38 -0500
User-agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.0.96 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 6 Feb 2001 11:10:32 +0100 (MET),
Dirk Herrmann wrote:
> 
> The reasons why I am not happy with #m is, that first, hash extension
> characters are rare and it is likely that we will sooner or later run into
> conflicts.  Second, #m can be put _anywhere_ in the code, for example
> (list 1 2 #m foo 3 4), which does not make sense to me.  You could modify
> the reader to treat #m specially and only accept it on the top-level, but
> this does not seem to be a clean solution to me.  Using ',' does not
> conflict with anything else, and it is common practice to use it for meta
> commands.  If I understand things right, ',' can not be used as an
> identifier character (at least not as the first character of an
> identifier) because of it's unquote semantics, or am I missing something?  
> The question, whether to use 'm' or 'module' is not of importance, since
> we could easily provide both, as Keisuke already does it in his example
> for a set of meta commands.

By the way, `,' commands are understood directly by the repl in my code,
and its not visible even to the reader.  (So meta commands work with
any language interpreter.)

> However, I don't think we are preempting the outcome of the module design
> process:  What we are doing at the moment is _doing_ the module design
> process.  It may be that some of the solutions suggested will not be used.  
> But, we don't even have an impression how we would like to use the new
> module system.  The only wishlist that I have found is a summary at
> http://www.glug.org/docbits/modules.texi.txt, but most of the points
> listed there need discussion.

Has any decision been made about the new module system so far?
I haven't followed all of discussion, but I have an impression
(or intuition) that Dybvig's module system is by itself not very
good for us.  So, I'm designing a different module system of my
own for my VM.

The following is a list of features I am thinking of:

 * There is no "current module".

 * Module variables are globally identified by an identifier
   like "system::core::car".

 * Bindings are solved syntactically, either by a translator
   or a compiler.  If you write just "car", it is expanded to
   "system::core::car" by a translator or compiler, depending
   on what modules you use.

 * An interpreter (repl) may memorize the "current working module".
   It tells the translator or the compiler what modules should be
   used to identify a variable.  So, during interactive sessions,
   a user may feel as if there *is* the current module.

 * But the fact is, all variables are globally identified at
   syntax level.  Therefore, the compiler can identify all
   variables at compile time.  This means the following code
   is not allowed:

     ;; I want to access `foo' in the module named some-module-name
     (let ((module (lookup-module some-module-name)))
       (set! (current-module) module)
       (foo x))
           -> ERROR: Unbound variable: current-module

     (let ((module (lookup-module some-module-name)))
       (module::foo x))
           -> ERROR: There is no variable named "module::foo"

   Instead, you should write as follows if you need a dynamic access:

     (let ((module (lookup-module some-module-name)))
       ((module-ref module 'foo) x))

     (let ((module (lookup-module some-module-name)))
       ((module 'foo) x))      ;; if module is an applicable smob

I guess the idea above is powerful enough to accommodate Dybvig's
module system and other typical module systems.  A syntax-case
transformer may transform a name "car" into "system::core::car",
instead of "g6342", during expansion.  Otherwise, the compiler
will search modules and find where "car" is defined in the way
we already familiar with.

I'm developing my new compiler in this policy, but since I'm
totally novice at module systems, please let me know if I'm
doing something wrong.

By the way, I was very impressed with the following idea by
Mikael Djurfeldt, regarding macro unexpansion:

| The superficial model I propose is the one of a simple interpreter
| with macros but without compilation or memoization (like a Guile or
| SCM with memoization disabled): a macro use is expanded every time it
| is being evaluated.
| 
| My proposed detailed model is that we want to store extra information
| along with the source in order to speed up evaluation (memoization in
| the current interpreter, byte-codes in Keisuke's VM, machine code when
| we have a compiler).  This information is based on various sources and
| when such a source changes, the extra information needs to be
| invalidated (we can postpone recomputing it if we want).  More
| specifically, this is performed by the unmemoization protocol or some
| generalization thereof.

This is great, I think.  I'll implement the new compiler upon
this philosophy.

Kei



reply via email to

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