From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f79bb,a2124d80f1ddc0d4 X-Google-Attributes: gidf79bb,public X-Google-Thread: 103376,a2124d80f1ddc0d4 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-27 06:54:13 PST Path: nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!news.sprintlink.net!uunet!portal.austin.ibm.com!bocanews.bocaraton.ibm.com!watnews.watson.ibm.com!ncohen From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada,comp.lang.sather Subject: Re: Current state of the language Date: 27 Mar 1995 14:54:13 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <3l6jil$12kj@watnews1.watson.ibm.com> References: <3ks2vu$2eo@sifon.cc.mcgill.ca> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Xref: nntp.gmd.de comp.lang.ada:20188 comp.lang.sather:1701 Date: 1995-03-27T14:54:13+00:00 List-Id: In article , 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