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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,791ecb084fdaba75 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-09-29 04:00:29 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Types with physical dimension Date: 29 Sep 1994 00:11:00 -0400 Organization: Courant Institute of Mathematical Sciences Message-ID: <36deok$dce@gnat.cs.nyu.edu> References: NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-09-29T00:11:00-04:00 List-Id: "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 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 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.