bus error

bus error

[saharbaugh%roo.dnet]

From:	WINNIE::"MAILER-DAEMON" "Mail Delivery Subsystem"  9-AUG-1990 10:40:54.85
To:	<roo::saharbaugh> 
CC:	
Subj:	Returned mail: unknown mailer error 101 

   ----- Transcript of session follows -----
bad system name: ucivax
uux failed. code 101
554 <ucivax!gateway@ucbvax.Berkeley.edu>... unknown mailer error 101

   ----- Unsent message follows -----
Received: from ROO.DECnet MAIL11D_V3 by winnie.fit.edu (5.57/Ultrix2.4-C)
	id AA04506; Thu, 9 Aug 90 10:27:06 EDT
Date: Thu, 9 Aug 90 10:27:05 EDT
From: roo::saharbaugh
To: WINNIE::"ucivax!gateway@ucbvax.Berkeley.edu"
Cc: SAHARBAUGH
Subject: to Jose_Duarte, bus_error

We haven't experienced bus_error on our Sun 4 or Silicon Graphics
but we have in the past experienced them on a Masscomp running
Unix and Verdix compiler.  Our conclusion was that bus errors were
hardware problems and being reported by Unix and had nothing to
do with Ada.  We would sometimes get bus_error on boot-up when the
hardware was being tested by the ROM boot.
   So...our suggestion is to call a hardware maintenance person
to run diagnostics.  Hope this helps some.
regards, sam harbaugh
---------------------

bus error

[saharbaugh%roo.dnet]

     Kathy Gilroy says that she has experienced "bus error" when using
access types sometimes and has found a preventative to be tp
use the keyword "all" when referencing components of the accessed
object.
     i.e., instead of referencing "object.component" reference
"object.all.component".
     A possible explanation is that the code
generator gets confused and generates an illegal bus address which
then is reported through the operating system to you as a "bus error".
     If anyone tries this please report the results, thanks.
sam harbaugh for kathy gilroy
-----------------------------

Re: bus error

[Chuck Peterson]

I believe that "bus error" on an SGI indicates that an invalid memory
address was generated (e.g. an attempt to dereference an invalid C
pointer).

My opinion only. (Disclaimer.)

BUS ERROR

[J o s e D u a r t e !!!]

Hi Everybody,

	I just wanted to post my findings on the BUS ERROR bug
that I recently battled with...I received the following responses
from people throughout the country. I would like to thank everyone
who responded and I would like to especially thank Sam Harbaugh and
Kathy Gilroy.  I tried Kathy's suggestion, and the program behaved
correctly in all trial tests except one.

Jose Duarte

------------------------------------------------------
From: Fred Hosch <fred@titan.tsd.arlut.utexas.edu>
Subject: bus error


Verdix reports "a deficiency in the Sun OS may cause a 'bus error' during
execution of VADS compiled code on 68030-based Sun hosts ... Sun intends to
fix this deficiency in the 4.1.1 release of Sun OS."  Since you're running
a Sun 4, I don't know if this applies.  At any rate, a patch exits for
Sun OS versions 4.0.3 and 4.1.  The bug ID is 1038670.  The patch can
be obtained from Sun (1-800-USA-4-SUN, or bulletin board 1-800-477-4768
with the login guest), or from Verdix (1-800-USE-VADS).

Fred Hosch
Applied Research Labs
UT Austin
fred@cs.utexas.edu


------------------------------------------------------
From: saharbaugh%roo.dnet@WINNIE.FIT.EDU
Subject: bus error
Date: 9 Aug 90 14:50:38 GMT


We haven't experienced bus_error on our Sun 4 or Silicon Graphics
but we have in the past experienced them on a Masscomp running
Unix and Verdix compiler.  Our conclusion was that bus errors were
hardware problems and being reported by Unix and had nothing to
do with Ada.  We would sometimes get bus_error on boot-up when the
hardware was being tested by the ROM boot.
   So...our suggestion is to call a hardware maintenance person
to run diagnostics.  Hope this helps some.
regards, sam harbaugh
------------------------------------------------------
From: cpp@calmasd.Prime.COM (Chuck Peterson)
Subject: Re: bus error
Organization: Calma - A Division of Prime Computers


I believe that "bus error" on an SGI indicates that an invalid memory
address was generated (e.g. an attempt to dereference an invalid C
pointer).

