Re: Current state of the language

[stt@spock.camb.inmet.com (Tucker Taft)]

Whitney de Vries (whitney@christie.Meakins.McGill.CA) wrote:
: Distribution: world

: Robb Nebbe (nebbe@lglsun.epfl.ch) wrote:

: : Another point seems to be the confusion between
: : modules and types in these same languages.

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

: -- Whitney

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.