Re: [Jscheme-devel] Module implementation

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---
>>
>
>