Re: Bus error

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

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