My opinion only. (Disclaimer.)
------------------------------------------------------
From: saharbaugh%roo.dnet@WINNIE.FIT.EDU
Subject: bus error


     Kathy Gilroy says that she has experienced "bus error" when using
access types sometimes and has found a preventative to be tp
use the keyword "all" when referencing components of the accessed
object.
     i.e., instead of referencing "object.component" reference
"object.all.component".
     A possible explanation is that the code
generator gets confused and generates an illegal bus address which
then is reported through the operating system to you as a "bus error".
     If anyone tries this please report the results, thanks.
sam harbaugh for kathy gilroy
------------------------------------------------------

Thanks again to everyone who responded !!!

BUS ERROR

[saharbaugh%roo.dnet]

Since one trial test still fails Kathy Gilroy suggests 
disabling the optimizer (assuming it is on by default).  This has
sometimes helped clear problems with access types.  Let us know the results.
sam harbaugh for kathy gilroy
-----------------------------

BUS ERROR

[J o s e D u a r t e ! ! !]

Hi Folks,

	A while ago, I asked for help with a BUS ERROR problem
that I was having when using pointers. Since then, I have
tried some of your suggestions & I posted the results a while
ago.  I resolved this problem by:

	1. Dereferencing the pointer variable explicitly.
	2. Using an older version of the Verdix Compiler.


	Thanks to all who replied & sent helpful suggestions.
Now that I compiled the program with Verdix 5.5, it's about
twice as slow *but* it doesn't stop w/"BUS ERROR" problems!

J Duarte

Bus error

[Maciej Sobczak]

I have found a problem with my compiler:

-- a.ads
with Ada.Finalization;
package A is

   type T is tagged limited private;

   function Make return T;

private

   type T is new Ada.Finalization.Limited_Controlled with
      record
         X : Integer;
      end record;

   overriding procedure Finalize(V : in out T);

end A;

-- a.adb
with Ada.Text_IO;
package body A is

   function Make return T is
   begin
      return (Ada.Finalization.Limited_Controlled with 7);
   end Make;

   procedure Finalize(V : in out T) is
   begin
      Ada.Text_IO.Put("Finalizing T");
   end;

end A;

-- hello.adb
with A;
procedure Hello is
   Y : A.T := A.Make;
begin
   null;
end Hello;

$ gnatmake hello
gcc -c hello.adb
gcc -c a.adb
gnatbind -x hello.ali
gnatlink hello.ali
$ ./hello
Bus error
$

GNAT version: 4.3.0 20070527 (experimental)

BTW - is the code correct at all? I'm worried about A.Make in
particular.

--
Maciej Sobczak
http://www.msobczak.com/

Re: Bus error

[Georg Bauhaus]

On Wed, 2007-06-27 at 07:23 -0700, Maciej Sobczak wrote:
> I have found a problem with my compiler:
> 
> -- a.ads
> with Ada.Finalization;
> package A is
> 
>    type T is tagged limited private;
> 
>    function Make return T;

As it happens, the masters--who are probably all in Geneva now--
have been discussing a related issue on Ada_Comment.
The archives might have some hints.

> $ gnatmake hello
> gcc -c hello.adb
> gcc -c a.adb
> gnatbind -x hello.ali
> gnatlink hello.ali
> $ ./hello
> Bus error
> $

(Do you get a different effect when you try compiling
with -O -g -a -gnata -gnato?)

> GNAT version: 4.3.0 20070527 (experimental)
> 
> BTW - is the code correct at all? I'm worried about A.Make in
> particular.

Procedure Make should be fine as the object returned is to be
built in place. (As per Bob Duff's "gems" on limited aggregates
and other sources.)

Re: Bus error

[Maciej Sobczak]

On 27 Cze, 17:45, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:

> > -- a.ads
> > with Ada.Finalization;
> > package A is
>
> >    type T is tagged limited private;
>
> >    function Make return T;
>
> As it happens, the masters--who are probably all in Geneva now--
> have been discussing a related issue on Ada_Comment.
> The archives might have some hints.

Google group search does not find anything.
And yes, Geneva is a good place for discussing Ada now, although it's
a bit rainy this week. ;-)

> (Do you get a different effect when you try compiling
> with -O -g -a -gnata -gnato?)

Yes, there is a difference - it took me longer to type the commands
before I got bus error...

