jscheme-devel Mailing List for The Jscheme Web Programming Project

What about extending "load" to take a class and call its static "load"
method?  That way

  (jlib.JLIB.load)

becomes

  (load jlib.JLIB.class)

which is a bit more consistent.

Derek

--
Derek Upham
Senior Software Engineer
Ontain
1750 112th Ave NE, Suite C-245
Bellevue, WA 98004-3727
Tel: 425-460-1886
der...@on...

> -----Original Message-----
> From: Ken Anderson [mailto:kan...@us...]
> Sent: Friday, October 18, 2002 7:45 AM
> To: jsc...@li...
> Subject: [Jscheme-devel] CVS-update
> 
> 
> Update of /cvsroot/jscheme/jscheme/src/jschemeweb
> In directory usw-pr-cvs1:/tmp/cvs-serv5567/src/jschemeweb
> 
> Modified Files:
> 	SchemeServlet.java 
> Log Message:
> Load now takes string that can be either a file, resource, or url.
> Fix (equal? 1.0 "hi") bug
> 
> SchemServlet now load the "code" file as a resource,
> sicne getRealPath can return null.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
> 

Update of /cvsroot/jscheme/jscheme/src/jscheme
In directory usw-pr-cvs1:/tmp/cvs-serv5567/src/jscheme

Modified Files:
	SchemeTests.scm 
Log Message:
Load now takes string that can be either a file, resource, or url.
Fix (equal? 1.0 "hi") bug

SchemServlet now load the "code" file as a resource,
sicne getRealPath can return null.

Update of /cvsroot/jscheme/jscheme/src/jschemeweb
In directory usw-pr-cvs1:/tmp/cvs-serv5567/src/jschemeweb

Modified Files:
	SchemeServlet.java 
Log Message:
Load now takes string that can be either a file, resource, or url.
Fix (equal? 1.0 "hi") bug

SchemServlet now load the "code" file as a resource,
sicne getRealPath can return null.

Update of /cvsroot/jscheme/jscheme/src/jsint
In directory usw-pr-cvs1:/tmp/cvs-serv5567/src/jsint

Modified Files:
	Scheme.java U.java 
Log Message:
Load now takes string that can be either a file, resource, or url.
Fix (equal? 1.0 "hi") bug

SchemServlet now load the "code" file as a resource,
sicne getRealPath can return null.

Thanks Derek,

   My plan is to use the new module system to implement a fairly large
