* strange error message
@ 2002-11-13 10:36 evangeli
2002-11-13 15:05 ` Stephen Leake
0 siblings, 1 reply; 13+ messages in thread
From: evangeli @ 2002-11-13 10:36 UTC (permalink / raw)
hi all
does anybody know the meaning of this message (at the runtime) :
------------------------------------------------
Xlib: unexpected async reply (sequence 0x1530)!
------------------------------------------------
my code has been compiled with gnat 3.14
i post this message just in case if someone got this message and
resolved the problem
thanks for any response.
Sami Evangelista
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: strange error message
2002-11-13 10:36 strange " evangeli
@ 2002-11-13 15:05 ` Stephen Leake
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Leake @ 2002-11-13 15:05 UTC (permalink / raw)
evangeli <evangeli@cnam.fr> writes:
> hi all
>
> does anybody know the meaning of this message (at the runtime) :
>
> ------------------------------------------------
> Xlib: unexpected async reply (sequence 0x1530)!
> ------------------------------------------------
This appears to be an X Windows error message. It is clearly _not_ a
GNAT run-time error message. You'll probably get more help on an X
Windows newsgroup.
--
-- Stephe
^ permalink raw reply [flat|nested] 13+ messages in thread
* Strange error message
@ 2014-06-01 10:24 Charly
2014-06-01 11:11 ` Dmitry A. Kazakov
2014-06-01 21:18 ` Robert A Duff
0 siblings, 2 replies; 13+ messages in thread
From: Charly @ 2014-06-01 10:24 UTC (permalink / raw)
Hi,
when I defined a class hierarchy I encountered a problem, that I could reduce
to the following few lines:
This version compiles without problems:
-----------------
package Test is
type Base is tagged private;
function Create return Base;
type High is new Base with private;
private
type Base is tagged null record;
type High is new Base with null record;
end Test;
-----------------
but this one
-----------------
package Test is
type Base is tagged private;
function Create return Base;
type High is new Base with private;
private
type Base is tagged null record;
type High is new Base with record --
H_Val : Natural := 0; -- these lines are changed
end record; --
end Test;
-----------------
does not compile an I get an error:
type must be declared abstract or "Create" overridden
Why do I have to overide the function Create for type High.
I don't see the necessity.
Btw. I'm using GNAT GPL 2014 but the same happens with 2013 version.
Charly
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-01 10:24 Strange error message Charly
@ 2014-06-01 11:11 ` Dmitry A. Kazakov
2014-06-01 12:50 ` Charly
2014-06-01 21:18 ` Robert A Duff
1 sibling, 1 reply; 13+ messages in thread
From: Dmitry A. Kazakov @ 2014-06-01 11:11 UTC (permalink / raw)
On Sun, 1 Jun 2014 03:24:02 -0700 (PDT), Charly wrote:
> when I defined a class hierarchy I encountered a problem, that I could reduce
> to the following few lines:
>
> This version compiles without problems:
> -----------------
> package Test is
>
> type Base is tagged private;
> function Create return Base;
>
> type High is new Base with private;
You must override Create for High, *always*.
> Why do I have to overide the function Create for type High.
> I don't see the necessity.
>
> Btw. I'm using GNAT GPL 2014 but the same happens with 2013 version.
I believe it was a recent hack (wrongly) added to Ada that you need not to
override primitive operations returning the tagged type when the derived
type does not actually extend. I don't know if making that public or
privately changes anything. You did that privately.
It is an awful idea in any form. You should always override such
operations, and all out-operations, because inheriting them is a priori
unsafe.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-01 11:11 ` Dmitry A. Kazakov
@ 2014-06-01 12:50 ` Charly
2014-06-01 13:54 ` Simon Wright
0 siblings, 1 reply; 13+ messages in thread
From: Charly @ 2014-06-01 12:50 UTC (permalink / raw)
Am Sonntag, 1. Juni 2014 13:11:08 UTC+2 schrieb Dmitry A. Kazakov:
> On Sun, 1 Jun 2014 03:24:02 -0700 (PDT), Charly wrote:
>
> You must override Create for High, *always*.
>
>
.........
>
>
> I believe it was a recent hack (wrongly) added to Ada that you need not to
>
> override primitive operations returning the tagged type when the derived
>
> type does not actually extend. I don't know if making that public or
>
> privately changes anything. You did that privately.
>
>
>
> It is an awful idea in any form. You should always override such
>
> operations, and all out-operations, because inheriting them is a priori
>
> unsafe.
>
>
>
> --
>
> Regards,
>
> Dmitry A. Kazakov
>
> http://www.dmitry-kazakov.de
> --
>
> Regards,
>
> Dmitry A. Kazakov
>
> http://www.dmitry-kazakov.de
Thank you for the rapid answer. I wondered if it is a bug in GNAT.
I thought, that I always have to override abstract function and
procedures in concrete types and can override concrete functions
and procedures only as needed.
Charly
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-01 12:50 ` Charly
@ 2014-06-01 13:54 ` Simon Wright
0 siblings, 0 replies; 13+ messages in thread
From: Simon Wright @ 2014-06-01 13:54 UTC (permalink / raw)
Charly <carl.weierstrass@googlemail.com> writes:
> Thank you for the rapid answer. I wondered if it is a bug in GNAT.
> I thought, that I always have to override abstract function and
> procedures in concrete types and can override concrete functions
> and procedures only as needed.
This is in the AARM 3.9.3(6) [1]. It'ss apparently intended to replace
'type renaming', and (in the comments on AI95-00391 [2]) is described as
'a last minute "quick fix."'.
[1] http://www.ada-auth.org/standards/12aarm/html/AA-3-9-3.html#p6
[2] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00391.txt?rev=1.9
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-01 10:24 Strange error message Charly
2014-06-01 11:11 ` Dmitry A. Kazakov
@ 2014-06-01 21:18 ` Robert A Duff
2014-06-02 7:47 ` Dmitry A. Kazakov
2014-06-02 19:56 ` Randy Brukardt
1 sibling, 2 replies; 13+ messages in thread
From: Robert A Duff @ 2014-06-01 21:18 UTC (permalink / raw)
Charly <carl.weierstrass@googlemail.com> writes:
> Hi,
>
> when I defined a class hierarchy I encountered a problem, that I could reduce
> to the following few lines:
>
> This version compiles without problems:
> -----------------
> package Test is
>
> type Base is tagged private;
> function Create return Base;
>
> type High is new Base with private;
>
> private
>
> type Base is tagged null record;
>
> type High is new Base with null record;
>
> end Test;
> -----------------
>
> but this one
>
> -----------------
> package Test is
>
> type Base is tagged private;
> function Create return Base;
>
> type High is new Base with private;
>
> private
>
> type Base is tagged null record;
>
> type High is new Base with record --
> H_Val : Natural := 0; -- these lines are changed
> end record; --
>
> end Test;
> -----------------
>
> does not compile an I get an error:
>
> type must be declared abstract or "Create" overridden
>
> Why do I have to overide the function Create for type High.
> I don't see the necessity.
Because whatever Create does, it doesn't set any value for H_Val,
because H_Val doesn't exist in Base. So it makes no sense to inherit
it as is. [*] But see below.
In your first version, High adds no new components. Ada 95 used to
require overriding in that case, too, but the overriding is always:
function Create return High is
begin
return (Base with null record);
end Create;
What else would it be? So the language was changed to provide that
overriding by default in the "null record" case.
I don't know why Dmitry and Randy want us to write that out explicitly;
it seems like an obviously useful and safe default.
[*] Your H_Val has a default of 0, so it might make sense to define
the language to provide an automatic default overriding:
function Create return High is
begin
return (Base with H_Val => 0);
end Create;
That's not how the language is now, and I suspect Dmitry and Randy
would be appalled at the idea. I don't really understand their
point of view -- I mean, I love consistency and all, but "A FOOLISH
consistency is the hobgloblin... etc".
By the way, Tucker wanted the current rule for Ada 95. I argued him
out of it. That is, in 1993 or so, I agreed with Dmitry's and Randy's
current position. I've since changed my mind.
- Bob
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-01 21:18 ` Robert A Duff
@ 2014-06-02 7:47 ` Dmitry A. Kazakov
2014-06-02 13:49 ` Robert A Duff
2014-06-02 19:56 ` Randy Brukardt
1 sibling, 1 reply; 13+ messages in thread
From: Dmitry A. Kazakov @ 2014-06-02 7:47 UTC (permalink / raw)
On Sun, 01 Jun 2014 17:18:03 -0400, Robert A Duff wrote:
> Charly <carl.weierstrass@googlemail.com> writes:
>
>> when I defined a class hierarchy I encountered a problem, that I could reduce
>> to the following few lines:
>>
>> This version compiles without problems:
>> -----------------
>> package Test is
>>
>> type Base is tagged private;
>> function Create return Base;
>>
>> type High is new Base with private;
>>
>> private
>>
>> type Base is tagged null record;
>>
>> type High is new Base with null record;
>>
>> end Test;
> I don't know why Dmitry and Randy want us to write that out explicitly;
> it seems like an obviously useful and safe default.
The first objection is that the legality of inheriting Create in
type Base is tagged private;
function Create return Base;
type High is new Base with private;
depends on the private part of the package. This is not good.
The second objection is, if the above is not good then
type High is new Base with null record;
should make no difference.
---------------
Of course one could argue in favor of the rule that all primitive
operations are in some sense overridden anyway. It is only the way the
bodies are constructed (inherited vs. provided by the user), what makes
difference. I.e. whether
overriding function Create return High;
appears in the public part of the package or not, that is an implementation
detail uninteresting to the clients. I would agree with that, but it is not
how the language is designed presently.
It is, as always, too late, but probably overriding (with new body) were to
appear strictly in the package body. Then the rule of null extension would
be all OK to me.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-02 7:47 ` Dmitry A. Kazakov
@ 2014-06-02 13:49 ` Robert A Duff
2014-06-02 14:55 ` Dmitry A. Kazakov
2014-06-02 18:39 ` Shark8
0 siblings, 2 replies; 13+ messages in thread
From: Robert A Duff @ 2014-06-02 13:49 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> The first objection is that the legality of inheriting Create in
>
> type Base is tagged private;
> function Create return Base;
>
> type High is new Base with private;
>
> depends on the private part of the package. This is not good.
Privacy breakage is not good, but there is no privacy breakage here.
Privacy breakage happens when the legality of clients depends on the
contents of the private part. Here, the legality of the package itself
depends on the contents of the private part (which is always the case!).
Clients can only see the visible part as quoted above.
The private part could be:
private
type Base is tagged null record;
type High is new Base with null record;
or:
private
type Base is tagged null record;
type High is new Base with record
H_Val : Natural;
end record;
overriding function Create return High is
(Base'(Create) with H_Val => <>);
both of which are legal. The visible part promises that there
will be a function Create returning High. The first private part
above accomplishes that by using the one implicitly generated
by the compiler, which looks like this:
function Create return High is (Base'(Create) with null record);
If you wrote it by hand (as you were required to do in Ada 95), you
would almost certainly write something equivalent. What else could it
reasonably do?
The compiler can't automatically create Create in the second case,
because it doesn't know what value you want for H_Val.
> The second objection is, if the above is not good then
>
> type High is new Base with null record;
>
> should make no difference.
Well, since your first objection is invalid, the premise of
your second objection is false. ;-)
> ---------------
> Of course one could argue in favor of the rule that all primitive
> operations are in some sense overridden anyway. It is only the way the
> bodies are constructed (inherited vs. provided by the user), what makes
> difference. I.e. whether
>
> overriding function Create return High;
>
> appears in the public part of the package or not, that is an implementation
> detail uninteresting to the clients. I would agree with that, but it is not
> how the language is designed presently.
Not sure what you mean. You can put the above "overriding..." in the
visible part or the private part, or (in the null record case) leave it
out. It makes no difference to clients.
> It is, as always, too late, but probably overriding (with new body) were to
> appear strictly in the package body.
Yes, that would make sense. I suggested that during Ada 9X. The
reasons not to do that have to do with making compilers easier to write.
In fact, private parts should not exist; that stuff belongs in the body.
>...Then the rule of null extension would
> be all OK to me.
Is it OK with you now, having read my comments above?
- Bob
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-02 13:49 ` Robert A Duff
@ 2014-06-02 14:55 ` Dmitry A. Kazakov
2014-06-02 17:24 ` Robert A Duff
2014-06-02 18:39 ` Shark8
1 sibling, 1 reply; 13+ messages in thread
From: Dmitry A. Kazakov @ 2014-06-02 14:55 UTC (permalink / raw)
On Mon, 02 Jun 2014 09:49:13 -0400, Robert A Duff wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> The first objection is that the legality of inheriting Create in
>>
>> type Base is tagged private;
>> function Create return Base;
>>
>> type High is new Base with private;
>>
>> depends on the private part of the package. This is not good.
>
> Privacy breakage is not good, but there is no privacy breakage here.
> Privacy breakage happens when the legality of clients depends on the
> contents of the private part. Here, the legality of the package itself
> depends on the contents of the private part (which is always the case!).
OK
> Is it OK with you now, having read my comments above?
Yes, you convinced me.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-02 14:55 ` Dmitry A. Kazakov
@ 2014-06-02 17:24 ` Robert A Duff
0 siblings, 0 replies; 13+ messages in thread
From: Robert A Duff @ 2014-06-02 17:24 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Yes, you convinced me.
Cool! :-)
Let's see if Randy agrees.
- Bob
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-02 13:49 ` Robert A Duff
2014-06-02 14:55 ` Dmitry A. Kazakov
@ 2014-06-02 18:39 ` Shark8
1 sibling, 0 replies; 13+ messages in thread
From: Shark8 @ 2014-06-02 18:39 UTC (permalink / raw)
On 02-Jun-14 07:49, Robert A Duff wrote:
> In fact, private parts should not exist; that stuff belongs in the body.
I'm not sure I agree -- it would be the ideal case, yes... but the
private part can, and should [IMO] be used to convey information that
isn't, strictly-speaking, required for the specification but /is/ for
interfacing. eg: the size of a private-type, import, convention, etc.
Granted. virtually all of those are [in Ada 2012] fairly obsolescent
with the aspect mechanism there are some that are not covered
(record-representations and enumeration-value specifications come
immediately to mind).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Strange error message
2014-06-01 21:18 ` Robert A Duff
2014-06-02 7:47 ` Dmitry A. Kazakov
@ 2014-06-02 19:56 ` Randy Brukardt
1 sibling, 0 replies; 13+ messages in thread
From: Randy Brukardt @ 2014-06-02 19:56 UTC (permalink / raw)
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcctx84qqgk.fsf@shell01.TheWorld.com...
...
> [*] Your H_Val has a default of 0, so it might make sense to define
> the language to provide an automatic default overriding:
>
> function Create return High is
> begin
> return (Base with H_Val => 0);
> end Create;
>
> That's not how the language is now, and I suspect Dmitry and Randy
> would be appalled at the idea. I don't really understand their
> point of view -- I mean, I love consistency and all, but "A FOOLISH
> consistency is the hobgloblin... etc".
Not speaking for others, but my concern with automatically generating Create
for null records is that it is a maintenance problem. When one later adds a
component (and you ALWAYS end up adding a component sooner or later), you
suddenly have to override a bunch of routines. This is extremely annoying,
because the entire reason (for me at least) for declaring the null record is
to get the structure (all of the routines that I need to implement) correct
before I bother with any actual implementation.
You can avoid the problem with a junk component, but that's nasty.
I'd be happy if there was a way for the automatic construction to extend to
other types as well. The one you suggested would work as well as any. I
tried to make such a proposal in AI12-0083-1 (in response to a question from
Adam), but it got approximately 0% support (which is why it's currently on
the hold of death). I'm surprised that you suddenly are in favor of it now,
because you surely weren't when we discussed it (or you missed that
meeting).
Randy.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-06-02 19:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-01 10:24 Strange error message Charly
2014-06-01 11:11 ` Dmitry A. Kazakov
2014-06-01 12:50 ` Charly
2014-06-01 13:54 ` Simon Wright
2014-06-01 21:18 ` Robert A Duff
2014-06-02 7:47 ` Dmitry A. Kazakov
2014-06-02 13:49 ` Robert A Duff
2014-06-02 14:55 ` Dmitry A. Kazakov
2014-06-02 17:24 ` Robert A Duff
2014-06-02 18:39 ` Shark8
2014-06-02 19:56 ` Randy Brukardt
-- strict thread matches above, loose matches on Subject: below --
2002-11-13 10:36 strange " evangeli
2002-11-13 15:05 ` Stephen Leake
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox