This is the mail archive of the guile@cygnus.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] |
Juan Jose Garcia Ripoll <jjgarcia@ind-cr.uclm.es> writes: > That should aid to R4RS compliant code away from extensions. And because > of the same reason I would suggest that module code be *not* inside a > single list as in (module "my-module" (statement-1) (statement-2)...), > but to leave module declarations as a sort of pragmas that delimit the > scope: > > (module "my-module") > (public a b) > (define a 1) > (define b "hola") What happens if... (define (go-to-foo-module) (module "foo")) (module "bar") (public a) (define a 1) (go-to-foo-module) (public b) (define b "hola") > This way it should be even possible to distribute bytecompiled Scheme > code plus a module declaration file with just a (module...) and the > (public...) directives, and even to code several modules in a single > text file, as in ADA. I don't see why one couldn't do that with the single-list module: (module "foo" (define x 1)) (module "bar" (define y 2)) Nothing stops you from writing those in the same file. Do we need a module declaration file -- can't the info be taken from the bytecompiled code (like Java classes)? Hey, here's some more food for thought: What if the forms of the module weren't evaluated until the module was referred to? Then you could define a module to be autoloaded with: (module "foo" (load "foo")) I don't think this would be worth the inconsistencies, though: (define a 1) (module "foo" (define b a)) (set! a 2) foo.b => 2 (set! a 3) foo.b => 2 -- Kalle Olavi Niemitalo <tosi@stekt.oulu.fi>, http://stekt.oulu.fi/~tosi/