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:
>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.

Wearing another hat:  Haskell type classes are one approach to this.

>One choice is to write a function that takes Longest_Integer, or
>whatever, but then you have a bunch of bogus type conversions

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.

>A type conversion ought to tell the reader "I'm going outside
>the type system, doing something questionable, read this carefully."
>But if you have a lot of "harmless" type conversions, it weaken the
>effect -- it's like crying wolf.

The point is, the author of the function cannot tell that it is harmless.
I guarantee you, if I have derived a new integral type, the chances are
pretty good that the *last* thing I want is your function automatically
being applicable.  If I wanted that, I'd use Integer.  In fact, I would
be happier if there were some simple way to switch off a lot of the
built-in Ada stuff.

>Another choice is to use a generic.  This require even *more* excess
>verbiage (all kinds of instantiations).  And it can lead to code bloat
>on most implementations.

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.

As for code bloat, we've had that in another thread.

	function Real_Foo(X: Longest_Integer) return Bar is
	... begin ... end;

	generic
	    type Number is range <>;
	function Generic_Foo(X: Number) return Bar;

	function Generic_Foo(X: Number) return Bar is
	    pragma Inline(Foo);
	begin
	    return Real_Foo(Longest_Integer(X));
	end;

Presto chango:  no bloat.  You get the same code you would have got
from writing the explicit conversions.  There is only one copy of
the real procedure.  I appreciate that this is compiler-dependent, but
even *C* compilers are automatically inlining things these days, and
GNAT can do this.

 The instantiation is no more than

	function Foo is new Generic_Foo(Integer);
	function Foo is new Generic_Foo(My_Derived_Integer);

which is not a _lot_ of verbiage to warn human beings that there is
an operation available for a type, an operation they might not otherwise
have been aware or OR WANTED.  If I minded trading a bit of verbosity for
a lot of confidence I wouldn't be using Ada.

This approach offers

 - type safety:  the operation cannot be forced on clients that don't
   authorise it
 - compact calls:  no conversions appear in the calls to Foo
 - no code bloat:  there is only one Real_Foo function

-- 
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.