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/04 Message-ID: <50jk0f$krh@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 178401769 references: <50aao3$3r88@news-s01.ny.us.ibm.net> <322B5BB0.422E@joy.ericsson.se> <50gelc$2le@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-09-04T00:00:00+00:00 List-Id: 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.