* MI for Ada @ 1999-02-11 0:00 Brian Rogoff 1999-02-11 0:00 ` Tucker Taft 0 siblings, 1 reply; 12+ messages in thread From: Brian Rogoff @ 1999-02-11 0:00 UTC (permalink / raw) Hi, I've been thinking lately about how to go about adding Java style interfaces or GNU C++ signatures to Ada. While syntax is probably the easiest part of such an addition, I thought I'd pose the topic here to others who've undoubtedly thought longer on this topic than I have. Does anyone have strong opinions on this topic (syntax), like whether new keywords should be added or not? I find the restricted MI of Java and GNU C++ signatures appealing. Ada already has forms of MI of implementation, so such an addition would make Ada OOP significantly nicer, without making it much more complex. Comments? -- Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-11 0:00 MI for Ada Brian Rogoff @ 1999-02-11 0:00 ` Tucker Taft 1999-02-12 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 12+ messages in thread From: Tucker Taft @ 1999-02-11 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > Hi, > I've been thinking lately about how to go about adding Java style > interfaces or GNU C++ signatures to Ada. While syntax is probably the > easiest part of such an addition, I thought I'd pose the topic here to > others who've undoubtedly thought longer on this topic than I have. Does > anyone have strong opinions on this topic (syntax), like whether new > keywords should be added or not? It is probably too soon to tell. I suggest you design the semantics of the feature. It may be that there are keywords that work already. Norm Cohen is famous for coming up with great combinations of existing keywords, if you need help. But don't be afraid of adding new keywords if necessary. > I find the restricted MI of Java and GNU C++ signatures appealing. > Ada already has forms of MI of implementation, so such an addition would > make Ada OOP significantly nicer, without making it much more complex. > Comments? I agree that multiple inheritance of *interface* only is a more pleasing approach than the full-blown MI of implementation (in two different ways!) found in C++. Future revisions to Ada will almost certainly be based on experimental results, rather than the pure thought experiments we were forced to use last time. So by all means, experiment! > > -- Brian -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-11 0:00 ` Tucker Taft @ 1999-02-12 0:00 ` Robert I. Eachus 1999-02-12 0:00 ` Brian Rogoff 1999-02-13 0:00 ` Alexy V Khrabrov 0 siblings, 2 replies; 12+ messages in thread From: Robert I. Eachus @ 1999-02-12 0:00 UTC (permalink / raw) In article <36C365F8.50E84F94@averstar.com> Tucker Taft <stt@averstar.com> writes: > It is probably too soon to tell. I suggest you design the > semantics of the feature. It may be that there are keywords that > work already. package Foo is new Bar(X,Y,Z) with body ... end Foo; Of course, given the opportunity to add a new body to a subprogram or package, it would also be useful to be able to define a template without an implementation: generic X,Y,Z: Integer; abstract package Bar is ... end Bar; It would be a very useful extension to the language. Any one want to work out the details of the semantics, then add it to gnat as a language extension? I suspect that taking it that far is not too much work, but the next step to allow a new generic to be derived from an existing and extend the interface is MUCH more work: generic type W is private; package Foo is new generic Bar with function Foobar return W; end Foo; -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-12 0:00 ` Robert I. Eachus @ 1999-02-12 0:00 ` Brian Rogoff 1999-02-13 0:00 ` Alexy V Khrabrov 1 sibling, 0 replies; 12+ messages in thread From: Brian Rogoff @ 1999-02-12 0:00 UTC (permalink / raw) On 12 Feb 1999, Robert I. Eachus wrote: > Tucker Taft <stt@averstar.com> writes: > > > It is probably too soon to tell. I suggest you design the > > semantics of the feature. It may be that there are keywords that > > work already. > > package Foo is new Bar(X,Y,Z) with body ... end Foo; Hmmm, you seem to be designing an "MI of package" facility. I was thinking of something more like Java interfaces, which would allow types to conform to multiple interfaces based on the set of primitive functions they support. I'd like to have access to interface variables too, so that I could define subprograms which are defined in terms of such variables, and would work on any access types which conform to the stated interface. If you know about GNU C++ signatures, thats really what I have in mind. No fundamental extensions to Ada's package system, just a way to specify signatures/interfaces, access to signature/interface, probably a "sigof" construct to get a signature from a type, and of course all the necessary changes to have generic formal signature parameters. There are probably some opportunities for streamlining Ada's package composition facilities by adding some kind of package inheritance; for example I'd love to be able to define generic signature packages for the different categories of iterator incrementally. Is that the sort of problem your proposal is meant to address? -- Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-12 0:00 ` Robert I. Eachus 1999-02-12 0:00 ` Brian Rogoff @ 1999-02-13 0:00 ` Alexy V Khrabrov 1999-02-14 0:00 ` Nick Roberts 1 sibling, 1 reply; 12+ messages in thread From: Alexy V Khrabrov @ 1999-02-13 0:00 UTC (permalink / raw) Robert I. Eachus wrote [an unspeakable blasphemy in 1983] in his message: > It would be a very useful extension to the language. Any one want >to work out the details of the semantics, then add it to gnat as a >language extension? I suspect that taking it that far is not too much It's just amazing how a strict monastery whose charter is LRM can get soft during Clinton's administration! :-)) That's what governmental affiliation does even to the creme-de-la-creme sect of the Ada gurus! No wonder the Standard and ACVC were a part of Reaganomics... Nah, nothing's clear in these times... OOPs/ShmOOPs... :-))) MS Projects taking over people's lives, malicious MS Objects COMmunicating with Ketzalkoatl, their master and protector... Brrrr... Still, Clinton/Java is better than Reagan/Ada! Sad but true, you may not be a programmer, but have to be a citizen. Cheers, Alexy ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-13 0:00 ` Alexy V Khrabrov @ 1999-02-14 0:00 ` Nick Roberts 1999-02-15 0:00 ` robert_dewar 1999-02-16 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 12+ messages in thread From: Nick Roberts @ 1999-02-14 0:00 UTC (permalink / raw) Alexy V Khrabrov wrote in message <7a2j8q$meo@bgtnsc01.worldnet.att.net>... | |Robert I. Eachus wrote [an unspeakable blasphemy in 1983] in his message: | |> It would be a very useful extension to the language. Any one want |>to work out the details of the semantics, then add it to gnat as a |>language extension? I suspect that taking it that far is not too much A blasphemy in 1983 perhaps, but not such a blasphemy now. Provided the extended syntax is rejected when the compiler is in 'standard mode', and accepted in some special mode (probably activated by a compiler flag), the sacred snake remains in his lair. Actually, it occurs to me that there is no particular difficulty in providing multiple inheritance from several publicly null-record tagged types at the same time. The new type would have to implement all the promised subprograms of both/all its parents, and (probably) it would have to be illegal for any such subprograms to 'overlap' (have same name & profile). Class membership tests for such types could be implemented by chaining the descriptors in series (the user would never know). For example: package Pa is type Ta is abstract tagged null record; function F1 (X: in Ta) return Ta is abstract; end Pa; package Pb is type Tb is abstract tagged null record; function F2 (X: in Tb) return Tb is abstract; end Pa; package Pc is type Tc is new Ta, Tb with private; function F1 (X: in Tc) return Tc; function F2 (X: in Tc) return Tc; private ... end Pc; The last type declaration would really just be a convenient way of writing type anon is new Ta with null record; function F2 (X: in anon) return anon is abstract; type Tc is new anon with private; or equally type anon is new Tb with null record; function F1 (X: in anon) return anon is abstract; type Tc is new anon with private; but I think it's clear that this could be a facility that would be very convenient at times. There would be a difference, in that both "X in Ta'Class" and "X in Tb'Class" would be true, if X were of type Tc. This functionality could be implemented by making a copy of the descriptor (the vector table) for Ta, and parent-linking this vector table to Tb, and then Tc's descriptor to this special copy of Ta's. You would have to store a tag value in each descriptor (rather than using the address of the descriptor as the tag). I suspect this is stuff that the Ada 95 design people went over (a lot). Something for Ada 200X, perhaps? ------------------------------------------- Nick Roberts The meek shall inherit the Earth. And then pay the capital transfer tax on it in full. ------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-14 0:00 ` Nick Roberts @ 1999-02-15 0:00 ` robert_dewar 1999-02-18 0:00 ` Nick Roberts 1999-02-16 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 12+ messages in thread From: robert_dewar @ 1999-02-15 0:00 UTC (permalink / raw) In article <7a7aav$mse$2@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote: > A blasphemy in 1983 perhaps, but not such a blasphemy > now. Provided the extended syntax is rejected when the > compiler is in 'standard mode', and > accepted in some special mode (probably activated by a > compiler flag), the sacred snake remains in his lair. It is equally valid to have the RM mode activated by a flag, there is no sense which requires the "default" mode (whatever that means) to be the RM mode. > > Actually, it occurs to me that there is no particular > difficulty in providing multiple inheritance from several > publicly null-record tagged types at the same time. Hmm! Nick, you have a long way to go in analyzing difficult RM issues. No particular difficulty??? This is in fact a VERY difficult proposal to get right, and almost certainly it will run aground on any number of rocks on the way. Have you read the AI's. I assume so if you are even vaguely serious about implementing an Ada 95 compiler. If not, you should, it would give you an interesting insight into the delicate semantic issues of the language. Actually reading the AARM is also a good way to get a feeling for this. Multiple inheritance is a well known landmine in programming language semantic definition land! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-15 0:00 ` robert_dewar @ 1999-02-18 0:00 ` Nick Roberts 0 siblings, 0 replies; 12+ messages in thread From: Nick Roberts @ 1999-02-18 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com wrote in message <7a86q2$kec$1@nnrp1.dejanews.com>... [...] |Hmm! Nick, you have a long way to go in analyzing difficult |RM issues. No particular difficulty??? This is in fact a |VERY difficult proposal to get right, and almost certainly |it will run aground on any number of rocks on the way. | |Multiple inheritance is a well known landmine in |programming language semantic definition land! Noted. |Have you read the AI's. I assume so if you are even vaguely |serious about implementing an Ada 95 compiler. If not, you |should, it would give you an interesting insight into the |delicate semantic issues of the language. Actually reading |the AARM is also a good way to get a feeling for this. I'm in the process of reading the AI95s and the AARM. And yes, both are most illuminating. Entertaining too, sometimes. The comment on the end of the AI on the 'List' pragma - something like "this must be the most pointless AI imaginable" - made me laugh out loud. I was amazed at how another (admittedly unimportant) AI, about time zones, seems to be just dropped unresolved. But that'll keep for another thread. And yes, I am serious about it. I don't have any great illusion about the enormity of the task - I suppose I feel a bit like Edmund Hillary or Tensing Norgay standing at the foot of Mt Everest/Chomolungma - but I intend to conquer! ------------------------------------- Nick Roberts Nothing Venture, Nothing Win ------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-14 0:00 ` Nick Roberts 1999-02-15 0:00 ` robert_dewar @ 1999-02-16 0:00 ` Robert I. Eachus 1999-02-16 0:00 ` robert_dewar 1999-02-17 0:00 ` Brian Rogoff 1 sibling, 2 replies; 12+ messages in thread From: Robert I. Eachus @ 1999-02-16 0:00 UTC (permalink / raw) In article <7a7aav$mse$2@plug.news.pipex.net> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes: > A blasphemy in 1983 perhaps, but not such a blasphemy now. Provided the > extended syntax is rejected when the compiler is in 'standard mode', and > accepted in some special mode (probably activated by a compiler flag), the > sacred snake remains in his lair. You have to understand that there are two roles involved, and most good language lawyers are also language designers, closet or otherwise. And as you are aware in Ada 83 the rule was "no unauthorized extensions." In Ada 95, there must be a standard conforming mode. One of the hopes for the GNAT project is that it will make trying out potential extensions much easier. The extension of generics that I suggested is mostly syntactic sugar, but I think it is the kind of extension that "Makes Ada more Ada-like." It makes such tailorable generic packages easier for the reader to understand. Instead of a generic with dozens or hundreds of formal parameters, you make it clear you are declaring the interface, and the instantiation must provide a body. A perfect example of how to use this is sorting. You could have a package with a (generic formal subprogram) parameter which indicates the sort algorithm desired. This is possible now, I was just suggesting a much cleaner syntax. > Actually, it occurs to me that there is no particular difficulty in > providing multiple inheritance from several publicly null-record tagged > types at the same time. The new type would have to implement all the > promised subprograms of both/all its parents, and (probably) it would have > to be illegal for any such subprograms to 'overlap' (have same name & > profile). Class membership tests for such types could be implemented by > chaining the descriptors in series (the user would never know). Actually you don't need the rule about overlapping, you can either have a rule about precedence order, or better, require that any such subprogram be explicitly overridden, with the possible exception of "=". That seems much more like the Ada way. > Something for Ada 200X, perhaps? There is a major difference between making multiple inheritance workable, and making it useful. I'm convinced that for Ada, the first is possible, but with the mix-in idiom that is very usable now, I don't see what "true" multiple inheritance gains other than to confuse the definition of parent type. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-16 0:00 ` Robert I. Eachus @ 1999-02-16 0:00 ` robert_dewar 1999-02-16 0:00 ` Robert I. Eachus 1999-02-17 0:00 ` Brian Rogoff 1 sibling, 1 reply; 12+ messages in thread From: robert_dewar @ 1999-02-16 0:00 UTC (permalink / raw) In article <EACHUS.99Feb16110742@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) wrote: > And as you are aware in Ada 83 the rule was "no > unauthorized extensions." In Ada 95, there must be a > standard conforming mode. This is highly misleading. There has been no change here between Ada 83 and Ada 95. It was always understood and never questioned that Ada compilers could have flags that caused them to operate in some non-standard mode, and this was true from the start for Ada 83. For example, nearly all compilers had a flag for suppressing runtime checks. The ARG discussed this a few times, and always unanimously agreed that even the most outrageous switches were perfectly fine as long as there was a standard conforming mode, and the ACVC procedures have always required that the VSR document the switches used to achieve this mode. So Robert Eachus' implication that there has been some shift in the Ada 95 design here is, as they would say in the British parliament, a "terminological inexactitude". -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-16 0:00 ` robert_dewar @ 1999-02-16 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 12+ messages in thread From: Robert I. Eachus @ 1999-02-16 0:00 UTC (permalink / raw) In article <7acbdd$316$1@nnrp1.dejanews.com> robert_dewar@my-dejanews.com writes: > So Robert Eachus' implication that there has been some > shift in the Ada 95 design here is, as they would say > in the British parliament, a "terminological inexactitude". Sorry, I always thought that the "no unauthorized extensions" was a clever in joke, but I guess it is a little too in for this forum. It looks like a draconian rule, but in practice it is a license with very little limitation except good documentation. For example, it has always been perfectly legitimate in terms of validation to have a compiler which under the influence of some mysterious switch compiled FORTRAN or C instead of Ada. In fact, some compilers that do just that based on the name of the source file presented to them. ;-) As Robert points out, there is no real difference between the Ada 83 and Ada 95 validation rules in terms of conformance, even though the RM wording is a little different: Ada 83 RM 1.1.2(6-7): "(e) Contains no variations except where the standard permits. "(f) Specifies all such permitted variations in the manner prescribed by the standard." Ada 95 RM 1.1.3(6-7): "- Contain no variations except those explicity permitted by this International Standard, or those that are impossible or impractical to avoid given the implementation's execution environment; "- Specify all such variations in the manner prescribed by this International Standard." In Ada 83, these variations were specified in Appendix F, and in Ada 95 they are found in Annex M. In either version, if you care about conformance to the standard you will have a copy of this close at hand, along with the Validation Summary Report. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MI for Ada 1999-02-16 0:00 ` Robert I. Eachus 1999-02-16 0:00 ` robert_dewar @ 1999-02-17 0:00 ` Brian Rogoff 1 sibling, 0 replies; 12+ messages in thread From: Brian Rogoff @ 1999-02-17 0:00 UTC (permalink / raw) On 16 Feb 1999, Robert I. Eachus wrote: > The extension of generics that I suggested is mostly syntactic > sugar, but I think it is the kind of extension that "Makes Ada more > Ada-like." It makes such tailorable generic packages easier for the > reader to understand. Instead of a generic with dozens or hundreds of > formal parameters, you make it clear you are declaring the interface, > and the instantiation must provide a body. A perfect example of how > to use this is sorting. You could have a package with a (generic > formal subprogram) parameter which indicates the sort algorithm > desired. This is possible now, I was just suggesting a much cleaner > syntax. I'd be interested in seeing some more examples of your proposal in use, since I don't think I understand its semantics yet. > > Actually, it occurs to me that there is no particular difficulty in > > providing multiple inheritance from several publicly null-record tagged > > types at the same time. The new type would have to implement all the > > promised subprograms of both/all its parents, and (probably) it would have > > to be illegal for any such subprograms to 'overlap' (have same name & > > profile). Class membership tests for such types could be implemented by > > chaining the descriptors in series (the user would never know). > > Actually you don't need the rule about overlapping, you can either > have a rule about precedence order, or better, require that any such > subprogram be explicitly overridden, with the possible exception of "=". > That seems much more like the Ada way. > > > Something for Ada 200X, perhaps? > > There is a major difference between making multiple inheritance > workable, and making it useful. I'm convinced that for Ada, the first > is possible, but with the mix-in idiom that is very usable now, I > don't see what "true" multiple inheritance gains other than to confuse > the definition of parent type. How about "false" multiple inheritance, a-la Java, Objective-C, GNU C++ with signatures, etc? Following the GNU C++ idea, we create some new entities, signatures and signature access types. These signatures correspond directly to Java interfaces, and the signature access types are there so that you can declare variables which conform to a signature. I think the general idea is fairly simple, and provides something that Ada doesn't handle well right now with its mix-in idioms. Unfortunately, I suspect the integration into Ada requires someone with a bigger brain than mine, or at least one that lives and breathes RM and AARM :-). -- Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1999-02-18 0:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-02-11 0:00 MI for Ada Brian Rogoff 1999-02-11 0:00 ` Tucker Taft 1999-02-12 0:00 ` Robert I. Eachus 1999-02-12 0:00 ` Brian Rogoff 1999-02-13 0:00 ` Alexy V Khrabrov 1999-02-14 0:00 ` Nick Roberts 1999-02-15 0:00 ` robert_dewar 1999-02-18 0:00 ` Nick Roberts 1999-02-16 0:00 ` Robert I. Eachus 1999-02-16 0:00 ` robert_dewar 1999-02-16 0:00 ` Robert I. Eachus 1999-02-17 0:00 ` Brian Rogoff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox