Re: AW: Bus error

Re: AW: Bus error

[Duncan Sands]

> > ... one objection against Ada 2005 design is that now it is impossible
> to > have types which objects were strictly temporal, i.e. to prevent
> creation > of variables. Consider this:
> >
> > [  type T (<>) is limited private; ]
> >
> >   X : T := Factory; -- Was illegal in Ada 95
> >
> >   Foo (Factory); -- That's OK

in Ada 95 you could do

	X : T renames Factory;

Ciao,

Duncan.

Re: Bus error

[Dmitry A. Kazakov]

On Fri, 29 Jun 2007 11:35:28 +0200, Duncan Sands wrote:

>>> ... one objection against Ada 2005 design is that now it is impossible
>> to > have types which objects were strictly temporal, i.e. to prevent
>> creation > of variables. Consider this:
>>>
>>> [  type T (<>) is limited private; ]
>>>
>>>   X : T := Factory; -- Was illegal in Ada 95
>>>
>>>   Foo (Factory); -- That's OK
> 
> 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

For fun:

   Y : Integer renames 1+1; -- Illegal
   Z : Integer renames "+"(1,1); -- Legal!

   function Very_Positive return Integer is
   begin
       return -1;
   end Very_Positive;

   Oops : Positive renames Very_Positive; -- This is OK!

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

Re: Bus error

[Markus E Leypold]

Dmitry said:
> On Fri, 29 Jun 2007 11:35:28 +0200, Duncan Sands wrote:
>
>>>> ... one objection against Ada 2005 design is that now it is impossible
>>> to > have types which objects were strictly temporal, i.e. to prevent
>>> creation > of variables. Consider this:
>>>>
>>>> [  type T (<>) is limited private; ]
>>>>
>>>>   X : T := Factory; -- Was illegal in Ada 95

<snipped>

>> in Ada 95 you could do
>> 
>> 	X : T renames Factory;

> Yes, you're right. It should be illegal. Semantically it is same as


So there never was a feature "to have types which objects were
strictly temporal". You just changed your agenda.

Regards -- Markus

Re: Bus error

[Georg Bauhaus]

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.
 
 
>    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;

Subtypes don't create new types in Ada. I wonder why you
keep pretending they do?

It is a mistake is to have predifined numeric types in a language
because this invites all kinds of assumptions about numeric types.

Re: Bus error

[Dmitry A. Kazakov]

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

But clearly your argument is nonsensical, literal is a syntactic element,
of which semantics is as much object as any of any other expression. It
would be a very perverse idea to try to draw a line between literals and
non-literals. 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?

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

Renaming is completely broken in Ada. It creates new objects, it violates
contracts, it introduces names conflicts.

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

Re: Bus error

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> You missed the point. The renaming in my example shall *not* raise
> Constraint_Error. It is a clear language design fault.

Right -- the fact that "X: T renames ..." completely ignores the
constraints on T is a flaw.  There are language-lawyerly reasons for
it...

> Renaming is completely broken in Ada.

A little bit broken.

>...It creates new objects,

Heh?  Renaming does not create new objects.

A function call creates a new object, but that's a
different story.  And it's a good thing -- that function-result
object might need to be finalized, which means it has to be
an object (not just a value).

If I ran the circus, literals would "return" objects, too.
And there would be no syntactic distinction betweem "name"
and "expression".

>... it violates
> contracts,

Not sure what you mean there.  I guess the fact that constraints on T
are ignored, above.  If so, it doesn't violate any contract, so long as
you understand that "X: Positive renames..." is not a contract requiring
positive numbers.  ;-)

>...it introduces names conflicts.

Yes.  We considered fixing that during Ada 9X.

Here's another small complaint about renaming: It's often used as an
"import", as in:

    function Blah (...) return ... renames Some.Library.Package.Blah;

We do not wish to change the name of Blah, just to import it into
another scope.  But mentioning Blah twice is error-prone in that
context.  The programmer really wants to say something like
"import Blah from Some.Library.Package".  Consider:

    function "+"(...) return ... renames Some_Package."+";
    function "-"(...) return ... renames Some_Package."+";

Note cut&paste error on second line.

- Bob

Re: Bus error

[Dmitry A. Kazakov]

