ANN: Ada 2005 Math Extensions, 20100810 release
in [ADA]
|
Prev: Ada 2012: An Oops in the new Ada amendments ? (in 10.1.2 ContextClauses - With Clauses)
Next: Ada 2012: An Oops in the new Ada amendments ? (in 10.1.2 Context Clauses - With Clauses)
From: Dmitry A. Kazakov on 13 Aug 2010 09:57 On Fri, 13 Aug 2010 15:41:08 +0200, Yannick Duchêne (Hibou57) wrote: >> ** We were told how dreadful the diamond is, so bad that Ada may not allow >> to have MI, but for sacred generics anything is perfectly OK! > Did not understood this sentence, at least the last “but for sacred > generics anything is perfectly OK!” Any problems MI is accused of do exist in generics and interfaces. But Ada 2005 had got ugly Java interfaces instead of clean MI. A combination of Java interfaces with generics in order to achieve MI is the worst thing ever invented. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Simon Wright on 13 Aug 2010 15:50 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > Yes, especially because of two "Extensions". I had immense problems with > names. Look at this: > > http://www.dmitry-kazakov.de/ada/fuzzy_packages.gif Gosh! From a UML background (OK, OK, ...) I'd have the arrows pointing the other way ('depends on' rather than 'is used in' or 'supports'). > Somewhere down deep the hierarchy the user starts to become > incomprehensive error messages upon instantiation within the > generic(!) bodies. It is practically impossible to understand what is > wrong, is it a compiler bug (in GNAT case) or something else. For the > user it would be a nightmare to fight this. I think I've come across a GNAT bug here .. I dont think it's allowed for a generic to compile but the instantiation not! > Another rule of thumb (I don't know if this is going to be fixed in > Ada 2012), is that a child should always rename formal generic > arguments in its specifications. Under certain circumstances, usually > in children, they might become unavailable. I mean this: > > generic > with package P is new Generic_P (<>); > package Generic_S is > package P_Of renames P; -- You will need this! > > Sometimes you need to "rename" formal types as well: > > generic > type Foo is ... > package Generic_S is > subtype Foo_Of is Foo; -- What a mess! I've more often come across the latter. Could consider generic type Formal_Foo is ... package Generic_S is subtype Foo is Formal_Foo;
From: Yannick Duchêne (Hibou57) on 13 Aug 2010 16:17 Le Fri, 13 Aug 2010 21:50:07 +0200, Simon Wright <simon(a)pushface.org> a écrit: > I've more often come across the latter. > > Could consider > > generic > type Formal_Foo is ... > package Generic_S is > subtype Foo is Formal_Foo; > The trouble with this one, is that it move the case to the client side.... I would not like to generic instantiations âobfuscatedâ with all of those Formal_Foo (I always use named parameter associations... especially with generic instantiations). The Dmitry way, which is also the one I use, end to be less intrusive, as the client of the generic package is less likely to have to spell this somewhere (except if it/he/she has to use a formal parameter of a given instantiated package to instantiate another). -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Simon Wright on 13 Aug 2010 18:04 "Yannick Duchêne (Hibou57)" <yannick_duchene(a)yahoo.fr> writes: > Le Fri, 13 Aug 2010 21:50:07 +0200, Simon Wright <simon(a)pushface.org> > a écrit: >> I've more often come across the latter. >> >> Could consider >> >> generic >> type Formal_Foo is ... >> package Generic_S is >> subtype Foo is Formal_Foo; >> > The trouble with this one, is that it move the case to the client > side... I would not like to generic instantiations “obfuscated” with > all of those Formal_Foo (I always use named parameter > associations... especially with generic instantiations). > > The Dmitry way, which is also the one I use, end to be less intrusive, > as the client of the generic package is less likely to have to spell > this somewhere (except if it/he/she has to use a formal parameter of > a given instantiated package to instantiate another). Well, I couldn't see how Dmitry's "Foo_Of" would make sense as it was being read. procedure P (Q : Generic_S.Foo_Of); -- huh? I suppose one could say generic type Foo is ... package Generic_S is subtype Actual_Foo is Foo; (since we're adopting the "spelt-out prefix" style, Generic_, rather than the "abbreviated suffix" style, _G !) though I see that the last time I used it was the other way round .. generic type Actual_Foo is ... package Generic_S is subtype Foo is Actual_Foo;
From: Yannick Duchêne (Hibou57) on 13 Aug 2010 18:28
Le Sat, 14 Aug 2010 00:04:17 +0200, Simon Wright <simon(a)pushface.org> a écrit: >> Le Fri, 13 Aug 2010 21:50:07 +0200, Simon Wright <simon(a)pushface.org> > Well, I couldn't see how Dmitry's "Foo_Of" would make sense as it was > being read. > > procedure P (Q : Generic_S.Foo_Of); -- huh? > > I suppose one could say > > generic > type Foo is ... > package Generic_S is > subtype Actual_Foo is Foo; I said too much less, sorry, so you could not understand what I was to say I would rather write generic type Foo is ... package Generic_S is subtype Formal_Foo is Foo; The name is not the same as the one Dmitry suggested, while the principle is the same : name formal parameter after the name their should have, and use renamed subtype in the package (just the name vary, and indeed it should be expressive and clear enough). > procedure P (Q : Generic_S.Foo_Of); -- huh? This would turn this into procedure P (Q : Generic_S.Foo_Of); which is also not so much used for me (do not know for others who live with other cases in mind). The count of generic instantiations is bigger than the one reference to this Package_Name.Formal_Subtype, which by the way, mainly appears as generic parameters when needed, like âpackage Blabla_Instance is new Generic_Blabla (Blabla_Base_Type => Instantiated_Package.Formal_Type);â These Formal_Subtype_Name are most of time not part of what is provided by the package (otherwise, it would simply provide nothing except what already exists), so as most of time not referenced when what the package provided is referenced (from the client side). But this may be required to make reference to a package's formal parameters with mixins (if I am not wrong, I had this requirement with some kind mixins). Pretty sure this is not so much referenced by clients, for the reason given above, that this is not what a package mainly provides. This is most needed to link generic packages each others. So (providing the latter assumption is OK), giving a proper name to formal parameters and only give special names to subtype of these formals, is likely to avoid to have to deal with obfuscated names as much as possible. |