> Procedure Make should be fine as the object returned is to be
> built in place. (As per Bob Duff's "gems" on limited aggregates
> and other sources.)

Except that those gems don't tell much about extension aggregates and
even less about limited controlled.

BTW - is it necessary to reveal in the public view that the type is
tagged? It is tagged only so that it can be controlled and since this
is implementation detail,
it should be private together with the extension.
I cannot check it, because this time I get the explicit "GNAT BUG
DETECTED".

Ideally, the public view should look like this:

type T (<>) is limited private;

With the private view unchanged. Is it possible? (assuming good
compiler)

--
Maciej Sobczak
http://www.msobczak.com/

Re: Bus error

[Anh Vo]

On Jun 27, 7:23 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> I have found a problem with my compiler:
>
> -- a.ads
> with Ada.Finalization;
> package A is
>
>    type T is tagged limited private;
>
>    function Make return T;
>
> private
>
>    type T is new Ada.Finalization.Limited_Controlled with
>       record
>          X : Integer;
>       end record;
>
>    overriding procedure Finalize(V : in out T);
>
> end A;
>
> -- a.adb
> with Ada.Text_IO;
> package body A is
>
>    function Make return T is
>    begin
>       return (Ada.Finalization.Limited_Controlled with 7);
>    end Make;
>
>    procedure Finalize(V : in out T) is
>    begin
>       Ada.Text_IO.Put("Finalizing T");
>    end;
>
> end A;
>
> -- hello.adb
> with A;
> procedure Hello is
>    Y : A.T := A.Make;
> begin
>    null;
> end Hello;
>
> $ gnatmake hello
> gcc -c hello.adb
> gcc -c a.adb
> gnatbind -x hello.ali
> gnatlink hello.ali
> $ ./hello
> Bus error
> $
>
> GNAT version: 4.3.0 20070527 (experimental)
>
> BTW - is the code correct at all? I'm worried about A.Make in
> particular.
>
> --
> Maciej Sobczakhttp://www.msobczak.com/

With the lattest snapshot gcc-4.3-20070622 a bug box resulted as shown
below

bash-2.05b$ gnatmake hello.adb
gcc -c hello.adb
gcc -c a.adb
+===========================GNAT BUG
DETECTED==============================+
| 4.3.0 20070615 (experimental) (i686-pc-linux-gnu) Assert_Failure
namet.adb:687|
| Error detected at a.adb:
10:7                                             |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.
|
| Use a subject line meaningful to you and us to track the
bug.            |
| Include the entire contents of this bug box in the
report.               |
| Include the exact gcc or gnatmake command that you
entered.              |
| Also include sources listed below in gnatchop
format                     |
| (concatenated together with no headers between
files).                   |
+==========================================================================
+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

a.adb
a.ads

compilation abandoned
gnatmake: "a.adb" compilation error

When compiled with GNAT-GPL-2007, an error is detected

gcc -c hello.adb
gcc -c a.adb
a.adb:10:07: "" is undefined
a.adb:10:07: actual for "From" must be a variable
gnatmake: "a.adb" compilation error

However, if the return statement is fully qualified as below, it works
fine on all versions

$$$       return T'(Ada.Finalization.Limited_Controlled with 7);

AV

Re: Bus error

[Maciej Sobczak]

On 27 Cze, 22:02, Anh Vo <anhvofrc...@gmail.com> wrote:

> However, if the return statement is fully qualified as below, it works
> fine on all versions
>
> $$$       return T'(Ada.Finalization.Limited_Controlled with 7);

I still get bus error with this.
Why should that make any difference, anyway (other than guessing
around the compiler bug)? Qualification should not be necessary in
this context, because the expected type for the aggregate is known
from the function return type. There is no ambiguity here that would
need to be resolved with the qualification.

--
Maciej Sobczak
http://www.msobczak.com/

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 27 Cze, 17:45, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
> wrote:
>> Procedure Make should be fine as the object returned is to be
>> built in place. (As per Bob Duff's "gems" on limited aggregates
>> and other sources.)

Thanks for mentioning the "gems", Georg.

> Except that those gems don't tell much about extension aggregates and
> even less about limited controlled.

There are a few more gems on this subject in the pipeline -- stay tuned.

http://www.adacore.com/category/developers-center/gems

> BTW - is it necessary to reveal in the public view that the type is
> tagged?

