* Generic private type declaration
@ 2016-11-25 17:36 Alejandro R. Mosteo
2016-11-25 19:17 ` Dmitry A. Kazakov
` (4 more replies)
0 siblings, 5 replies; 14+ messages in thread
From: Alejandro R. Mosteo @ 2016-11-25 17:36 UTC (permalink / raw)
Hello,
I need some eyes on this error because I'm missing something basic. When
compiling this code:
procedure B001_Tagged is
generic
type X is private;
package Untagged is
type Y is new X;
end Untagged;
package Ok is new Untagged (Integer);
type Void is tagged null record;
package Err is new Untagged (Void); -- Error here
begin
null;
end B001_Tagged;
I get in both gnat 4.9.3 and gpl2016 the following error:
b001_tagged.adb:15:04: instantiation error at line 7
b001_tagged.adb:15:04: type derived from tagged type must have extension
gnatmake: "b001_tagged.adb" compilation error
I would expect that the view inside the generic package is untagged and
so the type renaming in line 7 should be correct? Or I'm floundering
with the generic parameter declaration?
Thanks,
Alex.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
@ 2016-11-25 19:17 ` Dmitry A. Kazakov
2016-11-28 14:54 ` Alejandro R. Mosteo
2016-11-25 19:18 ` AdaMagica
` (3 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Dmitry A. Kazakov @ 2016-11-25 19:17 UTC (permalink / raw)
On 2016-11-25 18:36, Alejandro R. Mosteo wrote:
> I need some eyes on this error because I'm missing something basic. When
> compiling this code:
>
> procedure B001_Tagged is
>
> generic
> type X is private;
> package Untagged is
>
> type Y is new X;
>
> end Untagged;
>
> package Ok is new Untagged (Integer);
>
> type Void is tagged null record;
>
> package Err is new Untagged (Void); -- Error here
>
> begin
> null;
> end B001_Tagged;
>
> I get in both gnat 4.9.3 and gpl2016 the following error:
>
> b001_tagged.adb:15:04: instantiation error at line 7
> b001_tagged.adb:15:04: type derived from tagged type must have extension
> gnatmake: "b001_tagged.adb" compilation error
>
> I would expect that the view inside the generic package is untagged and
> so the type renaming in line 7 should be correct? Or I'm floundering
> with the generic parameter declaration?
Yes, generics leak privacy and don't respect any contracts much.
Sometimes an actual tagged type matches formal private type and
sometimes it does not. Visibility rules are broken with respect to
tagged types even without generics (see earlier discussions about
private overriding).
Ada lawyers will surely tell you that it is OK because it cannot be
fixed. In some sense generics are indeed beyond any hope being weakly
typed, but still most outrageous examples could be fixed nevertheless.
And visibility rules can be fixed for sure.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
2016-11-25 19:17 ` Dmitry A. Kazakov
@ 2016-11-25 19:18 ` AdaMagica
2016-11-28 14:57 ` Alejandro R. Mosteo
2016-11-25 19:38 ` G.B.
` (2 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: AdaMagica @ 2016-11-25 19:18 UTC (permalink / raw)
RM 12.5.1(5/3) ... For a formal derived type declaration, the reserved words *with private* shall appear if and only if the ancestor type is a tagged type; in this case the formal derived type is a private extension of the ancestor type and the ancestor shall not be a class-wide type...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
2016-11-25 19:17 ` Dmitry A. Kazakov
2016-11-25 19:18 ` AdaMagica
@ 2016-11-25 19:38 ` G.B.
2016-11-26 8:45 ` Jacob Sparre Andersen
2016-11-28 23:25 ` Robert Eachus
4 siblings, 0 replies; 14+ messages in thread
From: G.B. @ 2016-11-25 19:38 UTC (permalink / raw)
On 25.11.16 18:36, Alejandro R. Mosteo wrote:
> b001_tagged.adb:15:04: instantiation error at line 7
> b001_tagged.adb:15:04: type derived from tagged type must have extension
> gnatmake: "b001_tagged.adb" compilation error
second opinion:
b001.ada: Error: line 15 col 38 LRM:3.4(5), A record_extension_part shall be provided if and only if the parent type is tagged; this applies in the visible part of a generic instantiation
(In instance of generic Untagged at b001.ada: line 7 col 12)
--
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
` (2 preceding siblings ...)
2016-11-25 19:38 ` G.B.
@ 2016-11-26 8:45 ` Jacob Sparre Andersen
2016-11-26 19:18 ` Tero Koskinen
2016-11-28 23:25 ` Robert Eachus
4 siblings, 1 reply; 14+ messages in thread
From: Jacob Sparre Andersen @ 2016-11-26 8:45 UTC (permalink / raw)
Alejandro R. Mosteo wrote:
> I need some eyes on this error because I'm missing something
> basic. When compiling this code:
>
> procedure B001_Tagged is
>
> generic
> type X is private;
> package Untagged is
>
> type Y is new X;
>
> end Untagged;
>
> package Ok is new Untagged (Integer);
>
> type Void is tagged null record;
>
> package Err is new Untagged (Void); -- Error here
>
> begin
> null;
> end B001_Tagged;
>
> I get in both gnat 4.9.3 and gpl2016 the following error:
>
> b001_tagged.adb:15:04: instantiation error at line 7
> b001_tagged.adb:15:04: type derived from tagged type must have extension
> gnatmake: "b001_tagged.adb" compilation error
>
> I would expect that the view inside the generic package is untagged
> and so the type renaming in line 7 should be correct?
I agree with your expectation.
I suspect that this is an error due to how GNAT expands generics. It
might be useful to try to see how Janus/Ada and ICC/Ada treats it. If I
remember correctly, Janus/Ada implements generics differently from GNAT.
Greetings,
Jacob
--
"... but I don't think even Tucker can do scheduling with no cost."
-- Randy Brukardt
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-26 8:45 ` Jacob Sparre Andersen
@ 2016-11-26 19:18 ` Tero Koskinen
2016-11-28 15:05 ` Alejandro R. Mosteo
0 siblings, 1 reply; 14+ messages in thread
From: Tero Koskinen @ 2016-11-26 19:18 UTC (permalink / raw)
26.11.2016, 10.45, Jacob Sparre Andersen wrote:
> Alejandro R. Mosteo wrote:
>
>> I get in both gnat 4.9.3 and gpl2016 the following error:
>>
>> b001_tagged.adb:15:04: instantiation error at line 7
>> b001_tagged.adb:15:04: type derived from tagged type must have extension
>> gnatmake: "b001_tagged.adb" compilation error
...
> I suspect that this is an error due to how GNAT expands generics. It
> might be useful to try to see how Janus/Ada and ICC/Ada treats it. If I
> remember correctly, Janus/Ada implements generics differently from GNAT.
Janus/Ada 3.1.2c result here, just a warning on line 13:
Input File Is C:\Work\mosteo-generic\B001_TAGGED.ADB
Pass II
Expected J2inst duplication to be the same
In File C:\Work\mosteo-generic\B001_TAGGED.ADB(13)
--------------
12:
13: type Void is tagged null record;
----------------^
*WARNING* Construct allowed only in a package specification (6.4.9)
Expected J2inst duplication to be the same
Bad or locked TREEFLAG.IN file -- see J3Tree_Debug
Pass III - JCode
Pass IV - 80386 Family
Creating C:\Work\mosteo-generic\B001_TAG.SRL
Thank You For Using JANUS/Ada
"Bad or locked TREEFLAG.IN file" seems to be some
fancy/harmless (debug?) info. I can link and run
the executable just fine.
>
> Greetings,
>
> Jacob
>
Yours,
Tero
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 19:17 ` Dmitry A. Kazakov
@ 2016-11-28 14:54 ` Alejandro R. Mosteo
0 siblings, 0 replies; 14+ messages in thread
From: Alejandro R. Mosteo @ 2016-11-28 14:54 UTC (permalink / raw)
On 25/11/16 20:17, Dmitry A. Kazakov wrote:
> On 2016-11-25 18:36, Alejandro R. Mosteo wrote:
>
>> I need some eyes on this error because I'm missing something basic. When
>> compiling this code:
>>
>> procedure B001_Tagged is
>>
>> generic
>> type X is private;
>> package Untagged is
>>
>> type Y is new X;
>>
>> end Untagged;
>>
>> package Ok is new Untagged (Integer);
>>
>> type Void is tagged null record;
>>
>> package Err is new Untagged (Void); -- Error here
>>
>> begin
>> null;
>> end B001_Tagged;
>>
>> I get in both gnat 4.9.3 and gpl2016 the following error:
>>
>> b001_tagged.adb:15:04: instantiation error at line 7
>> b001_tagged.adb:15:04: type derived from tagged type must have extension
>> gnatmake: "b001_tagged.adb" compilation error
>>
>> I would expect that the view inside the generic package is untagged and
>> so the type renaming in line 7 should be correct? Or I'm floundering
>> with the generic parameter declaration?
>
> Yes, generics leak privacy and don't respect any contracts much.
> Sometimes an actual tagged type matches formal private type and
> sometimes it does not. Visibility rules are broken with respect to
> tagged types even without generics (see earlier discussions about
> private overriding).
I'm still trying to come to terms with the RM and the other answers
posted, but I must say that if GNAT is correct in this case, it makes me
uneasily feel in C++ templating territory.
Alex.
> Ada lawyers will surely tell you that it is OK because it cannot be
> fixed. In some sense generics are indeed beyond any hope being weakly
> typed, but still most outrageous examples could be fixed nevertheless.
> And visibility rules can be fixed for sure.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 19:18 ` AdaMagica
@ 2016-11-28 14:57 ` Alejandro R. Mosteo
0 siblings, 0 replies; 14+ messages in thread
From: Alejandro R. Mosteo @ 2016-11-28 14:57 UTC (permalink / raw)
On 25/11/16 20:18, AdaMagica wrote:
> RM 12.5.1(5/3) ... For a formal derived type declaration, the reserved words *with private* shall appear if and only if the ancestor type is a tagged type; in this case the formal derived type is a private extension of the ancestor type and the ancestor shall not be a class-wide type...
>
My interpretation is that the formal used in my example belongs to
12.5.1(2), formal private type. This is of course assuming that the
generic formal declaration is interpreted from inside the generic and
not from the actual instance type used?
I had assumed that 3/2 applies when you want to make explicit to the
generic that the type comes from some form of derivation.
Alex.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-26 19:18 ` Tero Koskinen
@ 2016-11-28 15:05 ` Alejandro R. Mosteo
2016-11-28 21:32 ` Randy Brukardt
0 siblings, 1 reply; 14+ messages in thread
From: Alejandro R. Mosteo @ 2016-11-28 15:05 UTC (permalink / raw)
On 26/11/16 20:18, Tero Koskinen wrote:
> 26.11.2016, 10.45, Jacob Sparre Andersen wrote:
>> Alejandro R. Mosteo wrote:
>>
>>> I get in both gnat 4.9.3 and gpl2016 the following error:
>>>
>>> b001_tagged.adb:15:04: instantiation error at line 7
>>> b001_tagged.adb:15:04: type derived from tagged type must have extension
>>> gnatmake: "b001_tagged.adb" compilation error
> ...
>> I suspect that this is an error due to how GNAT expands generics. It
>> might be useful to try to see how Janus/Ada and ICC/Ada treats it. If I
>> remember correctly, Janus/Ada implements generics differently from GNAT.
>
> Janus/Ada 3.1.2c result here, just a warning on line 13:
> Input File Is C:\Work\mosteo-generic\B001_TAGGED.ADB
> Pass II
> Expected J2inst duplication to be the same
>
>
> In File C:\Work\mosteo-generic\B001_TAGGED.ADB(13)
> --------------
> 12:
> 13: type Void is tagged null record;
> ----------------^
> *WARNING* Construct allowed only in a package specification (6.4.9)
> Expected J2inst duplication to be the same
> Bad or locked TREEFLAG.IN file -- see J3Tree_Debug
> Pass III - JCode
> Pass IV - 80386 Family
> Creating C:\Work\mosteo-generic\B001_TAG.SRL
> Thank You For Using JANUS/Ada
> (...)
Thanks to everyone that answered/took the time to test.
So, to summarize: Janus/Ada accepts it, Gnat does not, and some other
compiler used by G.B. also rejects it.
Cheers,
Alex.
>
>>
>> Greetings,
>>
>> Jacob
>>
>
> Yours,
> Tero
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-28 15:05 ` Alejandro R. Mosteo
@ 2016-11-28 21:32 ` Randy Brukardt
2016-11-29 11:12 ` Alejandro R. Mosteo
2016-11-29 11:42 ` Dmitry A. Kazakov
0 siblings, 2 replies; 14+ messages in thread
From: Randy Brukardt @ 2016-11-28 21:32 UTC (permalink / raw)
For what it's worth, Janus/Ada is wrong here (it probably isn't making the
recheck of the instance; all of those have to be manually programmed and we
pretty much only implemented the checks that we've seen in ACATS tests or in
our own examples).
The issue in this case is that type Y is a visible, tagged type outside of
the instance. In that case, we can't allow a derivation without an extension
(both for consistency reasons and I believe there also are semantic
differences between tagged and untagged types).
But this is the one rule that we intentionally do not use the standard
boilerplate about the legality rule also applying in the private part.
Therefore, your example is legal so long as the derived type is not visible
outside of the generic. Specifically, I think (I didn't try it) that:
generic
type X is private;
package Untagged is
private
type Y is new X;
end Untagged;
In this case, there is no place where Y would ever be a tagged type, and
thus it isn't a problem for this to be legal.
The general principle is that all Ada legality rules are rechecked in the
specification of an instance, using the properties of the actual parameters.
In most cases (for most rules), this doesn't matter (nothing changes), but
there are cases where it matters and those are potentially
contract-breaking. That's annoying, but it is an intergral part of the Ada
model for generics (the alternative would have been to use assume-the-worst
rules in generic specifications, as is done in bodies, but that would make
generics almost useless for tagged types -- no extensions could be done in
generic specs under such a rule -- in particular, a mix-in generic would not
be possible. So, yes, Dmitry, the language could strengthen contracts this
way -- if one didn't care about usability [or compatibility]).
Randy.
"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
news:o1hh1b$13v$1@dont-email.me...
> On 26/11/16 20:18, Tero Koskinen wrote:
>> 26.11.2016, 10.45, Jacob Sparre Andersen wrote:
>>> Alejandro R. Mosteo wrote:
>>>
>>>> I get in both gnat 4.9.3 and gpl2016 the following error:
>>>>
>>>> b001_tagged.adb:15:04: instantiation error at line 7
>>>> b001_tagged.adb:15:04: type derived from tagged type must have
>>>> extension
>>>> gnatmake: "b001_tagged.adb" compilation error
>> ...
>>> I suspect that this is an error due to how GNAT expands generics. It
>>> might be useful to try to see how Janus/Ada and ICC/Ada treats it. If I
>>> remember correctly, Janus/Ada implements generics differently from GNAT.
>>
>> Janus/Ada 3.1.2c result here, just a warning on line 13:
>> Input File Is C:\Work\mosteo-generic\B001_TAGGED.ADB
>> Pass II
>> Expected J2inst duplication to be the same
>>
>>
>> In File C:\Work\mosteo-generic\B001_TAGGED.ADB(13)
>> --------------
>> 12:
>> 13: type Void is tagged null record;
>> ----------------^
>> *WARNING* Construct allowed only in a package specification (6.4.9)
>> Expected J2inst duplication to be the same
>> Bad or locked TREEFLAG.IN file -- see J3Tree_Debug
>> Pass III - JCode
>> Pass IV - 80386 Family
>> Creating C:\Work\mosteo-generic\B001_TAG.SRL
>> Thank You For Using JANUS/Ada
>> (...)
>
> Thanks to everyone that answered/took the time to test.
>
> So, to summarize: Janus/Ada accepts it, Gnat does not, and some other
> compiler used by G.B. also rejects it.
>
> Cheers,
> Alex.
>
>>
>>>
>>> Greetings,
>>>
>>> Jacob
>>>
>>
>> Yours,
>> Tero
>>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
` (3 preceding siblings ...)
2016-11-26 8:45 ` Jacob Sparre Andersen
@ 2016-11-28 23:25 ` Robert Eachus
4 siblings, 0 replies; 14+ messages in thread
From: Robert Eachus @ 2016-11-28 23:25 UTC (permalink / raw)
On Friday, November 25, 2016 at 12:36:26 PM UTC-5, Alejandro R. Mosteo wrote:
> Hello,
>
> I need some eyes on this error because I'm missing something basic. When
> compiling this code:
Try this:
procedure B001_Tagged is
generic
type X is private;
package Untagged is
type Y is private;
private
type Y is new X;
end Untagged;
package Ok is new Untagged (Integer);
type Void is tagged null record;
package Err is new Untagged (Void); -- Error here
begin
null;
end;
GNAT 6.1.1 seems to like it, and I don't see any reason it shouldn't. Of course, type Y is tagged inside the generic and untagged outside. If you assign a value of type Y or a child to a globally visible object of type X, it should work--but I certainly won't guarantee it unless tested.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-28 21:32 ` Randy Brukardt
@ 2016-11-29 11:12 ` Alejandro R. Mosteo
2016-11-29 11:42 ` Dmitry A. Kazakov
1 sibling, 0 replies; 14+ messages in thread
From: Alejandro R. Mosteo @ 2016-11-29 11:12 UTC (permalink / raw)
On 28/11/16 22:32, Randy Brukardt wrote:
> For what it's worth, Janus/Ada is wrong here (it probably isn't making the
> recheck of the instance; all of those have to be manually programmed and we
> pretty much only implemented the checks that we've seen in ACATS tests or in
> our own examples).
>
> The issue in this case is that type Y is a visible, tagged type outside of
> the instance. In that case, we can't allow a derivation without an extension
> (both for consistency reasons and I believe there also are semantic
> differences between tagged and untagged types).
>
> But this is the one rule that we intentionally do not use the standard
> boilerplate about the legality rule also applying in the private part.
> Therefore, your example is legal so long as the derived type is not visible
> outside of the generic. Specifically, I think (I didn't try it) that:
Thanks for the explanation, Randy, I begin to see the rationale and
ramifications of this. Although my example was simplified, it was from a
actual case in which indeed the new type was in the public part. I guess
I had never encountered this particular situation in 10+ years of Ada so
it got me by surprise.
Cheers,
Alex.
> generic
> type X is private;
> package Untagged is
> private
> type Y is new X;
> end Untagged;
>
> In this case, there is no place where Y would ever be a tagged type, and
> thus it isn't a problem for this to be legal.
>
> The general principle is that all Ada legality rules are rechecked in the
> specification of an instance, using the properties of the actual parameters.
> In most cases (for most rules), this doesn't matter (nothing changes), but
> there are cases where it matters and those are potentially
> contract-breaking. That's annoying, but it is an intergral part of the Ada
> model for generics (the alternative would have been to use assume-the-worst
> rules in generic specifications, as is done in bodies, but that would make
> generics almost useless for tagged types -- no extensions could be done in
> generic specs under such a rule -- in particular, a mix-in generic would not
> be possible. So, yes, Dmitry, the language could strengthen contracts this
> way -- if one didn't care about usability [or compatibility]).
>
> Randy.
>
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:o1hh1b$13v$1@dont-email.me...
>> On 26/11/16 20:18, Tero Koskinen wrote:
>>> 26.11.2016, 10.45, Jacob Sparre Andersen wrote:
>>>> Alejandro R. Mosteo wrote:
>>>>
>>>>> I get in both gnat 4.9.3 and gpl2016 the following error:
>>>>>
>>>>> b001_tagged.adb:15:04: instantiation error at line 7
>>>>> b001_tagged.adb:15:04: type derived from tagged type must have
>>>>> extension
>>>>> gnatmake: "b001_tagged.adb" compilation error
>>> ...
>>>> I suspect that this is an error due to how GNAT expands generics. It
>>>> might be useful to try to see how Janus/Ada and ICC/Ada treats it. If I
>>>> remember correctly, Janus/Ada implements generics differently from GNAT.
>>>
>>> Janus/Ada 3.1.2c result here, just a warning on line 13:
>>> Input File Is C:\Work\mosteo-generic\B001_TAGGED.ADB
>>> Pass II
>>> Expected J2inst duplication to be the same
>>>
>>>
>>> In File C:\Work\mosteo-generic\B001_TAGGED.ADB(13)
>>> --------------
>>> 12:
>>> 13: type Void is tagged null record;
>>> ----------------^
>>> *WARNING* Construct allowed only in a package specification (6.4.9)
>>> Expected J2inst duplication to be the same
>>> Bad or locked TREEFLAG.IN file -- see J3Tree_Debug
>>> Pass III - JCode
>>> Pass IV - 80386 Family
>>> Creating C:\Work\mosteo-generic\B001_TAG.SRL
>>> Thank You For Using JANUS/Ada
>>> (...)
>>
>> Thanks to everyone that answered/took the time to test.
>>
>> So, to summarize: Janus/Ada accepts it, Gnat does not, and some other
>> compiler used by G.B. also rejects it.
>>
>> Cheers,
>> Alex.
>>
>>>
>>>>
>>>> Greetings,
>>>>
>>>> Jacob
>>>>
>>>
>>> Yours,
>>> Tero
>>>
>>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-28 21:32 ` Randy Brukardt
2016-11-29 11:12 ` Alejandro R. Mosteo
@ 2016-11-29 11:42 ` Dmitry A. Kazakov
2016-11-29 23:48 ` Randy Brukardt
1 sibling, 1 reply; 14+ messages in thread
From: Dmitry A. Kazakov @ 2016-11-29 11:42 UTC (permalink / raw)
On 28/11/2016 22:32, Randy Brukardt wrote:
> So, yes, Dmitry, the language could strengthen contracts this
> way -- if one didn't care about usability [or compatibility]).
Rather one should make contracts more complete. If the formal type "X is
private" may or may not allow type cloning by "Y is new X" of the actual
type, that must be a part of the contract. E.g. tagged types should not
match or, better cloning hierarchies tagged types must be allowed.
The principal design rule should be legality to be determined
exclusively by visible specifications.
For generic formals it would mean resolving all conflicting declarations
in the formal part. For example:
generic
type T is private;
package
function "+" (Left, Right : T) return T; -- Must be illegal!
Reason: T might have "+" visible in the instantiation context. So the
package declaration must be:
generic
type T is private;
without function "+" (Left, Right : T) return T;
-- I promise there will be none
package
function "+" (Left, Right : T) return T; -- It is OK now
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Generic private type declaration
2016-11-29 11:42 ` Dmitry A. Kazakov
@ 2016-11-29 23:48 ` Randy Brukardt
0 siblings, 0 replies; 14+ messages in thread
From: Randy Brukardt @ 2016-11-29 23:48 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:o1jpiq$13df$1@gioia.aioe.org...
> On 28/11/2016 22:32, Randy Brukardt wrote:
>> So, yes, Dmitry, the language could strengthen contracts this
>> way -- if one didn't care about usability [or compatibility]).
>
> Rather one should make contracts more complete. If the formal type "X is
> private" may or may not allow type cloning by "Y is new X" of the actual
> type, that must be a part of the contract. E.g. tagged types should not
> match or, better cloning hierarchies tagged types must be allowed.
That would be hard to do, though. It would make generics rather hard to make
general. One sees that with formal arrays, where it is necessary to make two
versions of each generic, one for constrained array types and one for
unconstrained array types.
I tend to agree with your usual analysis that generics are never going to
really work in an O-O environment. If you make the contracts complete,
you'll end up with generics that hardly are generic at all (they'd only work
in very limited circumstances). And if you make them really loose (as in
C++), you can't really write a body that is certain to work, because too
much leaks through from the actuals.
Ada's approach tries to tread a middle ground, and as such it isn't
satisfying to anyone (but it also allows a lot of things that otherwise
would have to be banned unconditionally). Of course, when trying to have
ones cake and eat it too, its not unusual to get the rules wrong (either too
tight or too loose). I doubt that there really is a solution.
Randy.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-11-29 23:48 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-25 17:36 Generic private type declaration Alejandro R. Mosteo
2016-11-25 19:17 ` Dmitry A. Kazakov
2016-11-28 14:54 ` Alejandro R. Mosteo
2016-11-25 19:18 ` AdaMagica
2016-11-28 14:57 ` Alejandro R. Mosteo
2016-11-25 19:38 ` G.B.
2016-11-26 8:45 ` Jacob Sparre Andersen
2016-11-26 19:18 ` Tero Koskinen
2016-11-28 15:05 ` Alejandro R. Mosteo
2016-11-28 21:32 ` Randy Brukardt
2016-11-29 11:12 ` Alejandro R. Mosteo
2016-11-29 11:42 ` Dmitry A. Kazakov
2016-11-29 23:48 ` Randy Brukardt
2016-11-28 23:25 ` Robert Eachus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox