Re: A new module system for Guile

[Chris.Bitmead@misys.com.au]

>> This is all very well, but off the top of my head, using the file
>> system as a name space for modules seems like a pretty bad idea
>
>Umm. Can you explain why? Scheme48 and Java use the same technique.

Partly because you are dependant on the path name syntax of the host
operating system, which can vary.

Partly because I am not a believer in traditional UNIXoid file systems
in any shape or form. My ideal would be some kind of object file system
in which path names are totally obsolete.

Partly because I don't think languages should polute themselves with
knowledge of the host OS in any shape or form, especially for something
as fundamental as a module system, and especially for such an otherwise
super-clean language such as Scheme.

I should point out that I am hardly an expert on module systems though, and
you should take my comments with a grain of salt.

>> That "." notation seems pretty suspect too
>
>We'll have to provide (module-ref boot id) for backward compatibility. But
technically >speaking `boot.id' is a) faster since it is not necessary to
intern `boot' and `id' in >weak_symhash just to throw them away later;
neither `boot' nor `id' is a symbol in the >current obarray. And b) it is a
more general approach:
>
>(set! boot.id 12)
>(if (= boot.id 12) ...
>
>And since the same syntax is used in other modern languages I just
>think it is a good idea to use it in guile, too. :)


It's just that Scheme, being a post-fix notation language, I find it
suspect to
start using some new syntax. I mean, basicly you are really changing the
syntax
of Scheme here rather severely.

One of the nice things about Scheme is that anyone can write a naive albeit
 inefficient
implementation with just the bare bones basic constructs of Scheme. Now
you're adding
a whole new syntax. The whole philosophy of Scheme is to keep the core
language simple.
If you keep the postfix notation, you could implement a naive module system
 compatible
with your design in ANY scheme implementation, just by using the built-in
features.

In fact, I think it's a good idea to keep that as a general design goal of
a Guile module
system. One that you could implement in any Scheme implementation using the
 built-in
features, even if such an implementation was horribly inefficient.

It's a bit like an object system. You can take an object system design and
implement
it in any Scheme implementation. Sure it's more efficient in most cases to
special-case
it in the core of the engine or compiler, but it's nice to know it's not
part of the core
language.