No.  You can have an untagged private type whose full type is tagged.
That means that clients cannot extend the type, but child packages can.

>... It is tagged only so that it can be controlled and since this
> is implementation detail,
> it should be private together with the extension.

Right.

> I cannot check it, because this time I get the explicit "GNAT BUG
> DETECTED".

...which requests that you send a bug report.  If you're not a supported
customer of AdaCore, and you send a bug report, it will eventually get
fixed (but it's lower priority than paying customers).

> Ideally, the public view should look like this:
>
> type T (<>) is limited private;
>
> With the private view unchanged. Is it possible? (assuming good
> compiler)

Yes, that's possible.  Assuming a bug-free compiler, of course. ;-).

As to your original question, about an extension aggregate: I don't see
anything wrong with your code, and I do recall fixing a bug in that area
(extension aggregate of limited type with controlled parts returned from
build-in-place function) a month or so ago.  The bug fix will eventually
find its way into the public version of GNAT.

- Bob

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 27 Cze, 22:02, Anh Vo <anhvofrc...@gmail.com> wrote:
>
>> However, if the return statement is fully qualified as below, it works
>> fine on all versions
>>
>> $$$       return T'(Ada.Finalization.Limited_Controlled with 7);
>
> I still get bus error with this.
> Why should that make any difference, anyway (other than guessing
> around the compiler bug)? Qualification should not be necessary in
> this context, because the expected type for the aggregate is known
> from the function return type. There is no ambiguity here that would
> need to be resolved with the qualification.

You are correct -- the return T'(...) version should behave the same as
the return (...) version.  If it doesn't, that's probably a bug in the
compiler.

Either way, I don't see any good reason for a bus error here.

- Bob

Re: Bus error

[Maciej Sobczak]

On 28 Cze, 03:58, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> > BTW - is it necessary to reveal in the public view that the type is
> > tagged?
>
> No.  You can have an untagged private type whose full type is tagged.

You mean - untagged *public*, I suppose?

> > I cannot check it, because this time I get the explicit "GNAT BUG
> > DETECTED".
>
> ...which requests that you send a bug report.

I conclude that AdaCore guys read comp.lang.ada as well. :-)

> As to your original question, about an extension aggregate: I don't see
> anything wrong with your code, and I do recall fixing a bug in that area
> (extension aggregate of limited type with controlled parts returned from
> build-in-place function) a month or so ago.  The bug fix will eventually
> find its way into the public version of GNAT.

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.

--
Maciej Sobczak
http://www.msobczak.com/

Re: Bus error

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 28 Cze, 03:58, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> > BTW - is it necessary to reveal in the public view that the type is
>> > tagged?
>>
>> No.  You can have an untagged private type whose full type is tagged.
>
> You mean - untagged *public*, I suppose?

Yeah, the terminology is confusing.  I mean:

    package P is
        type T is limited private;
    private
        type T is tagged limited ...;
    end P;

or:

    with Ada.Finalization; use Ada;
    package P is
        type T is limited private;
    private
        type T is new Finalization.Limited_Controlled with ...;
    end P;

Both of the above are legal.

>> > I cannot check it, because this time I get the explicit "GNAT BUG
>> > DETECTED".
>>
>> ...which requests that you send a bug report.
>
> I conclude that AdaCore guys read comp.lang.ada as well. :-)

Not really.  ;-)

I read it once in a while, but often not for months at a time.
Most AdaCore folks do not read comp.lang.ada at all.

And AdaCore certainly does not go looking for GNAT bugs on
comp.lang.ada.  If you want a bug fixed, you have to send
an official bug report.  And if you want it fixed fast,
or want AdaCore to answer your questions, you have to spend
money.

>> As to your original question, about an extension aggregate: I don't see
>> anything wrong with your code, and I do recall fixing a bug in that area
>> (extension aggregate of limited type with controlled parts returned from
>> build-in-place function) a month or so ago.  The bug fix will eventually
>> find its way into the public version of GNAT.
>
> 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.

Right, but it's the Ada 2005 build-in-place function return stuff that
makes these really useful.  The bug we're talking about (assuming it
really is the same bug that I fixed, which I can't promise) was a
nasty interaction between build-in-place functions and controlled
types.

- 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

Re: Bus error

[Maciej Sobczak]

