Re: Current state of the language

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <D5yq99.CxG@inmet.camb.inmet.com>, stt@spock.camb.inmet.com
(Tucker Taft) writes: 
|> Whitney de Vries (whitney@christie.Meakins.McGill.CA) wrote: 
...
|> : What is the difference between modules and types ? The need
|> : for type seems to disappear when one has module variables
|> : as in K2 ( a minimal Oberon-like language ). Or conversely
|> : the need for modules disappears when one restricts a type
|> : to a single instance ( as in Emerald ).
|>
|> A module is a namespace, whereas a type is a template for objects.
|>
|> They can be unified, as in C++ (at least pre-namespace C++) and Eiffel,
|> using a class construct with both per-instance variables
|> (data members/features) and per-class variables ("static" data
|> members or "once" features).
|>
|> However, when you start building big systems, you quickly
|> find that an entity like a class is too small to represent
|> a subsystem, and using nested classes (which is legal in newer C++'s,
|> but not in Eiffel) is not ideal, partly because the per-instance vs.
|> per-class distinction begins to get muddy in a set of nested classes,
|> and because you generally want the ability to short-cut module
|> names (the "using" clause, for example) when the hierarchies get
|> deep.
|>
|> Hence, C++ has introduced namespaces to represent the larger
|> groupings of things, and Eiffel has a module language (called "LACE" I
|> believe) for dealing with "module"-level issues of grouping and naming.
|>
|> So even if you can unify them in theory, in practice, programmers
|> of large systems need both modules and types.  Languages like
|> Ada and Modula have recognized the complementary nature of types
|> and modules, and included robust support for both from the beginning.

In Eiffel, the need to use classes for packaging leads to a nonsensical
way of importing math routines.  You inherit from a class whose instances
have no data, but do have methods like sine and square_root.  Sometimes,
an abstraction consists of two or more closely related types, perhaps
defined recursively in terms of each other, and it is often convenient to
package them in the same module.  Then a language which requires a
separate module for each class gets in the way.  (Example: An abstraction
for family trees consists of a type for persons and a type for pairings
(traditionally, marriages).  Each person is a participant in zero or more
pairings and each pairing has zero or more persons who are offspring of
the pairing.  Many of the operations for this abstraction, e.g.
iterating over all of a person's marriages or determining the pairing of
which a person is an offspring, involve operands of both types, and
artificially assigning each operation to one type or the other would be
pointless.)


--
Norman H. Cohen    ncohen@watson.ibm.com