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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b47b15fda2aeb0b2 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/06 Message-ID: <50opma$kos@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 178843550 references: <50aao3$3r88@news-s01.ny.us.ibm.net> <50gelc$2le@goanna.cs.rmit.edu.au> <50jk0f$krh@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-09-06T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: >I don't understand this. When you write "type T is range 1..1000;" in a >package spec, you're allowing all clients to do anything you can do to >integers. NONONONO. *You're* writing the package. You're the one writing the universal-integer function, remember? *I'm* writing the client. I am defining T for my own use, *not* for export. My package is "with"ing yours, and I *don't* want your code getting its paws on my T. *IF* I exported a derived integer type, then I agree that it would be up to the client to decide what to do with it. That is, if I didn't say "only use the following operations". That's one of the things I like about the old Russell type system: you can derive a new type by weakening. I can say "T is integer except that it doesn't have these operations." >This includes add, multiply, subtract, 'Image, and all the >other built in stuff, That is indeed a weakness in Ada. It should be possible to exclude such things. It is presently possible to do that by exporting a private type and replicating all and only the things I _do_ want to offer, so I don't call it a defect. >If you think gcd is an evil thing to do on type T, then you should make it >private instead. I do. I *still* don't want to get some function I've never heard of and isn't listed in the standard *automatically* being applicable to an internal type I have no intention of exporting. >You're confusing the abstraction and the client of the abstraction. If >the abstraction exports an integer type, the *client* can instantiate >whatever generics it wants, that take integer types. The abstraction >gave that permission by saying "is range 0..100". The only way to >prevent that is to use a private type. No, I'm not confused. *You* are making up this stuff about exporting an integral type, which has no relevance to my point. *You* are the one trying to export a function which will grab control over any integral type in view, and I don't want that happening inside my package body to stuff I have no intention of exporting, not without my say-so. >I don't understand what you mean by "forced on". If I call "gcd(I, J)", >that doesn't mean I'm forced to do so. Think about the possibilities for masking errors. Think about Beaujolais effects. > function gcd is new generic_gcd(my_int); > ... > gcd(I, J) >doesn't provide any extra type safety, as far as I can see. It just >requires several times as many tokens for no good reason. Well, _I_ can see the extra type safety. You were talking about a function that applies to _any_ integer type. GCD only really makes sense when I and J are the same kind of integer. You would have this go through if I were Short_Integer and J were Long_Integer; if I want that kind of sloppiness I know where to find it. There are other possibilities too. >It's the >abstraction that ought to be doing the "authorizing", not the client. It should be both. A legal contract, after all, requires *both* 'offer' (the abstraction) and 'acceptance' (the client). -- Australian citizen since 14 August 1996. *Now* I can vote the xxxs out! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.