Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!rutgers!mit-eddie!uw-beaver!cornell!rochester!seismo!vrdxhq!verdix!ogcvax!pase
From: pase@ogcvax.UUCP
Newsgroups: comp.lang.ada,comp.lang.misc,comp.ai
Subject: Re: Software Reuse (short title)
Message-ID: <1339@ogcvax.UUCP>
Date: Mon, 6-Jul-87 22:21:06 EDT
Article-I.D.: ogcvax.1339
Posted: Mon Jul  6 22:21:06 1987
Date-Received: Thu, 9-Jul-87 03:19:55 EDT
References: <4661@utah-cs.UUCP> <668@titan.camcon.co.uk> 
Reply-To: pase@ogcvax.UUCP (Douglas M. Pase)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 20
Xref: utgpu comp.lang.ada:416 comp.lang.misc:499 comp.ai:602

In article  jbn@glacier.UUCP (John B. Nagle) writes:
>
>     The trouble with this idea is that we have no good way to express
>algorithms "abstractly".  [...]

Well, I'm not sure just where the limits are, but polymorphic types can go
a long way towards what you have been describing.  It seems that a uniform
notation for operators + the ability to define additional operators +
polymorphically typed structures are about all you need.  Several functional
languages already provide an adequate basis for these features.  One such
language is called LML, or Lazy ML.  Current language definitions tend to
concentrate on the novel features rather than attempt to make LML a full-blown
"production" language, and therefore may be missing some of your favorite
features.  However, my point is that we may well be closer to your objective
than some of us realize.

I apologize for the brevity of this article -- if I have been too vague,
send me e-mail and I will be more specific.
--
Doug Pase   --   ...ucbvax!tektronix!ogcvax!pase  or  pase@Oregon-Grad.csnet