On Fri, 29 Jun 2007 21:37:43 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>>...It creates new objects,
> 
> Heh?  Renaming does not create new objects.

> A function call creates a new object, but that's a
> different story.  And it's a good thing -- that function-result
> object might need to be finalized, which means it has to be
> an object (not just a value).

The language misguiding the programmer here. He should declare an
initialized constant when a function result is "renamed," it is not
renaming, At least it is not just renaming happens here.

If you have

   X1 : String renames Get_Line;
   X2 : String renames Get_Line;
   X3 : String renames Get_Line;

the effect will be X1, X2, X3 all different objects. This should not be
called renaming.

Same is implementation of subprograms through renaming, which also creates
a new object.

But when I do:

   X : Element renames Collection (Key);

I'd like to be certain that X indeed renames a container's element.

> If I ran the circus, literals would "return" objects, too.
> And there would be no syntactic distinction betweem "name"
> and "expression".

Sign me up!

>>... it violates
>> contracts,
> 
> Not sure what you mean there.  I guess the fact that constraints on T
> are ignored, above.  If so, it doesn't violate any contract, so long as
> you understand that "X: Positive renames..." is not a contract requiring
> positive numbers.  ;-)

(:-)) The problem is then, what the meaning has the subtype specification
in renaming?

Nobody would object if renaming were:

   This : renames That;  -- Guess what is the subtype and constraints

Interestingly, but the "constant" (in/out/in out) constraint indeed need
not to and cannot be specified in renaming:

   X : Integer renames Y;

So whatever naive theory we'd invent Ada's renaming conforms to neither.

>>...it introduces names conflicts.
> 
> Yes.  We considered fixing that during Ada 9X.

But not 200X?

> Here's another small complaint about renaming: It's often used as an
> "import", as in:
> 
>     function Blah (...) return ... renames Some.Library.Package.Blah;

Yep, and the diamond diagram:

package A is
   X : T;
end A;

with A;
package B is
   X : T renames A.X;
end B;

with A;
package C is
   X : T renames A.X;
end C;

with B, C; use B, C;
package D is
   -- X is hidden
end D;

> We do not wish to change the name of Blah, just to import it into
> another scope.  But mentioning Blah twice is error-prone in that
> context.  The programmer really wants to say something like
> "import Blah from Some.Library.Package".  Consider:
> 
>     function "+"(...) return ... renames Some_Package."+";
>     function "-"(...) return ... renames Some_Package."+";
> 
> Note cut&paste error on second line.

Yes, there is no mechanism to merge declaration parts of packages. IMO
there should be some way to import things of one package specification into
another without tedious renamings, especially, without renaming things
which cannot be renamed at all, like types. But I don't think that renaming
should be used for that. I would prefer multiple parent packages and
something for flattening nested and separate packages:

package My_IO is
   ...
   with new Ada.Text_IO.Integer_IO (...);
      -- Merge all declarations from this instance with My_Io's public
      -- and private parts

----------------
There are three separate issues too difficult to handle by just one
construct:

1. Renaming of objects
2. Operations on packages specification
3. Delegation

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

Re: Bus error

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Fri, 29 Jun 2007 21:37:43 -0400, Robert A Duff wrote:

> If you have
> 
>    X1 : String renames Get_Line;
>    X2 : String renames Get_Line;
>    X3 : String renames Get_Line;
> 
> the effect will be X1, X2, X3 all different objects. This should not be
> called renaming.
 

There happen to be no explicit arguments in the function calls.
Does the same reasoning apply to

    X1 : String renames Get_Line(Foo);
    X2 : String renames Get_Line(Bar);
    X3 : String renames Get_Line(Baz, Mode => Frobnicate);


> But when I do:
> 
>    X : Element renames Collection (Key);
> 
> I'd like to be certain that X indeed renames a container's element.

Then I think there is a problem of choosing the right name for
what you have called Collection here. Ada not being a declarative
language, and if Collection is a function, then the name of the
function should probably indicate what the function *does* if and
when you do care about how it achieves some purpose.
Something like Get_From_Collection(Key) seems more likely a good
name in this case.

I'd agree that there is a "reading level ambiguity" in

   X : Data_Type renames Fun_Call_Result;
and
   X : Fun_Decl renames Another_Fun;


