Re: Bus error

[Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de>]

Dmitry A. Kazakov wrote:
> On Fri, 29 Jun 2007 17:44:22 +0200, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Fri, 29 Jun 2007 11:35:28 +0200, Duncan Sands wrote:
>>>
>>>> in Ada 95 you could do
>>>>
>>>> 	X : T renames Factory;
>>> Yes, you're right. It should be illegal. Semantically it is same as
>>>
>>>    X : Integer renames 1; -- Illegal
>> I don't think that renaming an object is the same as renaming
>> a number literal because the literal isn't declared anywhere.
>> Wheras I could say that a returned object is declared as part
>> of the function declaration.
> 
> Oh, if that is a problem then take this instead:
> 
>     X : Integer renames -1; -- Still illegal, though not a literal

If I had anything to contribute, my programming language
would never have elementary school writing modes built in because
this triggers these kinds of discussions.


> But clearly your argument is nonsensical, literal is a syntactic element,
> of which semantics is as much object as any of any other expression.

If the semantics of object renaming is that an object is renamed,
and a number literal is somehow not an object, I see a difference.

If we can have renamings of expressions, OK, let us have let bindings;
However, what is their 'Access? 


> It
> would be a very perverse idea to try to draw a line between literals and
> non-literals.

What is a possible alternative?


> Note also that Ada's renaming has conceptually little to do
> with objects. Consider:
> 
>    X : T;
>    X : T renames X; -- Illegal
> 
> though the "object" is obviously same. Same object, same name, what was
> wrong?

A programmer construing strange assumptions about the possibility of
duplicate names in a declarative part of an Ada program, I'd say.


>>>    function Very_Positive return Integer is
>>>    begin
>>>        return -1;
>>>    end Very_Positive;
>>>
>>>    Oops : Positive renames Very_Positive; -- This is OK!
>> So is
>>
>>   if 42 not in Boolean'pos(false) .. Boolean'pos(true) then
>>       raise Constraint_Error;
>>   end if;
> 
> You missed the point. The renaming in my example shall *not* raise
> Constraint_Error. It is a clear language design fault.

Oops will at some point raise Constraint error; how can a compiler
be supposed to known that some Integer function will *always*
return non-Positives? What makes you think that the programmer
who has written the Oops doesn't know what he is
doing using a subtype, not a new type?

I think it is a program design fault, if a fault at all (or a flaw as
Bub Duff notes). Subtypes are not new types, a compiler is not a
program proof program, and less so when the programmer writes about
overlapping value ranges, not types.

For contrast,

   Whatever: Boolean renames Halt(Main'access);  -- legal

(Make Halt an ASIS function that can call the compiler if you like.)