Re: Two ideas for the next Ada Standard

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

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.