system (groupscheme.sourceforge.net, about 7000 lines, in 38 files in
four "packages". Each file would be a module. Actually this is an 
overestimate
since the project I'm currently working on only uses about half of those 
files
and many of the rest are older versions that don't work with the rest of 
the
library.... There is much cruft that needs to be cleaned out and much 
refactoring.

Nevertheless, this exercise should help me get a feel for how it works
in practice. If everything works nicely (or can be made to work nicely),
I'll check it into CVS. In any case, I'll keep you posted as to how the
project is going. I'm quite optimistic that this module system will work 
well
and allow us to compile effectively to boot!

Thanks for the work you've put into getting it working.

---Tim---

On Monday, October 14, 2002, at 06:58 PM, Derek Upham wrote:

> Here are two new files with tweaks to the idempotent module 
> implementation.
>
> In primitives.java, I got rid of the Scheme-level bindings for
> "loading-environment" and "environment-bindings", since the high-level
> "environment-import" and "language-import" seem to be useful enough to 
> stick
> with for now.
>
> Scheme.java now caches the environments it loads, so if you evaluate
>
>     (language-import "foo.scm")
>     (environment-import "foo.scm" "foo:")
>
> You're only hitting the disk and evaluating "foo.scm" once.  For 
> safety, the
> code expands all file names to their canonical string representation 
> when
> making cache keys.
>
> The new files are attached, plus I've put them in
>
> http://www.serv.net/~sand/jscheme-envs/src/jsint
>
> and they're in the new TAR file at
>
> http://www.serv.net/~sand/jscheme-envs.tar.gz
>
> Derek
>
>> -----Original Message-----
>> From: Timothy Hickey [mailto:tim...@ma...]
>> Sent: Friday, October 11, 2002 3:33 AM
>> To: Derek Upham
>> Subject: Re: [Jscheme-devel] Module implementation
>>
>>
>>
>> On Thursday, October 10, 2002, at 09:11 PM, Derek Upham wrote:
>>
>>>> I've modified
>>>>       (environment-import FILE PREFIX)
>>>> so that it only imports the non-macro symbols and I've added
>>>> a procedure
>>>>       (language-import FILE)
>>>> which imports only the macros (with no prefix).
>>>
>>> So regardless of the import type, the program loads the
>> specified file
>>> into
>>> a new DynamicEnvironment.
>> yes
>>>  For "environment-import", it traverses all
>>> bindings in that environment and pulls out any that do not
>> correspond to
>>> macros.
>> yes
>>>  For "language-import" is pulls out any that do.
>> yes
>>> Correct?  Is the
>>> PREFIX argument optional, or do we have to explicitly use "#f".
>> We still use #f, but language-import doesn't use prefixes.
>>>
>>> Does "language-import" still work correctly when done
>> recursively across
>>> files?
>> It should import all symbols bound to macros in the loading
>> environment,
>> and this
>> should include all language-import'ed macros as well.
>>
>>>
>>>> Importing a language from a file on the other hand
>> explicitly imports
>>>> just those macros in the file, and these macros can use
>> the bindings
>>>> in the current environment just by backquoting them.
>>>
>>> Actually, it seems more accurate to say that free variables
>> encountered
>>> during macro expansion are always looked up in the current
>> environment.
>>>
>>>>> (define local-env jsint.Scheme.INTERACTION_ENVIRONMENT$)
>>>>> (define (local-eval x) (eval x local-env))
>>>>
>>>> I'll need to play with this for a while, but these two
>> procedures seem
>>>> to
>>>> handle most of my needs for modularity. I think it might
>> be a good idea
>>>> to hide the other functionality so that environments and
>> languages do
>>>> not
>>>> become first class objects, at least not now, as that can open up
>>>> unforeseen consequences....
>>>
>>> That's fine.  I viewed the intermediate functions as a way of
>>> explaining the
>>> implementation, more than anything else.  By the way, why not have
>>> "local-env" just be
>>>
>>>     (define local-env (interaction-environment))
>>>
>>> in this case?
>> Right...
>>>
>>>> Note also, that the "local-eval" procedure doesn't quite work
>>>> as I would like as
>>>>     (environment-import "test.scm" "z:")
>>>>     (z:local-eval '(g 5)) --> (+ 1 (f 5))
>>>> so local-eval does not evaluate g as a macro but rather as a simple
>>>> closure!
>>>> It would be nice to have some sort of local eval that would
>>>> evaluate an expression in the current module.
>>>
>>> Okay, I may not understand what the problem is (I haven't had the
>>> chance to
>>> play around with the new stuff), but I take it that you're trying to
>>> evaluate an expression in the "z:" environment, where it should be
>>> completely ignorant of the top-level bindings.
>> Actually, I want to evaluate it in the z-language/environment, i.e.
>> I want the macros to work as well.
>>
>> For compilers it would be nice to be able to evaluate a
>> macro-expansion
>> in a specified environment, so maybe we don't need the macros to work
>> as we will be just using the for explicit macroexpansion anyway.
>>>  After macro expansion, you
>>> should have
>>>
>>>     (+ 1 (+ 1 5))
>>>
>>> and the final result should be "7".  Since we don't have first-class
>>> top-level environments, how about the following:
>>>
>>>   * Importing an environment using a prefix adds a record of that
>>> prefix->environment mapping to a dictionary in the current
>> environment.
>>>   * A function "named-environment" does a lookup on that
>> mapping.  It
>>> returns a value equivalent to the value of
>> "(interaction-environment)"
>>> or
>>> "(null-environment)", which can be passed as the third
>> argument to eval.
>>>   * The "named-environment" function is special, and
>>> environment-specific.
>>> It does not get imported across environments like normal functions.
>> This seems accurate. I'll need to think about it a while though.
>>>
>>> So your example would look like:
>>>
>>>     (environment-import "test.scm" "z:")
>>>     (eval '(g 5) (named-environment "z:"))
>>>
>>> Note that R5RS is careful to describe
>> "(interaction-environment)" etc.
>>> as
>>> returning a *key*, not a first-class environment.  I suppose that
>>> "(named-environment #t)" could always return the current evaluation
>>> environment key, regardless of the interaction environment, so
>>>
>>>     (equal? (eval '(named-environment #t) (named-environment "z:"))
>>>             (named-environment "z:"))
>>>
>>> should always return true.
>> This might be cleaner as then it doesn't need to be a
>> "special" function.
>>>
>>> Since the JScheme builtin macros are non-hygenic anyway, the current
>>> semantics for importing a macro seem appropriate.
>> Its looking pretty good to me.
>>
>>>  I'd still like to see how
>>> ``hygenic'' language macros (where you can explicitly violate the
>>> hygiene)
>>> would work out.
>> Sure.
>> It might be even more interesting to redo the hygenic macros
>> so that you
>> can't violate hygiene
>> in letter or spirit! (The Scheme 2002 workshop has a paper on using
>> strictly hygenic macros
>> to do very nonhygenic things.....
>>
>> ---Tim---
>>
>
>

Here are two new files with tweaks to the idempotent module implementation.

In primitives.java, I got rid of the Scheme-level bindings for
"loading-environment" and "environment-bindings", since the high-level
"environment-import" and "language-import" seem to be useful enough to stick
with for now.

Scheme.java now caches the environments it loads, so if you evaluate

    (language-import "foo.scm")
    (environment-import "foo.scm" "foo:")

You're only hitting the disk and evaluating "foo.scm" once.  For safety, the
code expands all file names to their canonical string representation when
making cache keys.

The new files are attached, plus I've put them in

http://www.serv.net/~sand/jscheme-envs/src/jsint

and they're in the new TAR file at

http://www.serv.net/~sand/jscheme-envs.tar.gz

Derek

> -----Original Message-----
> From: Timothy Hickey [mailto:tim...@ma...]
> Sent: Friday, October 11, 2002 3:33 AM
> To: Derek Upham
> Subject: Re: [Jscheme-devel] Module implementation
> 
> 
> 
> On Thursday, October 10, 2002, at 09:11 PM, Derek Upham wrote:
> 
> >> I've modified
> >>       (environment-import FILE PREFIX)
> >> so that it only imports the non-macro symbols and I've added
> >> a procedure
> >>       (language-import FILE)
> >> which imports only the macros (with no prefix).
> >
> > So regardless of the import type, the program loads the 
> specified file 
> > into
> > a new DynamicEnvironment.
> yes
> >  For "environment-import", it traverses all
> > bindings in that environment and pulls out any that do not 
> correspond to
> > macros.
> yes
> >  For "language-import" is pulls out any that do.
> yes
> > Correct?  Is the
> > PREFIX argument optional, or do we have to explicitly use "#f".
> We still use #f, but language-import doesn't use prefixes.
> >
> > Does "language-import" still work correctly when done 
> recursively across
> > files?
> It should import all symbols bound to macros in the loading 
> environment, 
> and this
> should include all language-import'ed macros as well.
> 
> >
> >> Importing a language from a file on the other hand 
> explicitly imports
> >> just those macros in the file, and these macros can use 
> the bindings
> >> in the current environment just by backquoting them.
> >
> > Actually, it seems more accurate to say that free variables 
> encountered
> > during macro expansion are always looked up in the current 
> environment.
> >
> >>> (define local-env jsint.Scheme.INTERACTION_ENVIRONMENT$)
> >>> (define (local-eval x) (eval x local-env))
> >>
> >> I'll need to play with this for a while, but these two 
> procedures seem 
> >> to
> >> handle most of my needs for modularity. I think it might 
> be a good idea
> >> to hide the other functionality so that environments and 
> languages do 
> >> not
> >> become first class objects, at least not now, as that can open up
> >> unforeseen consequences....
> >
> > That's fine.  I viewed the intermediate functions as a way of 
> > explaining the
> > implementation, more than anything else.  By the way, why not have
> > "local-env" just be
> >
> >     (define local-env (interaction-environment))
> >
> > in this case?
> Right...
> >
> >> Note also, that the "local-eval" procedure doesn't quite work
> >> as I would like as
> >>     (environment-import "test.scm" "z:")
> >>     (z:local-eval '(g 5)) --> (+ 1 (f 5))
> >> so local-eval does not evaluate g as a macro but rather as a simple
> >> closure!
> >> It would be nice to have some sort of local eval that would
> >> evaluate an expression in the current module.
> >
> > Okay, I may not understand what the problem is (I haven't had the 
> > chance to
> > play around with the new stuff), but I take it that you're trying to
> > evaluate an expression in the "z:" environment, where it should be
> > completely ignorant of the top-level bindings.
> Actually, I want to evaluate it in the z-language/environment, i.e.
> I want the macros to work as well.
> 
> For compilers it would be nice to be able to evaluate a 
> macro-expansion
> in a specified environment, so maybe we don't need the macros to work
> as we will be just using the for explicit macroexpansion anyway.
> >  After macro expansion, you
> > should have
> >
> >     (+ 1 (+ 1 5))
> >
> > and the final result should be "7".  Since we don't have first-class
> > top-level environments, how about the following:
> >
> >   * Importing an environment using a prefix adds a record of that
> > prefix->environment mapping to a dictionary in the current 
> environment.
> >   * A function "named-environment" does a lookup on that 
> mapping.  It
> > returns a value equivalent to the value of 
> "(interaction-environment)" 
> > or
> > "(null-environment)", which can be passed as the third 
> argument to eval.
> >   * The "named-environment" function is special, and 
> > environment-specific.
> > It does not get imported across environments like normal functions.
> This seems accurate. I'll need to think about it a while though.
> >
> > So your example would look like:
> >
> >     (environment-import "test.scm" "z:")
> >     (eval '(g 5) (named-environment "z:"))
> >
> > Note that R5RS is careful to describe 
> "(interaction-environment)" etc. 
> > as
> > returning a *key*, not a first-class environment.  I suppose that
> > "(named-environment #t)" could always return the current evaluation
> > environment key, regardless of the interaction environment, so
> >
> >     (equal? (eval '(named-environment #t) (named-environment "z:"))
> >             (named-environment "z:"))
> >
> > should always return true.
> This might be cleaner as then it doesn't need to be a 
> "special" function.
> >
> > Since the JScheme builtin macros are non-hygenic anyway, the current
> > semantics for importing a macro seem appropriate.
> Its looking pretty good to me.
> 
> >  I'd still like to see how
> > ``hygenic'' language macros (where you can explicitly violate the 
> > hygiene)
> > would work out.
> Sure.
> It might be even more interesting to redo the hygenic macros 
> so that you 
> can't violate hygiene
> in letter or spirit! (The Scheme 2002 workshop has a paper on using 
> strictly hygenic macros
> to do very nonhygenic things.....
> 
> ---Tim---
> 

> One more small change.... I've modified DynamicEnvironment.java so that
> when a new environment is imported, it only imports those variables whose
> names do not contain ":"  under the assumption that such variables were 
> themselves created by a higher level environment import.
>
> We could require import prefixes to end in a ":" or we could just use 
> the colon to indicate variables that should not be exported, e.g.
>    (define (local:f x) {This is a non-exported function with parameter
[x]})
> With this model the user would be responsible for picking import 
> prefixes that didn't cause name clashes...

We definintely need to re-think this.

I'm not convinced that there's any need to prevent the export of symbols.
The reasons for doing that generally boil down to (a) data hiding and (b)
preventing inadvertent collisions.  Data hiding has never been a tremendous
selling point for Lisp languages, and collisions shouldn't be a problem when
loading ``system'' libraries where you

  * load them at the beginning of your file, and
  * never change them after you've loaded them.

The fact that there's a "foo:bar:baz:do-stuff" symbol in the top-level
environment with you shouldn't matter; either your code will change the
binding to something you wrote, or you won't be paying attention to the
symbol at all.  (Not exporting recursive symbols saves speed and memory,
since you'd be copying fewer bindings, but it's not worth optimizing that
yet).

But the real problem with this is that it breaks existing code.  One feature
of the original mechanism was that you could import new-style modules, *or*
old-style Scheme code with explicit colons in their identifiers.  They'd
both appear the same when used in your code, the only difference being the
use of "pp:" or #f in the import directive.  Using colons to mean "don't
export" would force you to use a different mechanism to load, say, SLIB.  I
consider that to be a major bug.

How about we back out this particular change for now?  I'd like to use the
module system for a bit with the current ``promiscuous'' export.  It'll give
us a chance to see where the rough spots are.  If we do decide that we need
strict export/import, we can do that as a successor project.  In particular,
the choice to export a binding or not should be a property of the binding,
not something implicit in the naming convention.  (Especially when the other
half of the Scheme community uses hyphens to separate module names...)

Derek

> I've modified
>       (environment-import FILE PREFIX)
> so that it only imports the non-macro symbols and I've added 
> a procedure
>       (language-import FILE)
> which imports only the macros (with no prefix).

So regardless of the import type, the program loads the specified file into
a new DynamicEnvironment.  For "environment-import", it traverses all
bindings in that environment and pulls out any that do not correspond to
macros.  For "language-import" is pulls out any that do.  Correct?  Is the
PREFIX argument optional, or do we have to explicitly use "#f".

Does "language-import" still work correctly when done recursively across
files?

> Importing a language from a file on the other hand explicitly imports
> just those macros in the file, and these macros can use the bindings
> in the current environment just by backquoting them.

Actually, it seems more accurate to say that free variables encountered
during macro expansion are always looked up in the current environment.

> > (define local-env jsint.Scheme.INTERACTION_ENVIRONMENT$)
> > (define (local-eval x) (eval x local-env))
> 
> I'll need to play with this for a while, but these two procedures seem to
> handle most of my needs for modularity. I think it might be a good idea
> to hide the other functionality so that environments and languages do not
> become first class objects, at least not now, as that can open up 
> unforeseen consequences....

That's fine.  I viewed the intermediate functions as a way of explaining the
implementation, more than anything else.  By the way, why not have
"local-env" just be

    (define local-env (interaction-environment))

in this case?

> Note also, that the "local-eval" procedure doesn't quite work 
> as I would like as
>     (environment-import "test.scm" "z:")
>     (z:local-eval '(g 5)) --> (+ 1 (f 5))
> so local-eval does not evaluate g as a macro but rather as a simple 
> closure!
> It would be nice to have some sort of local eval that would 
> evaluate an expression in the current module.

Okay, I may not understand what the problem is (I haven't had the chance to
play around with the new stuff), but I take it that you're trying to
evaluate an expression in the "z:" environment, where it should be
completely ignorant of the top-level bindings.  After macro expansion, you
should have

    (+ 1 (+ 1 5))

and the final result should be "7".  Since we don't have first-class
top-level environments, how about the following:

  * Importing an environment using a prefix adds a record of that
prefix->environment mapping to a dictionary in the current environment.
  * A function "named-environment" does a lookup on that mapping.  It
returns a value equivalent to the value of "(interaction-environment)" or
"(null-environment)", which can be passed as the third argument to eval.
  * The "named-environment" function is special, and environment-specific.
It does not get imported across environments like normal functions.

So your example would look like:

    (environment-import "test.scm" "z:")
    (eval '(g 5) (named-environment "z:"))

Note that R5RS is careful to describe "(interaction-environment)" etc. as
returning a *key*, not a first-class environment.  I suppose that
"(named-environment #t)" could always return the current evaluation
environment key, regardless of the interaction environment, so

    (equal? (eval '(named-environment #t) (named-environment "z:"))
            (named-environment "z:"))

should always return true.

Since the JScheme builtin macros are non-hygenic anyway, the current
semantics for importing a macro seem appropriate.  I'd still like to see how
``hygenic'' language macros (where you can explicitly violate the hygiene)
would work out.

Derek

One more small change.... I've modified DynamicEnvironment.java so that
when a new environment is imported, it only imports those variables whose
names do not contain ":"  under the assumption that such variables were 
themselves
created by a higher level environment import.

We could require import prefixes to end in a ":" or we could just use 
the colon to
indicate variables that should not be exported, e.g.
   (define (local:f x) {This is a non-exported function with parameter 
[x]})
With this model the user would be responsible for picking import 
prefixes that
didn't cause name clashes...

Also, on the topic of first class environments and languages, this might 
not be
a bad idea if they have a limited API because a compiler will need to be 
able to
compile a particular module in a particular dynamic environment 
(obtained by
executing all of the requisite (language-import FILE) expressions) to 
get the
proper semantics for the macros... Thus, we need to at least be able to 
specify that
a certain macro expansion should take place in a specified environment...

---Tim---


here is the latest version of Dynamic Environment (that doesn't import 
symbols containing
a colon in their string representation):

Hi Derek,

I've made a small change to your code base which seems to answer
many of my concerns about macros and modules.
  (changed files included below)

I've modified
      (environment-import FILE PREFIX)
so that it only imports the non-macro symbols and I've added a procedure
      (language-import FILE)
which imports only the macros (with no prefix).

This approach has the nice feature that any macros defined in a module 
can
be used to define the non-macro variables as expected, but loading
in these bindings does not change the "language" of the current module.

Importing a language from a file on the other hand explicitly imports
just those macros in the file, and these macros can use the bindings
in the current environment just by backquoting them. For example,
if the following is in test.scm, then

   (language-import "test.scm" "zz:")  ;; exposes f and g as zz:f and 
zz:g, using the value of a, while

   (environment-import "test.scm")      ;; exposes a,b,c,d


> (define a 1)
> (define (b x) (set! a x))  ;; this throws an error as a module call!
> (define (c x) (+ a x))
> (define-macro (f x) `(+ ,a ,x))
> (define-macro (g x) `(+ ,a (f ,x))) ;; this works as expected when the 
> language is imported
> (define (d x) (g x)) ;; this works as expected when the environment is 
> imported
> (define local-env jsint.Scheme.INTERACTION_ENVIRONMENT$)
> (define (local-eval x) (eval x local-env))


I'll need to play with this for a while, but these two procedures seem to
handle most of my needs for modularity. I think it might be a good idea
to hide the other functionality so that environments and languages do not
become first class objects, at least not now, as that can open up 
unforeseen
consequences....

The separation of environment importing from language importing follows
Christian Q's suggestion and seems to be to be a good one. One could of
course import both the environment and language from a module. I like the
idea of not allowing prefixes for language imports as it makes the tree 
of
languages simpler to understand.

I didn't check to see whether or not import-caching is being done, but 
it would be
a good idea (i.e. create one dynamic environment per file and use that 
for all
subsequent environment/language imports)

This looks to be a simple and easy to understand macro/module system.
Note also, that the "local-eval" procedure doesn't quite work as I would 
like as
    (environment-import "test.scm" "z:")
    (z:local-eval '(g 5)) --> (+ 1 (f 5))
so local-eval does not evaluate g as a macro but rather as a simple 
closure!
It would be nice to have some sort of local eval that would evaluate an 
expression
in the current module.

---Tim---

p.s. here are the changed files...

In a "syntax-rules" macro system, I'd expect all variables created by macro
expansion to be further evaluated in the dynamic environment of the macro;
all variables defined in the original tree would be further evaluated in the
original dynamic environment.

A "syntax-case" macro system would be much the same, except we'd want some
way of explicitly overriding this as needed.  You'd need some optional
additional argument to "datum->syntax-object" and "syntax", I think.

For non-hygenic macros, the closest match to existing practice would be to
make expansion in the current environment the default.  To enforce hygiene,
you'd do something like:

  ;; file foo.scm

  (define-macro g ...)
  (define-macro (f x) ((eval 'g (loading-environment "foo.scm")) x))

This is probably only practical in a system that supports environment
caching by name.

Derek

-----Original Message-----
From: Timothy Hickey [mailto:tim...@ma...]
Sent: Saturday, October 05, 2002 2:10 PM
To: Derek Upham
Cc: jsc...@li...
Subject: Re: [Jscheme-devel] Module implementation



On Saturday, October 5, 2002, at 04:10 PM, Derek Upham wrote:

> You can get it from
>
>   http://www.serv.net/~sand/jscheme-envs.tar.gz
Thanks!

I'm looking over it now.
One question is what to do with macros....
If one defines two macros f,g in a file
and if macro f uses macro g,
and one then environment-imports them with prefix "t:"
The expansion of f takes place in the current dynamic env.
not in the "t:" environment.

---Tim---


>
> There were a lot of minor changes to a whole bunch of files (mostly 
> renaming
> "Environment" to "LocalEnvironment" throughout).
>
> Derek
>
> -----Original Message-----
> From: Timothy Hickey
> To: Derek Upham
> Sent: 10/5/2002 6:46 AM
> Subject: Re: [Jscheme-devel] Module implementation
>
> Hi Derek,
>
>    Could you put a tgz of the src directory  on your server so I can
> download it
> and play with it.  (Or perhaps you've only changed a few files and I can
> just copy those.....) I'm quite interested in exploring its
> functionality...
>
> Thanks,
> ---Tim---
>
> On Tuesday, October 1, 2002, at 04:50 PM, Derek Upham wrote:
>
>> I've put a copy of the tree at
>>
>>   http://www.serv.net/~sand/jscheme-envs
>>
>> I've removed the JAR files, class files, and compiled Java files (and
>> the
>> whole of "src/elf/eopl2") to save space.
>>
>> My design goal for the new code was to let the language support
> existing
>> practice.  Existing practice for Scheme typically involves adding a
>> module
>> name prefix to the front of each top-level object; the entire body of
>> the
>> library has to be made module-aware (or jump through hoops such as
>> massive
>> "(let ...)" statements, which amounts to the same thing).  The new
> code
>> pushes the prefixing burden onto the loading application, and does it
>> automatically.
>>
>> Regarding loading favorite code into each environment: if the favorite
>
>> code
>> satisfies the idempotence requirement, then it's possible to cache the
>> environments created by the import.  You could import "elf/basic.scm"
>> ten
>> times with ten different prefixes, but only need to load and evaluate
> it
>> once.  You are creating more dynamic variables than you would
>> otherwise, of
>> course (the originals, plus one set for each import).
>>
>> Regarding the choice of using prefixes or no: if you pass #f as the
>> prefix
>> value, the symbols get imported without any prefix, but the separate
>> environments still prevent collisions in the imported libraries.  If
> two
>> libraries conflict, you can pick one to assign a prefix to it.
>>
>> Alternatively, we always do prefix-less importing and expose the
>> "import-bindings" functionality:
>>
>>     (define (environment-import-binding src sym new-sym)
>>       (let ((env (loading-environment src)))
>>         (eval `(define ,new-sym (eval (quote ,sym) ,env))))))
>>
>> So if there's a collision, you can explicitly re-import to resolve it.
>> (This is just a sample; a real implementation would need to support
>> merging
>> Generics, and they're weirder.  Of course, this sample becomes much
> more
>> efficient if "loading-environment" caches its results.)
>>
>> Derek
>>
>> -----Original Message-----
>> From: Ken Anderson [mailto:kan...@bb...]
>> Sent: Tuesday, October 01, 2002 12:37 PM
>> To: Derek Upham; 'Timothy Hickey'
>> Cc: 'jsc...@li...'
>> Subject: RE: [Jscheme-devel] Module implementation
>>
>>
>> You've been busy.  I haven't even checked in your last extension yet.
>> Can you post the code so we can take a look at it?
>>
>> An earlier version of Jscheme had multiple environments, though it did
>
>> not
>> have a module system.  One problem with it was that you always wound
> up
>> loading your favoite code into each enviornment before you started.
>> Also,
>> the environments had to be large enough to have a value for all
> symbols.
>>
>> I'm not suggesting your approach has these problems.
>>
>> I have a strong reaction against allowing someone to reach across
> module
>> boundaries by saying foo:bar.  This is based on my experience with
>> Common
>> Lisp.  Common Lisp has a package system.  You could import a package
>> into
>> your package and refer to exported symbols simply as 'bar.  You could
>> also
>> refer to exported symbols in an arbitrary packagage as foo:exported.
>> And
>> you could access any symbol with foo::bar.
>>
>> My belief is there should be not package prefixes in your code because
>
>> it
>> make the code maintainable, you don't know where the symbol comes
> from.
>> Others liked to use the foo:bar to know where the symbol came from.
>>
>> It became tricky to manage a complex package network.
>>
>> Tim and i one day played with a simple module system which used
> lexical
>> scope, but it did not handle macros.
>>
>> At 01:51 PM 10/1/2002, Derek Upham wrote:
>>> I don't know enough about the PLT unit modules to comment on future
>>> conflicts there, except in the actual use of symbols in the global
>>> environment: this system allows the importing program to choose the
>> prefixes
>>> used.  From my brief examination of the MzScheme documentation, their
>>> "namespace" mechanism is roughly similar, but they always add
> bindings
>>> to
>>> the local environment with no prefixes and (complicated) overriding
>>> rules.
>>>
>>> Regarding macro/compilation compatibility, the idempotence
> requirement
>> saves
>>> us.  If the imported code satisfies the requirement, there should be
>>> no way
>>> of telling whether the code was loaded at compile time or at run
> time,
>>> one
>>> time or multiple times.  Of course, if the imported code changes
>>> between
>> the
>>> time it was compiled and the time it was loaded, the idempotence
>> requirement
>>> is violated.
>>>
>>> BTW, I've already modified the compiler to support this system.  Just
>
>>> pass
>> a
>>> class to "environment-import" instead of a file.  The compiled class
>>> loads
>>> into the ``current'' environment instead of the interactive one.
>>>
>>> Derek
>>>
>>> -----Original Message-----
>>> From: Timothy Hickey [mailto:tim...@ma...]
>>> Sent: Monday, September 30, 2002 8:55 PM
>>> To: Derek Upham
>>> Subject: Re: [Jscheme-devel] Module implementation
>>>
>>>
>>> Hi Derek,
>>>
>>>    We'll have to see what Ken thinks, but it looks like a very
>>> interesting
>>> extension. Ken and I had discussed earlier the idea of making Symbols
>>> into "Dynamic Variables,"  in a way similar to what you have done.
>>>
>>> It looks like this should allow current code to run unchanged but it
>>> will
>>> add an extra lookup for each free variable evaluation.
>>>
>>> I've been starting to feel the pinch from not having a module system
>>> and what I like about your system is that it is very simple (Hence
> easy
>>> to understand and easy to implement efficiently). My only concern is
>>> whether including this module system will prevent us from adding a
>>> "better" module system later (e.g. PLT's unit modules???), but I
> think
>>> any module system should be able to provide the kind of functionality
>>> yours is giving so that shouldn't be a problem.
>>>
>>> If we do check it in, then we'll need to modify the compiler to
> handle
>>> modules (shouldn't be hard).
>>>
>>> Have you thought about how the module system interacts with macros?
>>> At first glance it looks like macros should behave as expected when
>>> in an imported file....
>>>
>>> This is exciting!
>>>
>>> ---Tim---
>>>
>>>
>>> On Monday, September 30, 2002, at 06:27 PM, Derek Upham wrote:
>>>
>>>> This weekend I got a simple module system up and running.  Simple,
> in
>>>> this
>>>> case, means that it is compatible with the "module:symbol" naming
>>>> convention
>>>> used in a lot of Scheme libraries.  The steps were as follows:
>>>>
>>>> 1. Symbols no longer contain their values.  There are separate
>>>> first-class
>>>> dynamic environments that contain the values.
>>>>
>>>> 2. Free variables are no longer Symbols after code analysis; they
> are
>>>> DynamicVariable objects, bound to a particular Symbol and
>>>> DynamicEnvironment.  This means that free variables are always
> looked
>>>> up in
>>>> the environment they were defined in.
>>>>
>>>> 3. A new function "loading-environment" acts as "load", but all
>>>> definitions
>>>> are done in a new environment with ``standard'' initial bindings.
> The
>>>> new
>>>> environment is returned.  You can pass that environment as the
> second
>>>> parameter to "eval", e.g.,
>>>>
>>>>       (let ((e (loading-environment "elf/basic.scm")))
>>>>         (eval 'iterate e))
>>>>
>>>> The new environment is locked-down; you can't change any of its
>>>> dynamic
>>>> bindings.
>>>>
>>>> 4. A new builtin (non-exposed) function "importBindings" runs
> through
>>>> all
>>>> the bindings in an environment and adds similar bindings to the
>>>> current
>>>> environment.  The new bindings can either be identical, or they can
>>>> have a
>>>> prefix attached.
>>>>
>>>> 5. A new function "environment-import" does both the loading and the
>>>> importing in succession.
>>>>
>>>>
>>>>
>>>> The upshot is that you can to the following:
>>>>
>>>>> (environment-import "elf/basic.scm" "foo:")
>>>>   #t
>>>>> (foo:map* (lambda (x) (* x 2)) #(1 2 3))
>>>>   (2 4 6)
>>>>> (map* (lambda (x) (* x 2)) #(1 2 3))
>>>>   (map* {jsint.Closure ??[1] (x)} #(1 2 3) )
>>>>
>>>>     ====================================
>>>>   SchemeException:[[ERROR: undefined variable "map*"""]]
>>>>
>>>> Note that "map*" is renamed to "foo:map*" for us, but internally it
>>>> still
>>>> uses the plain "iterate" binding that is always does.  You can also
>>>> load
>>>> classes that use the normal "load()" method initialization
> convention:
>>>>
>>>>> (environment-import jlib.JLIB.class "jl:")
>>>>   #t
>>>>> (jl:menu "m1" (jl:menuitem "foo"))
>>>>   java.awt.Menu[menu0,label=m1,tearOff=false,isHelpMenu=false]
>>>>
>>>> If we pass #f for the prefix, nothing is prefixed; the function acts
>>>> like
>>>> "load".  Assigning prefixes at load time gives more flexibility than
>>>> depending on hierarchical module trees (c.f. namespace aliases in
>>>> C++).
>>>> Note that generic functions are merged correctly, not treated like
>>>> other
>>>> variables.
>>>>
>>>> This mechanism only works for libraries that are idempotent; it
> can't
>>>> matter
>>>> how many times you've loaded the library, or which of the times
> you've
>>>> loaded it you're referring to.  But a large class of Scheme code
>>>> satisfies
>>>> this restriction.  (Locking-down the new environments catches at
> least
>>>> some
>>>> violations of this rule.)
>>>>
>>>> The big chunks seem to be complete; i'm now looking for corner cases
>>>> that
>>>> might hide bugs.  Is this new functionality worth finishing up?
>>>>
>>>> Derek
>>>>
>>>> --
>>>> Derek Upham
>>>> Senior Software Engineer
>>>> Ontain
>>>> 1750 112th Ave NE, Suite C-245
>>>> Bellevue, WA 98004-3727
>>>> Tel: 425-460-1886
>>>> der...@on...
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This sf.net email is sponsored by:ThinkGeek
>>>> Welcome to geek heaven.
>>>> http://thinkgeek.com/sf
>>>> _______________________________________________
>>>> Jscheme-devel mailing list
>>>> Jsc...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
>>> Linux or FreeBSD, FREE setup, FAST network. Get your own server
>>> today at http://www.ServePath.com/indexfm.htm
>>> _______________________________________________
>>> Jscheme-devel mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

On Saturday, October 5, 2002, at 04:10 PM, Derek Upham wrote:

> You can get it from
>
>   http://www.serv.net/~sand/jscheme-envs.tar.gz
Thanks!

I'm looking over it now.
One question is what to do with macros....
If one defines two macros f,g in a file
and if macro f uses macro g,
and one then environment-imports them with prefix "t:"
The expansion of f takes place in the current dynamic env.
not in the "t:" environment.

---Tim---


>
> There were a lot of minor changes to a whole bunch of files (mostly 
> renaming
> "Environment" to "LocalEnvironment" throughout).
>
> Derek
>
> -----Original Message-----
> From: Timothy Hickey
> To: Derek Upham
> Sent: 10/5/2002 6:46 AM
> Subject: Re: [Jscheme-devel] Module implementation
>
> Hi Derek,
>
>    Could you put a tgz of the src directory  on your server so I can
> download it
> and play with it.  (Or perhaps you've only changed a few files and I can
> just copy those.....) I'm quite interested in exploring its
> functionality...
>
> Thanks,
> ---Tim---
>
> On Tuesday, October 1, 2002, at 04:50 PM, Derek Upham wrote:
>
>> I've put a copy of the tree at
>>
>>   http://www.serv.net/~sand/jscheme-envs
>>
>> I've removed the JAR files, class files, and compiled Java files (and
>> the
>> whole of "src/elf/eopl2") to save space.
>>
>> My design goal for the new code was to let the language support
> existing
>> practice.  Existing practice for Scheme typically involves adding a
>> module
>> name prefix to the front of each top-level object; the entire body of
>> the
>> library has to be made module-aware (or jump through hoops such as
>> massive
>> "(let ...)" statements, which amounts to the same thing).  The new
> code
>> pushes the prefixing burden onto the loading application, and does it
>> automatically.
>>
>> Regarding loading favorite code into each environment: if the favorite
>
>> code
>> satisfies the idempotence requirement, then it's possible to cache the
>> environments created by the import.  You could import "elf/basic.scm"
>> ten
>> times with ten different prefixes, but only need to load and evaluate
> it
>> once.  You are creating more dynamic variables than you would
>> otherwise, of
>> course (the originals, plus one set for each import).
>>
>> Regarding the choice of using prefixes or no: if you pass #f as the
>> prefix
>> value, the symbols get imported without any prefix, but the separate
>> environments still prevent collisions in the imported libraries.  If
> two
>> libraries conflict, you can pick one to assign a prefix to it.
>>
>> Alternatively, we always do prefix-less importing and expose the
>> "import-bindings" functionality:
>>
>>     (define (environment-import-binding src sym new-sym)
>>       (let ((env (loading-environment src)))
>>         (eval `(define ,new-sym (eval (quote ,sym) ,env))))))
>>
>> So if there's a collision, you can explicitly re-import to resolve it.
>> (This is just a sample; a real implementation would need to support
>> merging
>> Generics, and they're weirder.  Of course, this sample becomes much
> more
>> efficient if "loading-environment" caches its results.)
>>
>> Derek
>>
>> -----Original Message-----
>> From: Ken Anderson [mailto:kan...@bb...]
>> Sent: Tuesday, October 01, 2002 12:37 PM
>> To: Derek Upham; 'Timothy Hickey'
>> Cc: 'jsc...@li...'
>> Subject: RE: [Jscheme-devel] Module implementation
>>
>>
>> You've been busy.  I haven't even checked in your last extension yet.
>> Can you post the code so we can take a look at it?
>>
>> An earlier version of Jscheme had multiple environments, though it did
>
>> not
>> have a module system.  One problem with it was that you always wound
> up
>> loading your favoite code into each enviornment before you started.
>> Also,
>> the environments had to be large enough to have a value for all
> symbols.
>>
>> I'm not suggesting your approach has these problems.
>>
>> I have a strong reaction against allowing someone to reach across
> module
>> boundaries by saying foo:bar.  This is based on my experience with
>> Common
>> Lisp.  Common Lisp has a package system.  You could import a package
>> into
>> your package and refer to exported symbols simply as 'bar.  You could
>> also
>> refer to exported symbols in an arbitrary packagage as foo:exported.
>> And
>> you could access any symbol with foo::bar.
>>
>> My belief is there should be not package prefixes in your code because
>
>> it
>> make the code maintainable, you don't know where the symbol comes
> from.
>> Others liked to use the foo:bar to know where the symbol came from.
>>
>> It became tricky to manage a complex package network.
>>
>> Tim and i one day played with a simple module system which used
> lexical
>> scope, but it did not handle macros.
>>
>> At 01:51 PM 10/1/2002, Derek Upham wrote:
>>> I don't know enough about the PLT unit modules to comment on future
>>> conflicts there, except in the actual use of symbols in the global
>>> environment: this system allows the importing program to choose the
>> prefixes
>>> used.  From my brief examination of the MzScheme documentation, their
>>> "namespace" mechanism is roughly similar, but they always add
> bindings
>>> to
>>> the local environment with no prefixes and (complicated) overriding
>>> rules.
>>>
>>> Regarding macro/compilation compatibility, the idempotence
> requirement
>> saves
>>> us.  If the imported code satisfies the requirement, there should be
>>> no way
>>> of telling whether the code was loaded at compile time or at run
> time,
>>> one
>>> time or multiple times.  Of course, if the imported code changes
>>> between
>> the
>>> time it was compiled and the time it was loaded, the idempotence
>> requirement
>>> is violated.
>>>
>>> BTW, I've already modified the compiler to support this system.  Just
>
>>> pass
>> a
>>> class to "environment-import" instead of a file.  The compiled class
>>> loads
>>> into the ``current'' environment instead of the interactive one.
>>>
>>> Derek
>>>
>>> -----Original Message-----
>>> From: Timothy Hickey [mailto:tim...@ma...]
>>> Sent: Monday, September 30, 2002 8:55 PM
>>> To: Derek Upham
>>> Subject: Re: [Jscheme-devel] Module implementation
>>>
>>>
>>> Hi Derek,
>>>
>>>    We'll have to see what Ken thinks, but it looks like a very
>>> interesting
>>> extension. Ken and I had discussed earlier the idea of making Symbols
>>> into "Dynamic Variables,"  in a way similar to what you have done.
>>>
>>> It looks like this should allow current code to run unchanged but it
>>> will
>>> add an extra lookup for each free variable evaluation.
>>>
>>> I've been starting to feel the pinch from not having a module system
>>> and what I like about your system is that it is very simple (Hence
> easy
>>> to understand and easy to implement efficiently). My only concern is
>>> whether including this module system will prevent us from adding a
>>> "better" module system later (e.g. PLT's unit modules???), but I
> think
>>> any module system should be able to provide the kind of functionality
>>> yours is giving so that shouldn't be a problem.
>>>
>>> If we do check it in, then we'll need to modify the compiler to
> handle
>>> modules (shouldn't be hard).
>>>
>>> Have you thought about how the module system interacts with macros?
>>> At first glance it looks like macros should behave as expected when
>>> in an imported file....
>>>
>>> This is exciting!
>>>
>>> ---Tim---
>>>
>>>
>>> On Monday, September 30, 2002, at 06:27 PM, Derek Upham wrote:
>>>
>>>> This weekend I got a simple module system up and running.  Simple,
> in
>>>> this
>>>> case, means that it is compatible with the "module:symbol" naming
>>>> convention
>>>> used in a lot of Scheme libraries.  The steps were as follows:
>>>>
>>>> 1. Symbols no longer contain their values.  There are separate
>>>> first-class
>>>> dynamic environments that contain the values.
>>>>
>>>> 2. Free variables are no longer Symbols after code analysis; they
> are
>>>> DynamicVariable objects, bound to a particular Symbol and
>>>> DynamicEnvironment.  This means that free variables are always
> looked
>>>> up in
>>>> the environment they were defined in.
>>>>
>>>> 3. A new function "loading-environment" acts as "load", but all
>>>> definitions
>>>> are done in a new environment with ``standard'' initial bindings.
> The
>>>> new
>>>> environment is returned.  You can pass that environment as the
> second
>>>> parameter to "eval", e.g.,
>>>>
>>>>       (let ((e (loading-environment "elf/basic.scm")))
>>>>         (eval 'iterate e))
>>>>
>>>> The new environment is locked-down; you can't change any of its
>>>> dynamic
>>>> bindings.
>>>>
>>>> 4. A new builtin (non-exposed) function "importBindings" runs
> through
>>>> all
>>>> the bindings in an environment and adds similar bindings to the
>>>> current
>>>> environment.  The new bindings can either be identical, or they can
>>>> have a
>>>> prefix attached.
>>>>
>>>> 5. A new function "environment-import" does both the loading and the
>>>> importing in succession.
>>>>
>>>>
>>>>
>>>> The upshot is that you can to the following:
>>>>
>>>>> (environment-import "elf/basic.scm" "foo:")
>>>>   #t
>>>>> (foo:map* (lambda (x) (* x 2)) #(1 2 3))
>>>>   (2 4 6)
>>>>> (map* (lambda (x) (* x 2)) #(1 2 3))
>>>>   (map* {jsint.Closure ??[1] (x)} #(1 2 3) )
>>>>
>>>>     ====================================
>>>>   SchemeException:[[ERROR: undefined variable "map*"""]]
>>>>
>>>> Note that "map*" is renamed to "foo:map*" for us, but internally it
>>>> still
>>>> uses the plain "iterate" binding that is always does.  You can also
>>>> load
>>>> classes that use the normal "load()" method initialization
> convention:
>>>>
>>>>> (environment-import jlib.JLIB.class "jl:")
>>>>   #t
>>>>> (jl:menu "m1" (jl:menuitem "foo"))
>>>>   java.awt.Menu[menu0,label=m1,tearOff=false,isHelpMenu=false]
>>>>
>>>> If we pass #f for the prefix, nothing is prefixed; the function acts
>>>> like
>>>> "load".  Assigning prefixes at load time gives more flexibility than
>>>> depending on hierarchical module trees (c.f. namespace aliases in
>>>> C++).
>>>> Note that generic functions are merged correctly, not treated like
>>>> other
>>>> variables.
>>>>
>>>> This mechanism only works for libraries that are idempotent; it
> can't
>>>> matter
>>>> how many times you've loaded the library, or which of the times
> you've
>>>> loaded it you're referring to.  But a large class of Scheme code
>>>> satisfies
>>>> this restriction.  (Locking-down the new environments catches at
> least
>>>> some
>>>> violations of this rule.)
>>>>
>>>> The big chunks seem to be complete; i'm now looking for corner cases
>>>> that
>>>> might hide bugs.  Is this new functionality worth finishing up?
>>>>
>>>> Derek
>>>>
>>>> --
>>>> Derek Upham
>>>> Senior Software Engineer
>>>> Ontain
>>>> 1750 112th Ave NE, Suite C-245
>>>> Bellevue, WA 98004-3727
>>>> Tel: 425-460-1886
>>>> der...@on...
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This sf.net email is sponsored by:ThinkGeek
>>>> Welcome to geek heaven.
>>>> http://thinkgeek.com/sf
>>>> _______________________________________________
>>>> Jscheme-devel mailing list
>>>> Jsc...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
>>> Linux or FreeBSD, FREE setup, FAST network. Get your own server
>>> today at http://www.ServePath.com/indexfm.htm
>>> _______________________________________________
>>> Jscheme-devel mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

I've put a copy of the tree at

  http://www.serv.net/~sand/jscheme-envs

I've removed the JAR files, class files, and compiled Java files (and the
whole of "src/elf/eopl2") to save space.

My design goal for the new code was to let the language support existing
practice.  Existing practice for Scheme typically involves adding a module
name prefix to the front of each top-level object; the entire body of the
library has to be made module-aware (or jump through hoops such as massive
"(let ...)" statements, which amounts to the same thing).  The new code
pushes the prefixing burden onto the loading application, and does it
automatically.

Regarding loading favorite code into each environment: if the favorite code
satisfies the idempotence requirement, then it's possible to cache the
environments created by the import.  You could import "elf/basic.scm" ten
times with ten different prefixes, but only need to load and evaluate it
once.  You are creating more dynamic variables than you would otherwise, of
course (the originals, plus one set for each import).

Regarding the choice of using prefixes or no: if you pass #f as the prefix
value, the symbols get imported without any prefix, but the separate
environments still prevent collisions in the imported libraries.  If two
libraries conflict, you can pick one to assign a prefix to it.

Alternatively, we always do prefix-less importing and expose the
"import-bindings" functionality:

    (define (environment-import-binding src sym new-sym)
      (let ((env (loading-environment src)))
        (eval `(define ,new-sym (eval (quote ,sym) ,env))))))

So if there's a collision, you can explicitly re-import to resolve it.
(This is just a sample; a real implementation would need to support merging
Generics, and they're weirder.  Of course, this sample becomes much more
efficient if "loading-environment" caches its results.)

Derek

-----Original Message-----
From: Ken Anderson [mailto:kan...@bb...]
Sent: Tuesday, October 01, 2002 12:37 PM
To: Derek Upham; 'Timothy Hickey'
Cc: 'jsc...@li...'
Subject: RE: [Jscheme-devel] Module implementation


You've been busy.  I haven't even checked in your last extension yet.
Can you post the code so we can take a look at it?

An earlier version of Jscheme had multiple environments, though it did not 
have a module system.  One problem with it was that you always wound up 
loading your favoite code into each enviornment before you started.  Also, 
the environments had to be large enough to have a value for all symbols.

I'm not suggesting your approach has these problems.

I have a strong reaction against allowing someone to reach across module 
boundaries by saying foo:bar.  This is based on my experience with Common 
Lisp.  Common Lisp has a package system.  You could import a package into 
your package and refer to exported symbols simply as 'bar.  You could also 
refer to exported symbols in an arbitrary packagage as foo:exported.  And 
you could access any symbol with foo::bar.

My belief is there should be not package prefixes in your code because it 
make the code maintainable, you don't know where the symbol comes from.
Others liked to use the foo:bar to know where the symbol came from.

It became tricky to manage a complex package network.

Tim and i one day played with a simple module system which used lexical 
scope, but it did not handle macros.

At 01:51 PM 10/1/2002, Derek Upham wrote:
>I don't know enough about the PLT unit modules to comment on future
>conflicts there, except in the actual use of symbols in the global
>environment: this system allows the importing program to choose the
prefixes
>used.  From my brief examination of the MzScheme documentation, their
>"namespace" mechanism is roughly similar, but they always add bindings to
>the local environment with no prefixes and (complicated) overriding rules.
>
>Regarding macro/compilation compatibility, the idempotence requirement
saves
>us.  If the imported code satisfies the requirement, there should be no way
>of telling whether the code was loaded at compile time or at run time, one
>time or multiple times.  Of course, if the imported code changes between
the
>time it was compiled and the time it was loaded, the idempotence
requirement
>is violated.
>
>BTW, I've already modified the compiler to support this system.  Just pass
a
>class to "environment-import" instead of a file.  The compiled class loads
>into the ``current'' environment instead of the interactive one.
>
>Derek
>
>-----Original Message-----
>From: Timothy Hickey [mailto:tim...@ma...]
>Sent: Monday, September 30, 2002 8:55 PM
>To: Derek Upham
>Subject: Re: [Jscheme-devel] Module implementation
>
>
>Hi Derek,
>
>    We'll have to see what Ken thinks, but it looks like a very interesting
>extension. Ken and I had discussed earlier the idea of making Symbols
>into "Dynamic Variables,"  in a way similar to what you have done.
>
>It looks like this should allow current code to run unchanged but it will
>add an extra lookup for each free variable evaluation.
>
>I've been starting to feel the pinch from not having a module system
>and what I like about your system is that it is very simple (Hence easy
>to understand and easy to implement efficiently). My only concern is
>whether including this module system will prevent us from adding a
>"better" module system later (e.g. PLT's unit modules???), but I think
>any module system should be able to provide the kind of functionality
>yours is giving so that shouldn't be a problem.
>
>If we do check it in, then we'll need to modify the compiler to handle
>modules (shouldn't be hard).
>
>Have you thought about how the module system interacts with macros?
>At first glance it looks like macros should behave as expected when
>in an imported file....
>
>This is exciting!
>
>---Tim---
>
>
>On Monday, September 30, 2002, at 06:27 PM, Derek Upham wrote:
>
> > This weekend I got a simple module system up and running.  Simple, in
> > this
> > case, means that it is compatible with the "module:symbol" naming
> > convention
> > used in a lot of Scheme libraries.  The steps were as follows:
> >
> > 1. Symbols no longer contain their values.  There are separate
> > first-class
> > dynamic environments that contain the values.
> >
> > 2. Free variables are no longer Symbols after code analysis; they are
> > DynamicVariable objects, bound to a particular Symbol and
> > DynamicEnvironment.  This means that free variables are always looked
> > up in
> > the environment they were defined in.
> >
> > 3. A new function "loading-environment" acts as "load", but all
> > definitions
> > are done in a new environment with ``standard'' initial bindings.  The
> > new
> > environment is returned.  You can pass that environment as the second
> > parameter to "eval", e.g.,
> >
> >       (let ((e (loading-environment "elf/basic.scm")))
> >         (eval 'iterate e))
> >
> > The new environment is locked-down; you can't change any of its dynamic
> > bindings.
> >
> > 4. A new builtin (non-exposed) function "importBindings" runs through
> > all
> > the bindings in an environment and adds similar bindings to the current
> > environment.  The new bindings can either be identical, or they can
> > have a
> > prefix attached.
> >
> > 5. A new function "environment-import" does both the loading and the
> > importing in succession.
> >
> >
> >
> > The upshot is that you can to the following:
> >
> >> (environment-import "elf/basic.scm" "foo:")
> >   #t
> >> (foo:map* (lambda (x) (* x 2)) #(1 2 3))
> >   (2 4 6)
> >> (map* (lambda (x) (* x 2)) #(1 2 3))
> >   (map* {jsint.Closure ??[1] (x)} #(1 2 3) )
> >
> >     ====================================
> >   SchemeException:[[ERROR: undefined variable "map*"""]]
> >
> > Note that "map*" is renamed to "foo:map*" for us, but internally it
> > still
> > uses the plain "iterate" binding that is always does.  You can also load
> > classes that use the normal "load()" method initialization convention:
> >
> >> (environment-import jlib.JLIB.class "jl:")
> >   #t
> >> (jl:menu "m1" (jl:menuitem "foo"))
> >   java.awt.Menu[menu0,label=m1,tearOff=false,isHelpMenu=false]
> >
> > If we pass #f for the prefix, nothing is prefixed; the function acts
> > like
> > "load".  Assigning prefixes at load time gives more flexibility than
> > depending on hierarchical module trees (c.f. namespace aliases in C++).
> > Note that generic functions are merged correctly, not treated like other
> > variables.
> >
> > This mechanism only works for libraries that are idempotent; it can't
> > matter
> > how many times you've loaded the library, or which of the times you've
> > loaded it you're referring to.  But a large class of Scheme code
> > satisfies
> > this restriction.  (Locking-down the new environments catches at least
> > some
> > violations of this rule.)
> >
> > The big chunks seem to be complete; i'm now looking for corner cases
> > that
> > might hide bugs.  Is this new functionality worth finishing up?
> >
> > Derek
> >
> > --
> > Derek Upham
> > Senior Software Engineer
> > Ontain
> > 1750 112th Ave NE, Suite C-245
> > Bellevue, WA 98004-3727
> > Tel: 425-460-1886
> > der...@on...
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Jscheme-devel mailing list
> > Jsc...@li...
> > https://lists.sourceforge.net/lists/listinfo/jscheme-devel
> >
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: DEDICATED SERVERS only $89!
>Linux or FreeBSD, FREE setup, FAST network. Get your own server
>today at http://www.ServePath.com/indexfm.htm
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

You've been busy.  I haven't even checked in your last extension yet.
Can you post the code so we can take a look at it?

An earlier version of Jscheme had multiple environments, though it did not 
have a module system.  One problem with it was that you always wound up 
loading your favoite code into each enviornment before you started.  Also, 
the environments had to be large enough to have a value for all symbols.

I'm not suggesting your approach has these problems.

I have a strong reaction against allowing someone to reach across module 
boundaries by saying foo:bar.  This is based on my experience with Common 
Lisp.  Common Lisp has a package system.  You could import a package into 
your package and refer to exported symbols simply as 'bar.  You could also 
refer to exported symbols in an arbitrary packagage as foo:exported.  And 
you could access any symbol with foo::bar.

My belief is there should be not package prefixes in your code because it 
make the code maintainable, you don't know where the symbol comes from.
Others liked to use the foo:bar to know where the symbol came from.

It became tricky to manage a complex package network.

Tim and i one day played with a simple module system which used lexical 
scope, but it did not handle macros.

At 01:51 PM 10/1/2002, Derek Upham wrote:
>I don't know enough about the PLT unit modules to comment on future
>conflicts there, except in the actual use of symbols in the global
>environment: this system allows the importing program to choose the prefixes
>used.  From my brief examination of the MzScheme documentation, their
>"namespace" mechanism is roughly similar, but they always add bindings to
>the local environment with no prefixes and (complicated) overriding rules.
>
>Regarding macro/compilation compatibility, the idempotence requirement saves
>us.  If the imported code satisfies the requirement, there should be no way
>of telling whether the code was loaded at compile time or at run time, one
>time or multiple times.  Of course, if the imported code changes between the
>time it was compiled and the time it was loaded, the idempotence requirement
>is violated.
>
>BTW, I've already modified the compiler to support this system.  Just pass a
>class to "environment-import" instead of a file.  The compiled class loads
>into the ``current'' environment instead of the interactive one.
>
>Derek
>
>-----Original Message-----
>From: Timothy Hickey [mailto:tim...@ma...]
>Sent: Monday, September 30, 2002 8:55 PM
>To: Derek Upham
>Subject: Re: [Jscheme-devel] Module implementation
>
>
>Hi Derek,
>
>    We'll have to see what Ken thinks, but it looks like a very interesting
>extension. Ken and I had discussed earlier the idea of making Symbols
>into "Dynamic Variables,"  in a way similar to what you have done.
>
>It looks like this should allow current code to run unchanged but it will
>add an extra lookup for each free variable evaluation.
>
>I've been starting to feel the pinch from not having a module system
>and what I like about your system is that it is very simple (Hence easy
>to understand and easy to implement efficiently). My only concern is
>whether including this module system will prevent us from adding a
>"better" module system later (e.g. PLT's unit modules???), but I think
>any module system should be able to provide the kind of functionality
>yours is giving so that shouldn't be a problem.
>
>If we do check it in, then we'll need to modify the compiler to handle
>modules (shouldn't be hard).
>
>Have you thought about how the module system interacts with macros?
>At first glance it looks like macros should behave as expected when
>in an imported file....
>
>This is exciting!
>
>---Tim---
>
>
>On Monday, September 30, 2002, at 06:27 PM, Derek Upham wrote:
>
> > This weekend I got a simple module system up and running.  Simple, in
> > this
> > case, means that it is compatible with the "module:symbol" naming
> > convention
> > used in a lot of Scheme libraries.  The steps were as follows:
> >
> > 1. Symbols no longer contain their values.  There are separate
> > first-class
> > dynamic environments that contain the values.
> >
> > 2. Free variables are no longer Symbols after code analysis; they are
> > DynamicVariable objects, bound to a particular Symbol and
> > DynamicEnvironment.  This means that free variables are always looked
> > up in
> > the environment they were defined in.
> >
> > 3. A new function "loading-environment" acts as "load", but all
> > definitions
> > are done in a new environment with ``standard'' initial bindings.  The
> > new
> > environment is returned.  You can pass that environment as the second
> > parameter to "eval", e.g.,
> >
> >       (let ((e (loading-environment "elf/basic.scm")))
> >         (eval 'iterate e))
> >
> > The new environment is locked-down; you can't change any of its dynamic
> > bindings.
> >
> > 4. A new builtin (non-exposed) function "importBindings" runs through
> > all
> > the bindings in an environment and adds similar bindings to the current
> > environment.  The new bindings can either be identical, or they can
> > have a
> > prefix attached.
> >
> > 5. A new function "environment-import" does both the loading and the
> > importing in succession.
> >
> >
> >
> > The upshot is that you can to the following:
> >
> >> (environment-import "elf/basic.scm" "foo:")
> >   #t
> >> (foo:map* (lambda (x) (* x 2)) #(1 2 3))
> >   (2 4 6)
> >> (map* (lambda (x) (* x 2)) #(1 2 3))
> >   (map* {jsint.Closure ??[1] (x)} #(1 2 3) )
> >
> >     ====================================
> >   SchemeException:[[ERROR: undefined variable "map*"""]]
> >
> > Note that "map*" is renamed to "foo:map*" for us, but internally it
> > still
> > uses the plain "iterate" binding that is always does.  You can also load
> > classes that use the normal "load()" method initialization convention:
> >
> >> (environment-import jlib.JLIB.class "jl:")
> >   #t
> >> (jl:menu "m1" (jl:menuitem "foo"))
> >   java.awt.Menu[menu0,label=m1,tearOff=false,isHelpMenu=false]
> >
> > If we pass #f for the prefix, nothing is prefixed; the function acts
> > like
> > "load".  Assigning prefixes at load time gives more flexibility than
> > depending on hierarchical module trees (c.f. namespace aliases in C++).
> > Note that generic functions are merged correctly, not treated like other
> > variables.
> >
> > This mechanism only works for libraries that are idempotent; it can't
> > matter
> > how many times you've loaded the library, or which of the times you've
> > loaded it you're referring to.  But a large class of Scheme code
> > satisfies
> > this restriction.  (Locking-down the new environments catches at least
> > some
> > violations of this rule.)
> >
> > The big chunks seem to be complete; i'm now looking for corner cases
> > that
> > might hide bugs.  Is this new functionality worth finishing up?
> >
> > Derek
> >
> > --
> > Derek Upham
> > Senior Software Engineer
> > Ontain
> > 1750 112th Ave NE, Suite C-245
> > Bellevue, WA 98004-3727
> > Tel: 425-460-1886
> > der...@on...
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Jscheme-devel mailing list
> > Jsc...@li...
> > https://lists.sourceforge.net/lists/listinfo/jscheme-devel
> >
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: DEDICATED SERVERS only $89!
>Linux or FreeBSD, FREE setup, FAST network. Get your own server
>today at http://www.ServePath.com/indexfm.htm
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

I don't know enough about the PLT unit modules to comment on future
conflicts there, except in the actual use of symbols in the global
environment: this system allows the importing program to choose the prefixes
used.  From my brief examination of the MzScheme documentation, their
"namespace" mechanism is roughly similar, but they always add bindings to
the local environment with no prefixes and (complicated) overriding rules.

Regarding macro/compilation compatibility, the idempotence requirement saves
us.  If the imported code satisfies the requirement, there should be no way
of telling whether the code was loaded at compile time or at run time, one
time or multiple times.  Of course, if the imported code changes between the
time it was compiled and the time it was loaded, the idempotence requirement
is violated.

BTW, I've already modified the compiler to support this system.  Just pass a
class to "environment-import" instead of a file.  The compiled class loads
into the ``current'' environment instead of the interactive one.

Derek

-----Original Message-----
From: Timothy Hickey [mailto:tim...@ma...]
Sent: Monday, September 30, 2002 8:55 PM
To: Derek Upham
Subject: Re: [Jscheme-devel] Module implementation


Hi Derek,

   We'll have to see what Ken thinks, but it looks like a very interesting
extension. Ken and I had discussed earlier the idea of making Symbols
into "Dynamic Variables,"  in a way similar to what you have done.

It looks like this should allow current code to run unchanged but it will
add an extra lookup for each free variable evaluation.

I've been starting to feel the pinch from not having a module system
and what I like about your system is that it is very simple (Hence easy
to understand and easy to implement efficiently). My only concern is
whether including this module system will prevent us from adding a
"better" module system later (e.g. PLT's unit modules???), but I think
any module system should be able to provide the kind of functionality
yours is giving so that shouldn't be a problem.

If we do check it in, then we'll need to modify the compiler to handle
modules (shouldn't be hard).

Have you thought about how the module system interacts with macros?
At first glance it looks like macros should behave as expected when
in an imported file....

This is exciting!

---Tim---


On Monday, September 30, 2002, at 06:27 PM, Derek Upham wrote:

> This weekend I got a simple module system up and running.  Simple, in 
> this
> case, means that it is compatible with the "module:symbol" naming 
> convention
> used in a lot of Scheme libraries.  The steps were as follows:
>
> 1. Symbols no longer contain their values.  There are separate 
> first-class
> dynamic environments that contain the values.
>
> 2. Free variables are no longer Symbols after code analysis; they are
> DynamicVariable objects, bound to a particular Symbol and
> DynamicEnvironment.  This means that free variables are always looked 
> up in
> the environment they were defined in.
>
> 3. A new function "loading-environment" acts as "load", but all 
> definitions
> are done in a new environment with ``standard'' initial bindings.  The 
> new
> environment is returned.  You can pass that environment as the second
> parameter to "eval", e.g.,
>
> 	(let ((e (loading-environment "elf/basic.scm")))
> 	  (eval 'iterate e))
>
> The new environment is locked-down; you can't change any of its dynamic
> bindings.
>
> 4. A new builtin (non-exposed) function "importBindings" runs through 
> all
> the bindings in an environment and adds similar bindings to the current
> environment.  The new bindings can either be identical, or they can 
> have a
> prefix attached.
>
> 5. A new function "environment-import" does both the loading and the
> importing in succession.
>
>
>
> The upshot is that you can to the following:
>
>> (environment-import "elf/basic.scm" "foo:")
>   #t
>> (foo:map* (lambda (x) (* x 2)) #(1 2 3))
>   (2 4 6)
>> (map* (lambda (x) (* x 2)) #(1 2 3))
>   (map* {jsint.Closure ??[1] (x)} #(1 2 3) )
>
>     ====================================
>   SchemeException:[[ERROR: undefined variable "map*"""]]
>
> Note that "map*" is renamed to "foo:map*" for us, but internally it 
> still
> uses the plain "iterate" binding that is always does.  You can also load
> classes that use the normal "load()" method initialization convention:
>
>> (environment-import jlib.JLIB.class "jl:")
>   #t
>> (jl:menu "m1" (jl:menuitem "foo"))
>   java.awt.Menu[menu0,label=m1,tearOff=false,isHelpMenu=false]
>
> If we pass #f for the prefix, nothing is prefixed; the function acts 
> like
> "load".  Assigning prefixes at load time gives more flexibility than
> depending on hierarchical module trees (c.f. namespace aliases in C++).
> Note that generic functions are merged correctly, not treated like other
> variables.
>
> This mechanism only works for libraries that are idempotent; it can't 
> matter
> how many times you've loaded the library, or which of the times you've
> loaded it you're referring to.  But a large class of Scheme code 
> satisfies
> this restriction.  (Locking-down the new environments catches at least 
> some
> violations of this rule.)
>
> The big chunks seem to be complete; i'm now looking for corner cases 
> that
> might hide bugs.  Is this new functionality worth finishing up?
>
> Derek
>
> --
> Derek Upham
> Senior Software Engineer
> Ontain
> 1750 112th Ave NE, Suite C-245
> Bellevue, WA 98004-3727
> Tel: 425-460-1886
> der...@on...
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>