> package My_IO is
>    ...
>    with new Ada.Text_IO.Integer_IO (...);
>       -- Merge all declarations from this instance with My_Io's public
>       -- and private parts

Which IMHO defeats the purpose of well designed packages: focus on one
thing. (A two dozen years old package like Text_IO formed around various
assumptions might serve to construct an exception.)
Why not use interfaces when you need to lump things together? Do you have
a few convincing examples that show how the decoupling of modules should
be "improved" with a mechanism of merging them into one? (That is, of
importing and reexporting declarations of entire packages.)

Re: Bus error

[Georg Bauhaus]

Georg Bauhaus wrote:

> I'd agree that there is a "reading level ambiguity" in
> 
>   X : Data_Type renames Fun_Call_Result;
> and
>   X : Fun_Decl renames Another_Fun;

Ups. You get the idea.

Re: Bus error

[Dmitry A. Kazakov]

On Sat, 30 Jun 2007 13:52:22 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 29 Jun 2007 21:37:43 -0400, Robert A Duff wrote:
> 
>> If you have
>> 
>>    X1 : String renames Get_Line;
>>    X2 : String renames Get_Line;
>>    X3 : String renames Get_Line;
>> 
>> the effect will be X1, X2, X3 all different objects. This should not be
>> called renaming.
>  
> There happen to be no explicit arguments in the function calls.
> Does the same reasoning apply to
> 
>     X1 : String renames Get_Line(Foo);
>     X2 : String renames Get_Line(Bar);
>     X3 : String renames Get_Line(Baz, Mode => Frobnicate);

These examples show that the concept is just wrong. The above creates some
anonymous objects in background and then renames them. How to rename
something that does not have any name?

>> But when I do:
>> 
>>    X : Element renames Collection (Key);
>> 
>> I'd like to be certain that X indeed renames a container's element.
> 
> Then I think there is a problem of choosing the right name for
> what you have called Collection here.

Collection is a container, like an array, Key is an index. Is this better:

   Slice : String renames Line (10..20);

>> package My_IO is
>>    ...
>>    with new Ada.Text_IO.Integer_IO (...);
>>       -- Merge all declarations from this instance with My_Io's public
>>       -- and private parts
> 
> Which IMHO defeats the purpose of well designed packages: focus on one
> thing. (A two dozen years old package like Text_IO formed around various
> assumptions might serve to construct an exception.)
> Why not use interfaces when you need to lump things together? Do you have
> a few convincing examples that show how the decoupling of modules should
> be "improved" with a mechanism of merging them into one? (That is, of
> importing and reexporting declarations of entire packages.)

Yes, I have examples. You can take a look at 

http://www.dmitry-kazakov.de/ada/fuzzy.htm

and figure out how to instantiate a network of generic packages kicked off
by just one actual generic parameter (floating-point type).

Soon you will package that all in bundle packages like:

generic -- Just instantiates things
   type (Number) is ...;
package Bundle is
   package X1 is new Foo (Number);
   package X2 is new X1.Bar;
   package X4 is new X1.Baz (X2.Bar);
   package X5 is new X4...;
   ...
end Bundle;

These proxy packages introduce new names like X1, X2 etc which nobody
actually needs. To "use" Bundle is meaningless. You have to use those Xn
from there. If you have 20 generic packages and 5 different instantiation,
the result is a horribly mess. I would reward with the Nobel Prize anybody
who could propose a working naming convention schema for these Xn.

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

Re: Bus error

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Sat, 30 Jun 2007 13:52:22 +0200, Georg Bauhaus wrote:
> 
>>
>>     X1 : String renames Get_Line(Foo);
>>     X2 : String renames Get_Line(Bar);
>>     X3 : String renames Get_Line(Baz, Mode => Frobnicate);
> 
> These examples show that the concept is just wrong. The above creates some
> anonymous objects in background and then renames them. How to rename
> something that does not have any name?

Again, this is a wording question I think. I see value in labelling
an object with a name when the language lets me do this (and I don't
want to assign to a local constant).

 
>>> But when I do:
>>>
>>>    X : Element renames Collection (Key);
>>>
>>> I'd like to be certain that X indeed renames a container's element.
>> Then I think there is a problem of choosing the right name for
>> what you have called Collection here.
> 
> Collection is a container, like an array, Key is an index. Is this better:
> 
>    Slice : String renames Line (10..20);