On 28 Cze, 23:19, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> >> No.  You can have an untagged private type whose full type is tagged.
>
> > You mean - untagged *public*, I suppose?
>
> Yeah, the terminology is confusing.

Yes, I meant "untagged public view". If any such thing exists. :-)

> I mean:
>
>     package P is
>         type T is limited private;
>     private
>         type T is tagged limited ...;
>     end P;
>
> or:
>
>     with Ada.Finalization; use Ada;
>     package P is
>         type T is limited private;
>     private
>         type T is new Finalization.Limited_Controlled with ...;
>     end P;

Yes, or even stricter:

    with Ada.Finalization; use Ada;
    package P is
        type T (<>) is limited private;
    private
        type T is new Finalization.Limited_Controlled with ...;
    end P;

which prevents uninitialized objects.

> Most AdaCore folks do not read comp.lang.ada at all.

Interesting.
Do they have so many official user complaints to read that they don't
have any time left? :-)

Hey, I can afford this joke, if they don't read it, right?

> And AdaCore certainly does not go looking for GNAT bugs on
> comp.lang.ada.  If you want a bug fixed, you have to send
> an official bug report.  And if you want it fixed fast,
> or want AdaCore to answer your questions, you have to spend
> money.

This is short-sighted. What if I'm not *yet* an Ada user, but just
contemplate this possibility and take into account *everything*,
including the consistency of Ada community?
By neglecting c.l.a. they're risking to lose a potential customer(s).

> > 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.
>
> Right, but it's the Ada 2005 build-in-place function return stuff that
> makes these really useful.

Yes. Interestingly, it works fine with my compiler. I just consider
the aggregate to be more concise in simpler cases.

>  The bug we're talking about (assuming it
> really is the same bug that I fixed, which I can't promise) was a
> nasty interaction between build-in-place functions and controlled
> types.

Controlled types are messy.

--
Maciej Sobczak
http://www.msobczak.com/

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. 

Re: Bus error

[Georg Bauhaus]

Maciej Sobczak wrote:
>
> Yes, or even stricter:
> 
>     with Ada.Finalization; use Ada;
>     package P is
>         type T (<>) is limited private;
>     private
>         type T is new Finalization.Limited_Controlled with ...;
>     end P;
> 
> which prevents uninitialized objects.

Uhm, it prevents uninitialized objects that cannot otherwise
have default initialisation (e.g. from function calls whose
results are assigned to components), or initialisation via Initialize.
Such as records that need their components initialised with
values known only at run time *and* defined at library level etc.

In a less flat architecture (which dismisses the possibilites of
nested block structure :), consider a plain limited type T in some
suitably nested block:


procedure Operate_System_95 is


    type External_State is new Natural;

    outside: External_State;
    

    
    package P is

        type T is limited private;

    private
        
        type Void is null record;
    
        function Constructor(Object: access T) return Void;
        
        type T is limited record
            hook: Void := Constructor(T'access);
            count: Natural;
        end record;

    end P;

    package body P is
    
        function Constructor(Object: access T) return Void is
        begin
            Object.count := Natural(outside);
            return (null record);
        end Constructor;
        
    end P;

    V: P.T;  --  initialisation via Constructor is guaranteed

begin
    null;
end Operate_System_95;

Re: Bus error

[Dmitry A. Kazakov]

On Fri, 29 Jun 2007 11:23:08 +0200, Grein, Christoph (Fa. ESG) wrote:

> Was this feature, which is now lost, often used and very important?

No so oft. One example I know is immutable lists of strings [actually any
unconstrained objects]. We don't have aggregates or tuples of, so let's
emulate them using a limited types:

   type List (<>) is limited private;
   function "/" (L, R : String) return List;
   function "/" (L : List, R : String) return List;

   procedure Foo (X : List);

We could call Foo as

   Foo ("A" / "B" / "C" / "D");

Let we wanted to prevent the second "/" from copying lists. In order to do
so, we would implement List as a controlled record containing a pointer to
a reference-counted implementation of the list. So "/" would actually
modify target of left argument in hope that it would vanish anyway. It
will, if there were impossible to create a variable of List.

   X : List := "A" / "B";
   Y : List := X / "C";   -- Surprise!

> Then
> we should consider making it again available in the next Ada version.

Have you an idea of how it could be done? It looks difficult to me.

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

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

[Adam Beneschan]

On Jun 29, 2:42 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> Maciej Sobczak wrote:
>
> > Yes, or even stricter:
>
> >     with Ada.Finalization; use Ada;
> >     package P is
> >         type T (<>) is limited private;
> >     private
> >         type T is new Finalization.Limited_Controlled with ...;
> >     end P;
>
> > which prevents uninitialized objects.
>
> Uhm, it prevents uninitialized objects that cannot otherwise
> have default initialisation (e.g. from function calls whose
> results are assigned to components), or initialisation via Initialize.
> Such as records that need their components initialised with
> values known only at run time *and* defined at library level etc.

I'm not sure what you mean here... For packages that can only see the
partial view of T, T is an indefinite type, and you cannot declare a
variable of type T without an initialization expression (3.3.1(5)).  I
think that's what Maciej was referring to.  (Yes, a private child
package of P could declare a variable of type T without an
initializer, but I don't think he was referring to those.)

                    -- Adam

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

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 28 Cze, 23:19, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> >> No.  You can have an untagged private type whose full type is tagged.
>>
>> > You mean - untagged *public*, I suppose?
>>
>> Yeah, the terminology is confusing.
>
> Yes, I meant "untagged public view". If any such thing exists. :-)

