Re: Current state of the language

Re: Current state of the language

[Kennel]

Robb Nebbe (nebbe@lglsun.epfl.ch) wrote:
> As a side note that isn't particularly pertinent - just informative:

> 	Ada 95 generalizes this concept of class to user defined types
> 	which provides the basis for the OO rather than adding on a
> 	separate OO annex to the existing language like C++. There
> 	are actually some interesting parallels between Ada and Sather
> 	since both languages separate polymorphic views from monomorphic
> 	views of an object. In Ada these are class-wide types and
> 	specific types (or sometimes just classes and types) and in
> 	Sather they are called abstract and concrete types.

Oddly enough, the preferred terminology for Sather is now
"types" for the abstract 'things', and "classes" for the concrete 'things',
apparently exactly reveresed from Ada. :-(

{So I guess it's not my preferred terminology.  Abstract types vs. 
 concrete classes seems to be clear, however.}

> Robb Nebbe

Re: Current state of the language

[Robb Nebbe]

In article <3kc8a7$g12@stc06.ctd.ornl.gov>, mbk@jt3ws1.seas.ucla.edu (Kennel) writes:
|> Robb Nebbe (nebbe@lglsun.epfl.ch) wrote:
|> > As a side note that isn't particularly pertinent - just informative:
|> 
|> > 	Ada 95 generalizes this concept of class to user defined types
|> > 	which provides the basis for the OO rather than adding on a
|> > 	separate OO annex to the existing language like C++. There
|> > 	are actually some interesting parallels between Ada and Sather
|> > 	since both languages separate polymorphic views from monomorphic
|> > 	views of an object. In Ada these are class-wide types and
|> > 	specific types (or sometimes just classes and types) and in
|> > 	Sather they are called abstract and concrete types.
|> 
|> Oddly enough, the preferred terminology for Sather is now
|> "types" for the abstract 'things', and "classes" for the concrete 'things',
|> apparently exactly reversed from Ada. :-(
|> 
|> {So I guess it's not my preferred terminology.  Abstract types vs. 
|>  concrete classes seems to be clear, however.}


Even though "class" and "type" are often used interchangeably in
everyday English to mean a group of individuals the nuance between
the two is that "type" places the emphasis on the similarity of
the members of the group and "class" on the commonality shared by
the members of the group.

This corresponds more closely with having the abstract view being
a class and the concrete view being a type. Of course this is contrary
to how a lot of people in computer science actually use the two terms.

I've done some speculation on why we have switched the two terms
around in computer science. My first thought was that many OO languages
have a reserved word "class" but not a reserved word "type" making class
seem more concrete. Another point seems to be the confusion between
modules and types in these same languages.

Robb Nebbe

Re: Current state of the language

[Whitney de Vries]

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


-- Whitney

Re: Current state of the language

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

Re: Current state of the language

[Robert Dewar]

"What is the difference between modules and types"

Ah ha! time to trot out again, for those who have not seen it, my observation
that the words unify and confuse both mean the same thing (join together), but
they express a very different point of view.

A lot of language design is discussion on whether two features should be
unified, or whether the attempt causes confusion.

For me, I don't like the idea of trying to unify modules and types, of course
it can be done, that's trivially obvious, and has been known for ever, but
I think it is confusing.

Re: Current state of the language

[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

"types" vs "classes" (was: Re: Current state of the language)

[Fergus Henderson]

>mbk@jt3ws1.seas.ucla.edu (Kennel) writes:
>|> Robb Nebbe (nebbe@lglsun.epfl.ch) wrote:
>|> 
>|> > 	In Ada these are class-wide types and
>|> > 	specific types (or sometimes just classes and types) and in
>|> > 	Sather they are called abstract and concrete types.
>|> 
>|> Oddly enough, the preferred terminology for Sather is now
>|> "types" for the abstract 'things', and "classes" for the concrete 'things',
>|> apparently exactly reversed from Ada. :-(

The terminology in Haskell is similar to that of Ada: Haskell has
"types", which are concrete, and "type classes" (or just "classes"),
which are abstract.

(I think the Sather people should go back to the terms
"abstract types" / "concrete types" which have no danger of confusion.)

-- 
Fergus Henderson - fjh@munta.cs.mu.oz.au

Re: Current state of the language

[Kennel]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:

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

So what? 

It's no more nonsensical than "#include <math.h>".

And Sather lets you MATH::cos() anyway.

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

It doesn't seem so bad to me.   In fact it divides up reasonably
naturally in my opinion.

Certainly you need the ability for two classes to know about the existence
of each other but that is taken for granted.

----------------------------------------------
-- Sather
----------------------------------------------
class PERSON is

	private attr pairings: LIST{PAIR}; -- may be null.
	private attr genesis: PAIR;  -- who made me.

	marriages!:PAIR is loop yield(pairings.elts!) end;

	children!:PERSON is
	-- all direct level children by all marriages.
	loop m ::= marriages!; -- for each marriage
	     loop yield(m.children!); end; -- yield all children from it.
	end;

	ancestors!: PERSON is
	-- *all* ancestors.  This routine may have infinite loops if
        -- your family comes from Arkansas.  Need a special routine for that.
	  loop
	    p ::= children!;
	    yield(p);	 -- yield direct children
	    loop yield(p.ancestors!); end; 
		 -- yield ancestors of your children.
	  end;
	end;

	siblings!: PERSON is
	-- blood brothers and sisters
	  loop yield(genesis.children!) end;
	end;

	siblings_and_half_siblings!: PERSON is
	  father ::= genesis.t1; -- first of tuple
  	  mother ::= genesis.t2; -- second of tuple
	  loop yield(father.children!); end; -- on father's side
	  loop yield(mother.children!); end; -- mother's side
	end;

end; -- class PERSON;

class PAIR is

	attr participants:TUP{PERSON,PERSON}; -- father and mother
	private attr offspring: LIST{PERSON}; -- from this marriage.
	
	children!:PERSON is
	-- children from *this* pairing
	  loop yield(offspring.elts!); end;
	end;

end;	

-----

Children of a person are different than children of a pairing.

Now what is the problem?

Modules seem necessary at a macro level (hundreds of classes), but in the 
relationships between individual classes I feel that empirical
evidence shows it to be quite feasible.  The sort of module automatically
provided by Sather and Eiffel classes is very freuqently the one you want.


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

Re: Current state of the language

[Kennel]

Kennel (mbk@jt3ws1.etd.ornl.gov) wrote:
> 	ancestors!: PERSON is
> 	-- *all* ancestors.  This routine may have infinite loops if
>         -- your family comes from Arkansas.  Need a special routine for that.
> 	  loop
> 	    p ::= children!;
> 	    yield(p);	 -- yield direct children
> 	    loop yield(p.ancestors!); end; 
> 		 -- yield ancestors of your children.
> 	  end;
> 	end;

Oops!!! This should be named "descendants!", not ancestors!.