🚀 go-pugleaf

In article <2747@mulga.oz>, lee@mulga.oz (Lee Naish) writes:
> The main uses of a module system are
> 	1) avoiding accidental name clashes, and
> 	2) protecting procedures from being called by anyone.
> 
> THEOREM: Every module system is either too complicated or
> 	 not powerful enough.
> 
> COROLLARY: It is impossible to get more than two people to agree on a
> 	   module system (the failure of the BSI module committee was
> 	   therefore inevitable).
> 
The initial sentence is precisely what my
algebra-for-constructing- programs paper disputed.  If you think
of a module system as an optional extra bolted on afterwards as
a means of protection, you can't expect it to work very well or
be liked much.  I claim that a better approach is to provide a
clean way of building programs out of fragments, which may have
hiding as one of its characteristics.  Examples of systems
taking this approach are CLEAR, EQLOG, Standard ML, and Lincoln
Wallen's paper last year.  I'm sure there are enough people who
like the Standard ML approach, and I _hope_ there are enough
people who like Lincoln's paper, to refute the corollary.  [As a
practical matter, everyone at Quintus likes the Quintus module
system, and the only complaints we've hard are that it isn't
powerful enough.  But then, it fails to be sufficiently powerful
in exactly the same way that Common Lisp does.]

I refrain from comment on Lee Naish's atom-based proposal.