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=1.6 required=5.0 tests=BAYES_20,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-28 22:22:41 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!usc!elroy.jpl.nasa.gov!lll-winken.llnl.gov!fnnews.fnal.gov!stc06.ctd.ornl.gov!mbk
From: mbk@jt3ws1.etd.ornl.gov (Kennel)
Newsgroups: comp.lang.ada,comp.lang.sather
Subject: Re: Current state of the language
Followup-To: comp.lang.ada,comp.lang.sather
Date: 28 Mar 1995 18:36:52 GMT
Organization: Oak Ridge National Lab, Oak Ridge, TN
Distribution: world
Message-ID: <3l9l04$l9m@stc06.ctd.ornl.gov>
References: <3ks2vu$2eo@sifon.cc.mcgill.ca> <D5yq99.CxG@inmet.camb.inmet.com>
 <3l6jil$12kj@watnews1.watson.ibm.com>
Reply-To: kennel@msr.epm.ornl.gov
NNTP-Posting-Host: jt3ws1.etd.ornl.gov
X-Newsreader: TIN [version 1.2 PL2]
Xref: nntp.gmd.de comp.lang.ada:20195 comp.lang.sather:1703
Date: 1995-03-28T18:36:52+00:00
List-Id: <comp.lang.ada>

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