Re: modules and syntax

[Eli Barzilay <eli@barzilay.org>]

On Dec 24, Matthew Flatt wrote:
> A description of the current module design for our next release:
> 
>  http://www.cs.utah.edu/~mflatt/tmp/modules.txt
> 
> As noted at the top of the file, modules.txt is incomplete and
> evolving, but it should provide a useful picture of where we're going.
> 
> Please send comments and suggestions to the plt-scheme (preferably) or
> to me (if plt-scheme somehow seems inappropriate).

So I'll start by saying that it does look very impressive - makes me
have that feeling of "about to get a new toy to play with"...  I
especially liked the run-time hierarchy idea, the initial-import thing
(provided that I understood it correctly - that it allows you to have
modules with different syntaxes like the signature modules), and the
set!-expander (again, if I got it right - allowing setf-like things).

Anyway, the comments I had are:

1. It is not clear if there is a single initial-import for a module.
   (Maybe more than one is using the ":" shown in the fileunit.ss
   example?)

2. Module names are case-insensitive, but since the syntax uses
   symbols, I would expect them to be sensitive if symbols are
   sensitive.  This would also mess things when you define any
   association between module names and file names.  (Also, it pushes
   people to use names like LambdaCalculus instead of lambda-calculus,
   but maybe this is intentional?).

3. The import form "(<id> . <module-name>)" looks strange when it's
   put with the other definitions that uses lists with a first symbol
   that determines what happens, so maybe a "(prefix <id> <mod-name>)"
   would be more natural?  Also, why the restriction to x.y?  What
   about ":" or "-"?  It looks like this fact (using ".") justifies
   the "(<id> . <module-name>)" form but I'm sure that some people
   will confuse the two usages of the ".".

4. The beginning of 1.3 says "(rename <id> <exported-id>)" but example
   #3 uses "(rename (x y))".

5. Wouldn't it make sense to use a simple value as a result of
   define-syntax's expr as a constant function?  This will allow
   simple definitions of compile-time constants.

6. One thing that I don't like and is (AFAIK) one of the constant
   pains in Java, is the link between module names and file names.  I
   think that this will only get worse if you assign some magic
   meaning to some names like "plt.*" or "local.*".  Why not use
   symbols for modules that are already defined somehow, and strings
   for filenames that contain modules?  This way you don't need all
   the name hacks, and if you combine it with a module-search-path
   parameter, you could use "mzlib/file" in contrast to a local
   "./file" etc etc.  Maybe even allow any (compile-time) expression
   that evaluates to either a string or a module object (if they're
   first-class or a symbol otherwise).
-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!