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/03
Message-ID: <Dx5zH4.2zo@world.std.com>#1/1
X-Deja-AN: 178219256
references: <50aao3$3r88@news-s01.ny.us.ibm.net> <dewar.841590835@schonberg>
 <322B5BB0.422E@joy.ericsson.se> <50gelc$2le@goanna.cs.rmit.edu.au>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-09-03T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <50gelc$2le@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>This puzzles me greatly.  I've been hacking Ada for about two years now,
>and *except when trying to interface to C code* find that I have very
>few conversions. ...

I gave an example in another post.

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 -- e.g.
a function that converts an integer to a string.  (I know 'Image does
that, but it does it wrong -- it leaves an extra space, and it doesn't
support hexadecimal, interspersed commas (as in 1,000,000), etc.)

One choice is to write a function that takes Longest_Integer, or
whatever, but then you have a bunch of bogus type conversions at all the
call sites.  These type conversions are just extra verbiage in my
opinion.  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.

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.

Another choice is to declare a root integer type, and declare the
function as primitive of that type, and inherit that function for all
your integer types.  But this requires everything to be derived from a
single root type, which inhibits code reuse.

Another choice is to use subtypes instead of types.  This reduces the
number of type conversions needed, but also reduces the amount of type
checking.

>Hmm.  It would be interesting to determine the preferences of
> - people whose native language is SVO, like English
>    Prediction: subject.method(object) preferred.
>
> - people whose native language is VSO
>    Prediction:  method(subject, object) preferred
>
> - people whose native language is SOV (isn't Japanese like that?)
>    Prediction:  somewhere in between the others.

I doubt it.  Programming languages are so different from natural
languages that I don't believe the above predictions.  FWIW, I'm a
counter example (native language is English, but prefer method(args).
I suspect there's more cross-over from grade-school math notations to
programming notations, than from one's native language.

>To some extent this is true, but as someone who uses GNAT every day
>I don't want to see too much of Robert Dewar's time diverted from 
>enhancing an already *wonderful* tool.  And his postings are already
>darned productive (even when he disagrees with me).

I suspect he has two keyboards on his desk, and fixes bugs in GNAT with
his right hand, while simultaneously posting to comp.lang.ada with his
left hand.

- Bob