Re: Is this expected behavior or not

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Shark8" <onewingedshark@gmail.com> wrote in message 
> news:87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com...
> ...
>> Hm, true; speaking of object-attributes I sometimes [though not too often]
>> wish I could write something like:
>> Procedure X( Input : Some_Type ) is
>>  Temp : Input'Type := Some_Value;
>> begin
>>  -- Whatever needs done.
>> end X;
>>
>> Is there any reason that should be disallowed / would be difficult for 
>> compiler-writers to implement?
>
> I've occassionally had such a thought, too.

Me, too.  (I also agree with Shark8's "not too often" comment.)

Many languages allow the type of an object to be deduced from
its initial value.  I believe C++ recently added that feature,
using the "auto" keyword (which it inherited from C, and meant
something completely different -- and completely useless).
Ada allows that in a small way -- named numbers.

>... Probably the reason this doesn't 
> exist is that Ada 83 didn't have type-valued attributes and thus it wasn't 
> considered there.

I suspect the reason was that the designers of Ada 83 thought that
types of things ought to be explicit.  Except for named numbers --
consistency wasn't their strong suit.

> 83). There would potentially be a cost to an object attribute vs. using the
> subtype name directly, in that the prefix would have to be evaluated (which,
> if it included function calls or checks, would generate some code).

Such cases could be forbidden.

Or one could do something like what C does for sizeof -- the operand
is not evaluated.  It's as if you could say "X.all'Size" in Ada and
not get a C_E, even if X = null.  That works in C because all sizes
are known at compile time.  In Ada, all types are known at compile
time, so "X.all'Type" (or "X.all'Subtype"?) could conceivably denote
Integer even when X = null.

> It's not clear that there is any problem here, it's just that we haven't 
> considered it and usually that means there is a problem there. :-) Could 
> just be FUD, too.

Well, a bit of FUD is often appropriate in language design.  ;-)

- Bob