And you want to be sure that Line (10 .. 20) indeed renames
a character string of the array?


> Yes, I have examples. You can take a look at 
> 
> http://www.dmitry-kazakov.de/ada/fuzzy.htm

I'm starting to see why you are upset about generics.
This will take some time to understand.

Re: Bus error

[Robert A Duff]

Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de> writes:

> Again, this is a wording question I think. I see value in labelling
> an object with a name when the language lets me do this (and I don't
> want to assign to a local constant).

I think compilers really ought to generate identical code for:

  X3 : String renames Get_Line(Baz, Mode => Frobnicate);

and:

  X3 : constant String := Get_Line(Baz, Mode => Frobnicate);

so the choice is purely aesthetic.

- Bob

Re: Bus error

[Dmitry A. Kazakov]

On Sat, 30 Jun 2007 20:07:45 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:

>>    Slice : String renames Line (10..20);
> 
> And you want to be sure that Line (10 .. 20) indeed renames
> a character string of the array?

If that is called renaming.

Note, that there are three independent concepts intermixed in Ada's
renaming:

1. Alias names
2. Temporal objects
3. Delegation

If Slice is a proxy object to Line delegating its operations to Line, then
why is it called renaming? Why is it String? (in fact it is some anonymous
thing from String'Class)

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

Re: Bus error

[Robert A Duff]

Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de> writes:

> Which IMHO defeats the purpose of well designed packages: focus on one
> thing. (A two dozen years old package like Text_IO formed around various
> assumptions might serve to construct an exception.)
> Why not use interfaces when you need to lump things together? Do you have
> a few convincing examples that show how the decoupling of modules should
> be "improved" with a mechanism of merging them into one? (That is, of
> importing and reexporting declarations of entire packages.)

I run across such cases fairly often.

Suppose I say:

    package P is
        type Int is range 1..10;
        type Int_Array is array (...) of Int;
        ...
    end P;

Clients that say "use P;" have visibility on two types, plus all kinds
of operations on those types (such as "=" on Int_Arrays).

Now suppose I want a growable array instead:

    with ...;
    package P is
        type Int is range 1..10;
        package Int_Vectors is new Ada.Containers.Vectors(Int, ...);
        ...
    end P;

Now clients have to say "use P, P.Int_Vectors;" to get visibility on all
the relevant operations.  Or else P has to rename whole bunch of stuff.

- Bob

Re: Bus error

[Georg Bauhaus]

Robert A Duff wrote:
> 
> Suppose I say:
> 
>     package P is
>         type Int is range 1..10;
>         type Int_Array is array (...) of Int;
>         ...
>     end P;
> 
> Clients that say "use P;" have visibility on two types, plus all kinds
> of operations on those types (such as "=" on Int_Arrays).
> 
> Now suppose I want a growable array instead:
> 
>     with ...;
>     package P is
>         type Int is range 1..10;
>         package Int_Vectors is new Ada.Containers.Vectors(Int, ...);
>         ...
>     end P;
> 
> Now clients have to say "use P, P.Int_Vectors;" to get visibility on all
> the relevant operations.  Or else P has to rename whole bunch of stuff.

Ah. In these cases I stubbornly place Int and operations in their own
package. When another part of the program needs Int_Vectors in addition
to Int, they are made available in an additional package. Use as needed.
I'll probably write a seemingly artificial abstraction around
Int_Array when I want it to be similar to Int_Vectors.Vector. (But so far
have had no need to do so.)

Re: Bus error

[Jean-Pierre Rosen]

Robert A Duff a �crit :
>     function "+"(...) return ... renames Some_Package."+";
>     function "-"(...) return ... renames Some_Package."+";
> 
> Note cut&paste error on second line.
> 
Next version of AdaControl (hint: comming soon :-) has a 
"non_identical_renaming" rule that will spot this.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Bus error

[Dmitry A. Kazakov]

On Mon, 02 Jul 2007 10:01:00 +0200, Jean-Pierre Rosen wrote:

> Robert A Duff a �crit :
>>     function "+"(...) return ... renames Some_Package."+";
>>     function "-"(...) return ... renames Some_Package."+";
>> 
>> Note cut&paste error on second line.
>> 
> Next version of AdaControl (hint: comming soon :-) has a 
> "non_identical_renaming" rule that will spot this.

Great.

However, there is at least one quite specific case where renaming is indeed
renaming rather than flattening names.

How will AdaControl handle this:

type My_Integer is ...;
function Add (Left, Right : My_Integer return My_Integer renames "+";
function "+" (Left, Right : My_Integer return My_Integer;

Add is a renaming of the inherited implementation to use it later in the
custom implementation of "+".

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

Re: Bus error

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
>> Next version of AdaControl (hint: comming soon :-) has a 
>> "non_identical_renaming" rule that will spot this.
> 
> Great.
> 
> However, there is at least one quite specific case where renaming is indeed
> renaming rather than flattening names.
> 
> How will AdaControl handle this:
> 
> type My_Integer is ...;
> function Add (Left, Right : My_Integer return My_Integer renames "+";
> function "+" (Left, Right : My_Integer return My_Integer;
> 
> Add is a renaming of the inherited implementation to use it later in the
> custom implementation of "+".
> 
AdaControl will do what it is asked to do :-).

Non_Identical_Renaming will tell you all renamings with a different name.
Non_Identical_Operator_Renaming will do the same, but only for operators.

Whether the occurrences of such constructs are errors or not is a matter 
of interpreting the output of the tool. If it is not an error, and you 
don't want to be bothered by messages anymore, you can disable the rule 
locally (i.e. put a special comment to prevent the output of the message).
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Bus error

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Robert A Duff a �crit :
>>     function "+"(...) return ... renames Some_Package."+";
>>     function "-"(...) return ... renames Some_Package."+";
>> Note cut&paste error on second line.
>>
> Next version of AdaControl (hint: comming soon :-) has a
> "non_identical_renaming" rule that will spot this.

Cool!

- Bob

Re: Bus error

[Georg Bauhaus]

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.)

Re: Bus error

[Dmitry A. Kazakov]

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

Re: Bus error

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 30 Jun 2007 15:14:39 +0200, Georg Bauhaus wrote:
>
>> Dmitry A. Kazakov wrote:
>>> 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.

I must say, I'm mystified as to what the above example is supposed
illustrate.  You can't have two declarations with the same name
(unless they are both overloadable).  The fact that they are both
names for the same object is irrelevant to THAT rule.

- Bob

Re: Bus error

[Dmitry A. Kazakov]

On Sat, 30 Jun 2007 11:34:16 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 30 Jun 2007 15:14:39 +0200, Georg Bauhaus wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> 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.
> 
> I must say, I'm mystified as to what the above example is supposed
> illustrate.  You can't have two declarations with the same name
> (unless they are both overloadable).  The fact that they are both
> names for the same object is irrelevant to THAT rule.

Declarations of what? That is the question. Allegedly, as the name of the
thing let suggest, "rename" does not declare anything [new]. Does "use"
declare something? Or is name an object?

If I designed rename, I would certainly allow X renames X; similarly to
"use" or "with" A, A;

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

Re: Bus error

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 30 Jun 2007 11:34:16 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sat, 30 Jun 2007 15:14:39 +0200, Georg Bauhaus wrote:
>>>
>>>> Dmitry A. Kazakov wrote:
>>>>> 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.
>> 
>> I must say, I'm mystified as to what the above example is supposed
>> illustrate.  You can't have two declarations with the same name
>> (unless they are both overloadable).  The fact that they are both
>> names for the same object is irrelevant to THAT rule.
>
> Declarations of what?

Well, the RM doesn't seem to care:

8 {homograph} Two declarations are homographs if they have the same
defining name, and, if both are overloadable, their profiles are type
conformant. {type conformance [partial]} [An inner declaration hides any
outer homograph from direct visibility.]

9/1 {8652/0025} [Two homographs are not generally allowed immediately
within the same declarative region unless one overrides the other (see
Legality Rules below).]...

>... That is the question. Allegedly, as the name of the
> thing let suggest, "rename" does not declare anything [new].

A renaming declaration is syntactically a declaration,
and it declares a name.  It does not declare a new entity.

>... Does "use"
> declare something?

No.  And it's not a declaration.

>... Or is name an object?

No.  But:

5 {Declaration} [Glossary Entry]A declaration is a language construct
that associates a name with (a view of) an entity. ...

7 {Definition} [Glossary Entry]{view} All declarations contain a
definition for a view of an entity. A view consists of an identification
of the entity (the entity of the view), plus view-specific
characteristics that affect the use of the entity through that view
(such as mode of access to an object, formal parameter names and
defaults for a subprogram, or visibility to components of a type). In
most cases, a declaration also contains the definition for the entity
itself (a renaming_declaration is an example of a declaration that does
not define a new entity, but instead defines a view of an existing
entity (see 8.5)).

> If I designed rename, I would certainly allow X renames X; similarly to
> "use" or "with" A, A;

OK, I think I see what you're getting at.  You would then say that
referring to X is legal (not ambiguous) because both of those
declarations of the name X refer to the same entity.  Right?

To make this work, you need to distinguish static and dynamic.

    X : Integer renames Func(...).all.Component(Func2(...));
    X : Integer renames Func(...).all.Component(Func2(...));

    X := X + 1; -- legal?

I don't think you want a run-time check that the two
names X denote the same entity!

FWIW, I would simply delete the no-duplicate-homographs rule.
And weaken the overload resolution rules.

- Bob

Re: Bus error

[Dmitry A. Kazakov]

On Sun, 01 Jul 2007 11:39:33 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>... Does "use"
>> declare something?
> 
> No.  And it's not a declaration.

So should be renaming, at least ideally, a pure name space thing. For LHS
and implementation by renaming it would be better to have some delegation
mechanism.

>> If I designed rename, I would certainly allow X renames X; similarly to
>> "use" or "with" A, A;
> 
> OK, I think I see what you're getting at.  You would then say that
> referring to X is legal (not ambiguous) because both of those
> declarations of the name X refer to the same entity.  Right?
> 
> To make this work, you need to distinguish static and dynamic.
> 
>     X : Integer renames Func(...).all.Component(Func2(...));
>     X : Integer renames Func(...).all.Component(Func2(...));

Illegal, for they denote different objects.

>     X := X + 1; -- legal?
> 
> I don't think you want a run-time check that the two
> names X denote the same entity!

Yes, of course. I would just match names. If the names match after
resolving all renamings, then the objects considered same. When they don't
match or do not resolve, then objects are considered different. This
becomes interesting with literals and aggregates which are names of
themselves. There exist a similar situation with matching signatures of
subprogram's declaration and implementation when arguments have defaults. I
forgot how it is solved there.

> FWIW, I would simply delete the no-duplicate-homographs rule.
> And weaken the overload resolution rules.

Yes. However, there still would remain the issues of checking the subtype
of the renamed thing and of proper renaming of types:

   type T is tagged private;
   procedure Foo (X : T); -- Primitive

   type S is private renames T;
    -- Hmm, is Foo primitive of S, would it dispatch? (:-))

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

Re: Bus error

[Robert A Duff]

Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de> writes:

> Dmitry A. Kazakov wrote:
>> On Fri, 29 Jun 2007 17:44:22 +0200, Georg Bauhaus wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>>    function Very_Positive return Integer is
>>>>    begin
>>>>        return -1;
>>>>    end Very_Positive;
>>>>
>>>>    Oops : Positive renames Very_Positive; -- This is OK!

> Oops will at some point raise Constraint error;...

Dmitry's complaint is the above will NOT raise C_E.
The subtype of Oops is Integer, not Positive,
and its value is -1.  Oops is a constant (even though
it doesn't say so).

The fact that "Positive" is completely ignored by the compiler is
clearly a language design flaw.

From AARM-8.5.1:

6 An object_renaming_declaration declares a new view [of the renamed
object] whose properties are identical to those of the renamed
view. [Thus, the properties of the renamed object are not affected by
the renaming_declaration. In particular, its value and whether or not it
is a constant are unaffected; similarly, the constraints that apply to
an object are not affected by renaming (any constraint implied by the
subtype_mark of the object_renaming_declaration is ignored).]

    6.a   Discussion: Because the constraints are ignored, it is a good
      idea
          to use the nominal subtype of the renamed object when writing
      an
          object_renaming_declaration.

>...how can a compiler
> be supposed to known that some Integer function will *always*
> return non-Positives?

Indeed!  Likewise, how is the _programmer_ supposed to know?

>...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).

Yes, I agree with you and with my evil twin Bub ;-) that it is a flaw in
the program.  The programmer should have written:

    Oops : Integer renames Very_Positive;

But it's exactly the sort of flaw that the compiler ought to be required
to detect, and give an error at compile time.  (Note that the compiler
doesn't need to look inside the body of Very_Positive to detect the
"flaw".)

Actually, the programmer really should have written:

    Oops : constant Integer := Very_Positive;

but that's a different story.

- Bob

Re: Bus error

[Georg Bauhaus]

Robert A Duff wrote:
> Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de> writes:
> 
>> Dmitry A. Kazakov wrote:
>>> On Fri, 29 Jun 2007 17:44:22 +0200, Georg Bauhaus wrote:
>>>
>>>> Dmitry A. Kazakov wrote:
>>>>>    function Very_Positive return Integer is
>>>>>    begin
>>>>>        return -1;
>>>>>    end Very_Positive;
>>>>>
>>>>>    Oops : Positive renames Very_Positive; -- This is OK!
> 
>> Oops will at some point raise Constraint error;...
> 
> Dmitry's complaint is the above will NOT raise C_E.

I see, yes, it won't raise at that point. I didn't jump to conclusions about
faulty language design because (1) Ada has new <type> when needed and
(b) using subtypes will, I guess, require some compromises, i.e. range
checks at run time.
So I will get a (possibly surprising) Constraint_Error when I write

  Some_String(Oops).

Positive'image is just as "tolerant". 


>> ...how can a compiler
>> be supposed to known that some Integer function will *always*
>> return non-Positives?
> 
> Indeed!  Likewise, how is the _programmer_ supposed to know?

A programmer may be using Positive when it is clear from the logic
of a program that in a region of the program, function Very_Positive
will indeed compute positive return values from its inputs (and thus
be aptly named). Otherwise, yes, mentioning subtype Positive in the
renaming declaration would not be the best choice.  When in other
circumstances, the function returns values not necessarily positive,
I expect the renaming to mention a different subtype. But OK, 
this subtype name is just a hint of varying value for the reader.


>> ...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).
> 
> Yes, I agree with you and with my evil twin Bub ;-)

