[clean-list] Comments on the module system

[Fabien Todescato]

Marco Kesseler writes :

	Modules already define scopes, in the public/private sense, but I 
	would not couple this to namespaces.

	I am not too familiar with the ML, Ada and Mercury solution.
However, 
	I think
	that it would be useful to add definitions to a particular namespace

	without
	having to add it to a particular module.

	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.

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

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.

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.

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.

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

Best regards, Fabien

> -----Message d'origine-----
> De:	Marco Kesseler [SMTP:m.wittebrood@mailbox.kun.nl]
> Date:	jeudi 25 juillet 2002 21:13
> À:	bpr@artisan.com
> Cc:	clean-list@cs.kun.nl
> Objet:	Re: [clean-list] Comments on the module system
> 
> >> >     One of the things that's (sorely, IMO) missing from the Clean
> module
> >> >system is qualified names, where you refer to the identifiers in a
> module 
> >> >using ModuleName.identifier or some equivalent syntax. 
> >> >
> >> >     Another issue that I've mentioned is the lack of hierarchy. Even
> >> >rather pathetic (compared to Clean) languages like Java have
> hierarchical 
> >> >namespaces and I think it's a good idea. 
> >> 
> >> In principle I agree that it is a good idea to have namespaces of 
> >> some sort,
> >> but I seriously doubt whether namespaces should be related to module 
> >> names
> >> and module hierarchy. This will lead to trouble when one starts 
> >> rearanging modules.
> >
> >If you mean that hierarchical namespaces shouldn't map to filesystem 
> >directory
> >hierarchy, I agree. However, I think modules should define scopes. Think
> of 
> >the ML module system without functors, or Ada packages without generics. 
> >Mercury, which is a kind of cousin to Clean, is a good source of design
> >ideas here (though I prefer separate interface and implementation modules
> 
> >like Clean and Ada).
> 
> Modules already define scopes, in the public/private sense, but I 
> would not couple this to namespaces.
> 
> I am not too familiar with the ML, Ada and Mercury solution. However, 
> I think
> that it would be useful to add definitions to a particular namespace 
> without
> having to add it to a particular module.
> 
> 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.
> 
> Furthermore, in a system of reasonable size, there will often be a lot
> of modules, which makes it hard for a programmmer to find out in which
> module a particular definition resides. A library of a particular party
> will usually have no conflicting names. These could all be placed in a
> single namespace, which is quite convenient, and easy to remember.
> 
> But maybe I am overlooking something?
> 
> regards,
> Marco
> 
> 
> _______________________________________________
> clean-list mailing list
> clean-list@cs.kun.nl
> http://www.cs.kun.nl/mailman/listinfo/clean-list