Re: A module system should resolve, not introduce, name conflicts

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> > My position is that the idea of mixing forms of the module
> > configuration language with the bindings it's supposed to manage is
> > flawed
> 
> Quite the opposite, I think it's elegant.  The point is here that you
> can choose to remove the module which exports the module
> configuration language from your import-list:

Since, in the vast majority of cases, code in a module doesn't use the
configuration language, the configuration language bindings shouldn't
be on the default import-list.

> Scheme48 has other problems, for example it specifies a
> "meta-language" --- ",in" for example which lets you jump from one
> module to another in the repl.

This is not a problem but a strength.  As I've pointed out earlier,
it's not a good idea to be forced to import bindings for walking
around modules in every module.

It seems quite obvious that what you want to import is the bindings
which the code in your module uses, and nothing else.  It also seems
obvious that you would like the metalanguage to stay constant while
walking around among modules.

> Guile can't use such a meta-language because every module
> may have its own repl.  A module written in tcl for example
> may have a tcl repl, a module written in perl may have
> a perl repl etc.

This is exactly why the meta-language should be associated with the
repl instead of being implemented by bindings imported by individual
modules.  There is no reason why the Guile Scheme repl can't use the
meta-language in Scheme48.