[clean-list] Comments on the module system

[Marco Kesseler]

Hi Fabien,

>	Consider for example the case that one wants to extend some 
>	'standard' namespace with new definitions. In such a case it is 
>	probably unwise to
>	touch the original implementation modules, even if one does have the
>	sources.
>
>Well, I don't know what Marco exactly means when he says to 'Add' a
>definition to a 'namespace'. If 'namespaces' are such that definitions to
>them can be 'dynamically' 'added' during the very process of compilation,
>then the problem arises that the semantics of 'namespaces' is no longer
>declarative. That is, it may be no more possible to infer the meaning of a
>'namespace' from its text alone.

I am afraid that I do not understand. Function names are also 
'dynamically'
'added' during the process of compilation. Namespaces are just a way of
_declaring_ names in a particular named set. Same as if you would 
prefix each function name with a 'namespace' name, only without the 
need to write down the
namespace each and every time.

I could envisage a system in which you have to declare namespaces 
before you can put function names in them. I am not sure whether that 
would buy you much.

>Would this not be a blasphemous feature for a functional programming
>language ? :)

No, certainly not more than overloading.

>Also, speaking from the viewpoint of software engineering, the Clean module
>type system already allows for the kind of flexibility you are asking for.
>Since imports are transitive in Clean - to be convinced of this read the
>StdEnv.dcl - you can extend the set of identifiers exported by a module in a
>relatively safe manner : just add an import clause. Say for example you want
>to customize the StdEnv module/namespace with some new definitions of your
>own in a myDefinitions module : just add import myDefinitions in StdEnv and
>you're done - providing no name clashes occur -. This is certainly not as
>flexible as what you hint at, but IMO safer.

Changing the StdEnv module counts as changing existing modules and in 
my opinion this is bad, because you would have to do this each time a 
new version of StdEnv gets releases.

Now, if all definitions imported by StdEnv.dcl can be referred to as 
StdEnv.function (or similar) this seems equivalent with the 
namespaces as I proposed. This - if this is what you mean - seems to 
suggest however, that you must import StdEnv entirely via importing 
StdEnv.dcl. I would rather just import the functions that I actually 
need. Apart from this, there are some confusing practical problems 
associated with it I think.

I am totally at a loss, why my namespace proposal would be unsafe.

>Personally, I consider adding namespaces entities to the already existing
>module system would introduce unnecessary complications. As I see it, having
>'namespace' coupled to module enforces a sound discipline of design.

As I see it, the module system has nothing to do with namespaces. So, 
a 'sound' set of modules (whatever that is) does not automatically 
lead to a sound set of namespaces. I would rather properly design the 
set of namespaces.

>Now, my own preferences would be to allow for the use of qualified names of
>the form <module>.<identifier> to gracefully handle the problem of name
>clashes.

The problem I have with this, is that you have to run through all of 
your code as soon as you think it is better to move 'identifier' to 
some other module. Such a scenario is not unlikely.

>Another quite interesting functionality - as may be found in ADA - is the
>possibility to rename imported identifiers locally in the module where they
>are imported. Say, for example, to import 'or' from 'StdEnv' and locally
>rename it as 'booleanOr', we could write a clause : 'from StdEnv import or
>as booleanOr'.

Technically, this would work but:
- with proper namespaces you probably do not need it
- I would rather just assume that the original names are sensible 
enough, so that I do not have to come up with some (contrived) new name.

regards,
Marco