Re: Ada exception block does NOT work?

["Frank J. Lhota" <NOSPAM.FrankLho@rcn.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcck6ig89oz.fsf@shell01.TheWorld.com...
> ...
>
> Agreed.  And to some folks, "pointer" implies "you can do arithmetic on
> it" (i.e. C-style pointers).
>
> There's no uniform terminology across programming languages.
> That's not surprising, given that programming language design
> is such a new art.

This lack of uniform terminology can cause confusion. For example, what does 
"package" mean? In some languages, a package is little more than a name 
space. In Ada, it is something far more substantial.

>>... It certainly does not hurt to introduce a new term
>> to avoid potential misunderstandings.
>
> I think it does hurt to introduce new terms -- we end up with 37
> different ways of referring to the same thing (and folks who talk about
> "methods" have trouble communicating with folks who talk about
> "procedures" and so on).

I'm in full agreement with the notion that new terms should not be 
introduced unless they represent new concepts. The arguments over "throw" 
versus "raise", "catch" versus "handle" are silly, and divert attention from 
the real issues.

> True.  But they're pretty close.  The both "point at" or "refer to"
> things.  There are differences in which ones you can copy and whether
> dereferencing is explicit or implicit and so on.
>
> Interesting that we "dereference" pointers.  ;-)
> As opposed to "depointering" them.

The English language is full of such quirks, even outside of programming. 
Why do we drive on the parkway and park on the driveway?

> ...
>> For the record, I know of no Pascal compiler that implements a pointer as
>> anything other than a machine address.
>
> That's true.  And almost all Ada compilers use single-machine-address
> to represent almost-all access types.

At least major Ada compiler, GNAT, does use "fat" pointers for accessing 
unconstrained arrays unless forbidden by representation clauses.

> ...
>> Now that is an interesting concept. I am fond of divorcing the language 
>> from
>> platform constrains when practical. There are, however, some practical
>> concerns about this proposal. An Ada 'bignum' type would undoubtedly be a
>> controlled type, introducing more overhead than one would expect in a 
>> scalar
>> type.
>
> Well, one has to learn what to "expect" in terms of efficiency.
>
> In a garbage-collected implementation of Ada, bignum would not need to
> be a controlled type.
>
> If I said "1..2**80", I would "expect" 3 words to be allocated typically
> on the stack, with no heap usage, and no need for either controlled
> types or GC.  If I said "1..2**1000", I would expect heap usage, and
> consequent controlled types or GC.  If I'm writing a hard real-time
> embedded system, I probably won't say "1..2**1000".
>
> But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
> of, and I can't even count on "1..2**35" portably.  Sigh.

Good point. I like the idea of being able to create a new integer type 
without concern over details such as machine representation.

> - Bob