Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!howland.reston.ans.net!EU.net!julienas!news.fnet.fr!ilog!news
From: davis@ilog.fr (Harley Davis)
Subject: Re: Name spaces and Modules (Was: Re: Two Dylan Questions)
In-Reply-To: patrick_d_logan@ccm.jf.intel.com's message of Wed, 11 Jan 1995 08:55:22
Message-ID: <DAVIS.95Jan13110320@passy.ilog.fr>
Lines: 112
Sender: news@ilog.fr
Nntp-Posting-Host: passy
Organization: Ilog SA, Gentilly, France
References: <rloD1tKCG.7D6@netcom.com> <CARROLL.95Jan4120858@quadriga.cis.udel.edu>
	<DAVIS.95Jan10102924@passy.ilog.fr>
	<patrick_d_logan.61.0008EC85@ccm.jf.intel.com>
Date: 13 Jan 1995 10:03:19 GMT


In article <patrick_d_logan.61.0008EC85@ccm.jf.intel.com> patrick_d_logan@ccm.jf.intel.com (Patrick D. Logan) writes:

   In article <DAVIS.95Jan10102924@passy.ilog.fr> davis@ilog.fr (Harley Davis) writes:

   >2. I think the evidence shows (and this was my original point) that
   >   the name conflict problem is a fairly minor issue in the overall
   >   scheme of things.  The fact is that the C & C++ library market has
   >   not suffered at all from this problem; each vendor chooses their
   >   ugly prefixes and life goes on.  So I don't think this aspect of
   >   Dylan's module system (or C++ namespaces) will have very much
   >   impact on Dylan's (or C++'s) success or lack thereof.

   Will modules make or break Dylan? Is that the ultimate criterion
   for having them in the language?

   The point is that they are convenient for little cost. They put
   namespaces (and name choices in general) in the consumers' hands
   rather than the providers'. No, they don't solve the most painful
   problem of C++, but they do solve a problem that is continually
   discussed in several languages that do not have them: C++, Scheme,
   and Smalltalk, in my observations.

   In Dylan the consumer can choose which modules to use (even if they
   have the same module name) and which variables to use (even if they
   have the same variable name). The consumer can rename any variable
   to resolve a conflict or even just to be more meaningful in that
   consumer's context.

   Why have to deal with ugly prefixes, that ultimately don't resolve
   all possible conflicts, when there is a module system that is (1)
   easy to implement; and (2) would resolve all conflicts at the
   disgression of the *consumer*?

If Dylan's module system was easy to implement usefully and if it
really solved the problems it was meant to solve, then it would
certainly be good thing.  However, that's not the case.  Dylan's
module system is really hard to implement if you want it to be usable.
My argument is that it costs far too much for what it brings to the
language.  A much simpler module system would be better for everyone
concerned.

Why is Dylan's module system hard to implement?  On the face of it,
it's not hard to implement:  Each module defines a separate lexical
environment, and you can bring in bindings from other modules,
possibly renaming them.  This part is easy.

The problem comes in designing and implementing a development
environment which can support such modules.  Here is one example why -
I can bring up others if you aren't yet convinced that my reasoning is
not completely nutty:

The existence of separate namespaces encourages programmers to use
simple, very common variable names in libraries.  (C++ also encourages
very common names for class member functions for the same reason; each
class defines a separate namespace so there's apparently no reason to
worry about name clashes between separate classes.)  But that means
that you, as a user of these modules, are likely to get name conflicts
when you import several modules in your application module.  No
problem, says Dylan: You can just rename the conflicting names.  But
that means that your application code will now reference names that,
as they are written, are undocumented - that in fact have no clear
definition.

One common development environment feature that we on Unix all know
and love is the M-. command in Emacs, which brings you to the
definition of the name on which the cursor is standing.  In VisualC++,
you have a similar command: selecting a function name in your code and
hitting F1 will bring up the documentation of that function.  I use
both of these features all the time to help me understand code.

How will Dylan implementors put this kind of feature in a development
environment?  You can't just have a simple table mapping names to
locations, like Emacs TAG file.  Every code buffer in the editor has
to keep track of which module it's attached to.  The development
environment has to keep an internal representation of the module to
know which names have been locally renamed.  If the development
environment ever loses track of these things, it's a real pain to set
up again.

In short, the development environment is not going to be the simple
Emacs (or vi) plus make that C++ developers know and love; it's going
to be some complicated, newfangled thing that's going to be fragile,
bug prone, probably unportable - in any case, proprietary to their
compiler vendor and unfamiliar.  The implementors are going to have to
be the smartest in the field and will have to spend lots of time
making it work, and it will probably come out years late, well after
(say) the Dylan book is published.

Just so you don't think I'm completely ignorant of what I'm talking
about, my team and I have been working on module systems in commercial
Lisp systems for about six years now.  Ilog has been profitably
selling a Lisp with a module system for eight years.  So we certainly
have more experience in the field of modules and dynamic languages
than just about anyone else.  The major conclusion we have come to is
that the two most important considerations in a module system are that
it be absurdly simple and completely invisible to the user.  Anything
else will globally increase costs for everyone concerned even if it
solves some isolated problems.  You can read more about our work in
our LFP'94 paper "Talking about Modules and Delivery", available from
our Web server at http://www.ilog.fr/, in the Ilog Talk section.

-- Harley Davis
-- 

------------------------------------------------------------------------------
Harley Davis                            net: davis@ilog.fr
ILOG S.A.                               tel: +33 1 46 63 66 66
2 Avenue Gallini, BP 85                fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France            url: http://www.ilog.fr/

           Ilog Talk information: info@ilog.com