The RM term is "partial view".

>> I mean:
>>
>>     package P is
>>         type T is limited private;
>>     private
>>         type T is tagged limited ...;
>>     end P;
>>
>> or:
>>
>>     with Ada.Finalization; use Ada;
>>     package P is
>>         type T is limited private;
>>     private
>>         type T is new Finalization.Limited_Controlled with ...;
>>     end P;
>
> Yes, or even stricter:
>
>     with Ada.Finalization; use Ada;
>     package P is
>         type T (<>) is limited private;
>     private
>         type T is new Finalization.Limited_Controlled with ...;
>     end P;
>
> which prevents uninitialized objects.

As written, it prevents clients from creating ANY objects of
type T.  Clients cannot create uninitialized objects ("X:T;",
or "new T;") because of the (<>).  And clients cannot create
initialized objects, because no functions are exported.

In a real example, T might be Set, and there would be some
functions like:

    function Empty_Set return Set;
    function Intersection (...) return Set;

The (<>) means clients can't create objects of type Set without
initializing them with some function under control of the Sets
package.

>> Most AdaCore folks do not read comp.lang.ada at all.
>
> Interesting.
> Do they have so many official user complaints to read that they don't
> have any time left? :-)
>
> Hey, I can afford this joke, if they don't read it, right?

;-)

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

Adam Beneschan wrote:
> On Jun 29, 2:42 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
>> Maciej Sobczak wrote:
>>
>>> Yes, or even stricter:
>>>     with Ada.Finalization; use Ada;
>>>     package P is
>>>         type T (<>) is limited private;
>>>     private
>>>         type T is new Finalization.Limited_Controlled with ...;
>>>     end P;
>>> which prevents uninitialized objects.
>> Uhm, it prevents uninitialized objects that cannot otherwise
>> have default initialisation (e.g. from function calls whose
>> results are assigned to components), or initialisation via Initialize.
>> Such as records that need their components initialised with
>> values known only at run time *and* defined at library level etc.
> 
> I'm not sure what you mean here... For packages that can only see the
> partial view of T, T is an indefinite type, and you cannot declare a
> variable of type T without an initialization expression (3.3.1(5)).  I
> think that's what Maciej was referring to.  (Yes, a private child
> package of P could declare a variable of type T without an
> initializer, but I don't think he was referring to those.)

I was only thinking of guaranteed initialisation of an object of a
limited type T that is declared just anywhere even when it is not
explicitly initialised. The idea being that T then doesn't necessarily
need (<>) in its public view because T's default initialization
might take care of all components via

  type T is limited ...
     Xyz_Part : D := Init_All_Copmonents(T'access, ...);

This, I thought, is made possible through the venerable
mechanisms "limited" and visibility control. That is, just like we can
make a no-argument constructor of a Java class call methods on "this",
we can make variables of a limited type T call functions on "T'access"
(by not using an Ada 2005 constructor function in this case).

And I'm glad that we can now have aggregates of limited types for
building connected (partially) immutable data structures in source.
And all kinds of constants of limited types.

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

[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

[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

[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

[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

[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

[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

[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:
> 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

[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

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

[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]

"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]

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

[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