comp.lang.ada
 help / color / mirror / Atom feed
From: ucaa2385@iris3.csv.ica.uni-stuttgart.de (Peter Hermann)
Subject: Re: Types with physical dimension
Date: 29 Sep 1994 11:19:43 GMT
Date: 1994-09-29T11:19:43+00:00	[thread overview]
Message-ID: <36e7sf$19ql@info2.rus.uni-stuttgart.de> (raw)
In-Reply-To: 36deok$dce@gnat.cs.nyu.edu

Robert Dewar (dewar@cs.nyu.edu) wrote:
: "Of course it would be nice to have more direct support for units"

: In the "of course" here likes a rather fundamental assumption which I
: question, namely that it is always desirable to have features at hand
: that do exactly what you want in the most convenient way. While that
: may seem locally optimal, I am afraid that following this inclination
: repeatedly leads to too much complexity in language design. Remember
: that a reader must be able to read the code, that means that a reader
: has to be able to pretty much understand the whole language since there
: is no restriction on what the writer can write. A big language is not

agreed. The reader would be "overloaded".
but (see below)

: so bad from the writer's point of view, since you only learn what you
: need, but from the reader's point of view, the complexity is much
: harder to handle.

: To me, the units case crosses the line. I think you can build this well enough

Because you are involved in compiler construction?  ;-) :-)

: in Ada, esp in Ada 9X with the abstract feature, and I think that (even
: given infinite resources :-) it would be a mistake to add an additional
: (inevitably somewhat complex) feature that would handle this more
: directly.

I don't see it necessarily as an add-on feature like another "rucksack".
Ada has done a good job to prevent semantic errors.
I think however, that for Ada2000+ there are still reserves
which are not digged out in the abstraction process.
I am feeling that there must be better methods
which fit smoothly into a language concept.
A good solution would bring another major step 
in the abstraction process.

Today, we are able to prevent an expression like
meter times meter giving meter.   (you may substitute inch for meter :-)
We may allow meter times meter giving an_area_type.
The tools are here but certainly only rarely used.

Did I tease your phantasy?

The problem is with any language. We need some words to 
communicate but the optimal set is seldom reached.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)



  reply	other threads:[~1994-09-29 11:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <GRAHAM.94Sep27181841@canopus.clsi.com>
1994-09-28 17:36 ` Types with physical dimension William Brennan
1994-09-28 21:41 ` Tucker Taft
1994-09-29  4:11   ` Robert Dewar
1994-09-29 11:19     ` Peter Hermann [this message]
1994-09-30 10:17       ` Dr John Stockton
1994-10-03  4:37       ` Robert Dewar
1994-09-29 13:37     ` Tucker Taft
1994-10-03  4:40       ` Robert Dewar
1994-09-28 19:28 Paul Pukite
  -- strict thread matches above, loose matches on Subject: below --
1994-09-28 10:55 Simtel20 Transfer
1994-09-28 18:56 ` Mark A Biggar
1994-10-04  2:06 ` lmiller
1994-09-27 22:18 Paul Graham
1994-09-28 13:59 ` Robert Dewar
1994-09-30  2:06   ` R_Tim_Coslet
1994-10-03 17:31 ` Stephen A. Leake
1994-10-04 11:51   ` Robert I. Eachus
1994-10-04 19:45     ` Mark A Biggar
     [not found]       ` <CxBBx8.7L@irvine.com>
1994-10-13 22:15         ` gamache
1994-10-12  3:43     ` Matt Kennel
1994-10-04 14:56   ` Robert Dewar
1994-10-05 14:53     ` Bob Gilbert
1994-10-05  8:38   ` Jean-Pierre Rosen
1994-10-05 10:35     ` Stephen J Bevan
1994-10-05 13:17       ` Jean-Pierre Rosen
1994-10-05 15:48     ` Norman H. Cohen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox