Re: Bus error

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 30 Jun 2007 15:14:39 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 29 Jun 2007 17:44:22 +0200, Georg Bauhaus wrote:
>> 
>> 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.

Which one? What is in your theory a difference between:

   A : constant := 1;
   B : constant Integer := 1;
   C : Integer renames A;
   D : Positive renames B;

Can you tell without much thinking which renaming is correct above?

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

Huh, but it is OK to take 'Access from a renaming!

   X : aliased Integer;
   Y : Integer renames X;
   Y_Ptr : access Integer := Y'Access;

Note also that Ada has subroutine's implementation through renaming and,
again, such implementations have 'Access. You should really fix your
theory.

>> It
>> would be a very perverse idea to try to draw a line between literals and
>> non-literals.
> 
> What is a possible alternative?

As Robert Duff have said, there should be no any difference. Especially to
have user-defined literals and aggregates.
 
>> 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.

Where do you see duplicated names?  Is bare name an object? Observe that X
referred to exactly same object, if the theory were correct. But apparently
the theory is wrong, and in fact X : T renames X; produces something else.

>>>>    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?

It is not about the time point a check would happen, it is about absence of
any check. Constraint_Error will *never* be raised. This actually defeats
the purpose of subtypes in helping the compiler to omit checks when Oops
would be used in a context where a Positive is expected. It can do that for

    Oops : Positive := Whatever;

but it cannot for renaming, because "Positive" there is a lie.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de