I'm sorry!  <:-|


-- Georg
Too many scripting language programs, log files, and no sunshine for
too many days here
http://www.boersenspiel.de

Re: Bus error

[Markus E Leypold]

> 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
>
> But clearly your argument is nonsensical, literal is a syntactic element,

How about the difference between lvalues and rvalues?

- M

Re: Bus error

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> How about the difference between lvalues and rvalues?

I don't think it's necessary, if we have the distinction
between constant and variable.  Nor is the distinction
between name and expression useful.

These distinctions were diminished from Ada 83 to 95
(e.g. a function call returns a value (rvalue) in Ada
83, but returns an object (lvalue) in Ada 95).  We should
have gone all the way, and eliminated these useless
distinctions.

Why should "Hello"'Length be illegal, for example?

- Bob

Re: Bus error

[Dmitry A. Kazakov]

On Thu, 28 Jun 2007 13:06:49 -0700, Maciej Sobczak wrote:

> That's a good news, really. I consider this feature (limited
> controlled with unknown discriminant) to be fundamental for correct
> handling of external resources and other "interesting" types. It is
> really a high time for this feature to get a wider adoption.

Hmm, that depends on "interest." Maybe I am wrong, but I think that one
objection against Ada 2005 design is that now it is impossible to have
types which objects were strictly temporal, i.e. to prevent creation of
variables. Consider this:

 [  type T (<>) is limited private; ]

   X : T := Factory; -- Was illegal in Ada 95

   Foo (Factory); -- That's OK

(Ada 95 design was of course flawed too, because you could not do, say:

   Foo (Factory & Factory); -- Couldn't do this in Ada 95)

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

AW: Bus error

[Grein, Christoph (Fa. ESG)]

> ... one objection against Ada 2005 design is that now it is impossible
to > have types which objects were strictly temporal, i.e. to prevent
creation > of variables. Consider this:
>
> [  type T (<>) is limited private; ]
>
>   X : T := Factory; -- Was illegal in Ada 95
>
>   Foo (Factory); -- That's OK

Was this feature, which is now lost, often used and very important? Then
we should consider making it again available in the next Ada version. So
put a request to Ada Comment.


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message.