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: bobduff@world.std.com (Robert A Duff) Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/05 Message-ID: #1/1 X-Deja-AN: 178562658 references: <50aao3$3r88@news-s01.ny.us.ibm.net> <50gelc$2le@goanna.cs.rmit.edu.au> <50jk0f$krh@goanna.cs.rmit.edu.au> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-09-05T00:00:00+00:00 List-Id: In article <50jk0f$krh@goanna.cs.rmit.edu.au>, Richard A. O'Keefe wrote: >bobduff@world.std.com (Robert A Duff) writes: >>Another example is: You can't write a function that takes a parameter of >>"any integer type". This is a perfectly reasonable thing to do > >Wearing my Lisp hat: only because Ada doesn't actually support integers, >but a machine-dependent set of machine-dependent small bounded integers. That seems like an orthogonal issue. One could imagine a language like Ada, where the potential range of integers was essentially infinite, but the type model would still be the same. >Wearing another hat: Haskell type classes are one approach to this. Yes. >Well, yes, but when I use derived integer types in my Ada code, >it's because I _don't_ want to allow a whole lot of functions. >I _want_ those conversions to be required, because I _don't_ want >other people's functions coming in unless I say so. 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. This includes add, multiply, subtract, 'Image, and all the other built in stuff, plus anything you can build on top of those things. For example, a client of this package can write a function to take the greatest common divisor (gcd) of two things of type T. If you think gcd is an evil thing to do on type T, then you should make it private instead. Whether gcd is written specifically for type T (by the client), or as a generic instantiation, or if there's a gcd-of-any-integer-type (not Ada!) available shouldn't matter -- you can't *prevent* the client from doing a gcd operation on this type, because you've exported the fact that it's an integer type. >Well, you may call it excess verbiage: I call it not letting you >violate my privacy unless I give you explicit permission. It may >be "excess", but it's only one or two lines, and I really value having >that explicit indication of what unusual things may be going on. 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. >This approach offers > > - type safety: the operation cannot be forced on clients that don't > authorise it 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. And making me write: 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. It's the abstraction that ought to be doing the "authorizing", not the client. Don't get me wrong -- I'm all for verbosity when it serves a useful purpose (as it usually does in Ada). - Bob