* Your wish list for Ada 202X @ 2014-03-25 21:41 Stoik 2014-03-25 22:14 ` Simon Wright ` (10 more replies) 0 siblings, 11 replies; 240+ messages in thread From: Stoik @ 2014-03-25 21:41 UTC (permalink / raw) I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X? I suspect many of the proposals could be tested in GNAT before being introduced (or rejected) in the new version. One could add a switch to GNAT indicating that we want to use some of the experimental features. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik @ 2014-03-25 22:14 ` Simon Wright 2014-03-26 6:25 ` Shark8 ` (9 subsequent siblings) 10 siblings, 0 replies; 240+ messages in thread From: Simon Wright @ 2014-03-25 22:14 UTC (permalink / raw) Stoik <staszek.goldstein@gmail.com> writes: > One could add a switch to GNAT indicating that we want to use some of > the experimental features. I'm pretty sure it is -gnatX. What, if anything, it enables at the moment I don't know .. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik 2014-03-25 22:14 ` Simon Wright @ 2014-03-26 6:25 ` Shark8 2014-03-26 20:41 ` Randy Brukardt 2014-03-26 8:17 ` Dmitry A. Kazakov ` (8 subsequent siblings) 10 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-03-26 6:25 UTC (permalink / raw) On 25-Mar-14 14:41, Stoik wrote: > I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada > 202X? > > I suspect many of the proposals could be tested in GNAT before being > introduced (or rejected) in the new version. One could add a switch to > GNAT indicating that we want to use some of the experimental features. (1) I think we should look at simplifying the standard packages. Consider also the [[wide_]wide_]string packages and the relationship to [[wide_]wide_]character -- it would be very nice (as well as aiding maintainability) to have the *_String [and character-handling] packages be generics instantiated on the proper Character type. (2) I also think that the INTERFACE construct could be more beneficial introducing properties (virtual fields; possibly with IN / IN OUT / OUT modes) and a way to delegate them... Delphi has an IMPLEMENTS keyword which allows you to have a field (or property) that implements the maned interface ( see: http://stackoverflow.com/a/6067165 ) -- IIRC you can also do "partial delegation" and resolution so that, given two INTERFACEs I1 and I2 which both have "function Count( Input : I* ) : Integer" and you could use both w/o any great gymnastics. type TObj = Class(I1, I2) private FCount : Integer; {Internal count for something.} FItems : Array of TSomeObject; {Dynamically sized array.} function Get_length : Integer implements I2.Count; public {This treats the read of count as a function-call.} property Count : Integer read FCount implements I1.Count; end; {TObj} {...} function TObj.Get_length : Integer; begin Get_Length := Length( FItems ); end; (3) Third, I think it would be good to extend the FOR loop once again; this time giving access to the cursor involved, this way the index can be retrieved in the new-style loops. -- Given Table : array (1..20, 1..20) of Positive we wish to populate it -- with Pascal's Triangle. For Element of Table loop -- We remember that to construct the triangle there are two rules: -- 1) If the row or the column is 1, then the value of the cell is 1, -- 2) Otherwise, the value is the sum of the its predecessor in the -- row and its predecessor in the column. Element:= (if Element'Index(1) = 1 or Element'Index(2) = 1 then else Table(Element'Index(1)-1,Element'Index(2) ) + Table(Element'Index(1) ,Element'Index(2)-1) ); end loop; ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 6:25 ` Shark8 @ 2014-03-26 20:41 ` Randy Brukardt 2014-03-27 9:20 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-03-26 20:41 UTC (permalink / raw) "Shark8" <OneWingedShark@gmail.com> wrote in message news:tvtYu.83108$tD4.27538@fx25.iad... > On 25-Mar-14 14:41, Stoik wrote: >> I think that even a casual user of Ada should be able to influence >> somehow the new >> version of Ada. I wonder what is high on your list of wishes for Ada >> 202X? ... > (1) > I think we should look at simplifying the standard packages. > > Consider also the [[wide_]wide_]string packages and the relationship to > [[wide_]wide_]character -- it would be very nice (as well as aiding > maintainability) to have the *_String [and character-handling] packages be > generics instantiated on the proper Character type. I agree that this is an area that needs looking at, but I don't think using more generics will provide anything useable. The problem, as Dmitry likes to say, is that the representation and semantics of a string are intertwined, and those have to be separated in order to make a sensible string type system. I've played with some ideas based on an abstract Root_String'Class, and pretty much everything necessary can be done with existing Ada 2012 features, and the few things that can't have a fairly obvious language feature that could be defined to provide them (for instance, a mechanism to support string literals). I think the problem is mainly going to be political rather than technical. The solution requires defining a large set of new packages that echo functionality already in the language, and that would not be used by the sorts of safety-critical applications that the paying customers use. (They're not using Text_IO or Unbounded_Strings or Directories or ...). That's going to make changes in this area a tough sell, I fear. Hope I'm wrong. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 20:41 ` Randy Brukardt @ 2014-03-27 9:20 ` Shark8 2014-03-27 21:50 ` Randy Brukardt 2014-03-27 22:06 ` Randy Brukardt 0 siblings, 2 replies; 240+ messages in thread From: Shark8 @ 2014-03-27 9:20 UTC (permalink / raw) On 26-Mar-14 13:41, Randy Brukardt wrote: > "Shark8" <OneWingedShark@gmail.com> wrote in message > news:tvtYu.83108$tD4.27538@fx25.iad... >> On 25-Mar-14 14:41, Stoik wrote: >>> I think that even a casual user of Ada should be able to influence >>> somehow the new >>> version of Ada. I wonder what is high on your list of wishes for Ada >>> 202X? > ... >> (1) >> I think we should look at simplifying the standard packages. >> >> Consider also the [[wide_]wide_]string packages and the relationship to >> [[wide_]wide_]character -- it would be very nice (as well as aiding >> maintainability) to have the *_String [and character-handling] packages be >> generics instantiated on the proper Character type. > > I agree that this is an area that needs looking at, but I don't think using > more generics will provide anything useable. The problem, as Dmitry likes to > say, is that the representation and semantics of a string are intertwined, > and those have to be separated in order to make a sensible string type > system. Hm, not even with the new incomplete-type allowances for generics? Perhaps a "abstract interface" / "abstract type" could be made where, you can sever the representation and semantics? > I've played with some ideas based on an abstract Root_String'Class, and > pretty much everything necessary can be done with existing Ada 2012 > features, and the few things that can't have a fairly obvious language > feature that could be defined to provide them (for instance, a mechanism to > support string literals). Hm, Really? Care to share your findings? > I think the problem is mainly going to be political rather than technical. > The solution requires defining a large set of new packages that echo > functionality already in the language, and that would not be used by the > sorts of safety-critical applications that the paying customers use. > (They're not using Text_IO or Unbounded_Strings or Directories or ...). > That's going to make changes in this area a tough sell, I fear. Hope I'm > wrong. That's rather sad; I'd hope for Ada to be a technically superior language -- IMO, it already is in several respects... but that's no reason to slack off and not strive for higher quality. ------------ Any comment on idea #2 or #3? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 9:20 ` Shark8 @ 2014-03-27 21:50 ` Randy Brukardt 2014-03-28 1:54 ` Jeffrey Carter 2014-03-28 8:17 ` Dmitry A. Kazakov 2014-03-27 22:06 ` Randy Brukardt 1 sibling, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-03-27 21:50 UTC (permalink / raw) "Shark8" <OneWingedShark@gmail.com> wrote in message news:x9RYu.3020$XJ3.767@fx09.iad... > On 26-Mar-14 13:41, Randy Brukardt wrote: ... >> I've played with some ideas based on an abstract Root_String'Class, and >> pretty much everything necessary can be done with existing Ada 2012 >> features, and the few things that can't have a fairly obvious language >> feature that could be defined to provide them (for instance, a mechanism >> to >> support string literals). > > Hm, Really? Care to share your findings? Of course really. The rough sketch is in the !discussion of AI12-0021-1. Please note that we've never discussed this AI within the ARG, so I might be the only one interested in persuing this idea. I've fleshed it out further mentally; in particular, one could imagine supporting conversions through a common type (in this case Wide_Wide_String). The primary "problem" is that in this model, most strings become tagged and communicate using Wide_Wide_Character and Wide_Wide_String. That probably seems more inefficient than it actually is (after all, Unbounded_Strings are already tagged -- controlled, actually -- and this couldn't be less efficient than that, so long as the language-defined types stick to single inheritance). For the characters, the representation doesn't matter much (and on a 32-bit machine, they're all the same performance anyway). So the main issue is the cost of converting to-from Wide_Wide_String. Perhaps there is some other way to ensure universal convertability which doesn't require performance-sapping multiple inheritance or multidispatching. After all, if storage space is not a concern, Wide_Wide_String is the most universal (and efficient) representation. It seems that it makes the most sense to do operations in terms of that type and convert for storage -- since that's what will happen naturally most of the time. (Presuming you're not so American-centric that you don't care about anything beyond type String. :-) Anyway, lots more thought needed. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 21:50 ` Randy Brukardt @ 2014-03-28 1:54 ` Jeffrey Carter 2014-03-28 8:17 ` Dmitry A. Kazakov 1 sibling, 0 replies; 240+ messages in thread From: Jeffrey Carter @ 2014-03-28 1:54 UTC (permalink / raw) On 03/27/2014 02:50 PM, Randy Brukardt wrote: > > After all, if storage space is not a concern, Wide_Wide_String is the most > universal (and efficient) representation. It seems that it makes the most > sense to do operations in terms of that type and convert for storage -- > since that's what will happen naturally most of the time. (Presuming you're > not so American-centric that you don't care about anything beyond type > String. :-) I guess storage space is not a concern for Erlang. The string "ABC" is shorthand for the list [65, 66, 67], and apparently each "character" takes 8 bytes: 4 for the number, and 4 for the pointer to the next element in the list. Using 4 bytes for the character is sometimes called support for Unicode. Why not define Character as 32 bits and get rid of the Wide_ guys? -- Jeff Carter "My brain hurts!" Monty Python's Flying Circus 21 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 21:50 ` Randy Brukardt 2014-03-28 1:54 ` Jeffrey Carter @ 2014-03-28 8:17 ` Dmitry A. Kazakov 2014-03-28 21:27 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-28 8:17 UTC (permalink / raw) On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote: > The primary "problem" is that in this model, most strings become tagged and > communicate using Wide_Wide_Character and Wide_Wide_String. In another model only Wide_Wide_String'Class would be tagged. Real issue: Classes of non-tagged types. > So the > main issue is the cost of converting to-from Wide_Wide_String. You would not need conversions if the specific operations were provided rather than inherited (as they are provided presently). Real issue: Multi-methods (String vs String) and full multiple dispatch (String vs Character) To reiterate the point. The implementation of strings in Ada is all OK, it is the interface to this implementation which sucks. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-28 8:17 ` Dmitry A. Kazakov @ 2014-03-28 21:27 ` Randy Brukardt 2014-03-29 9:44 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-03-28 21:27 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net... > On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote: ... > Real issue: Multi-methods (String vs String) and full multiple dispatch > (String vs Character) That's an alternative, but the question is whether that can be implemented with less overhead than the scheme I suggested. I believe the answer is no, at least within generalized string packages (which hopefully will become the norm for new string operations in Ada). It's surely one of the questions to be considered - nothing I think on this topic (or any topic, for that matter) is likely to be the last word. > To reiterate the point. The implementation of strings in Ada is all OK, it > is the interface to this implementation which sucks. Right, but that manifests itself in duplicated and overly restrictive packages, which would have to be reworked in order to use a more general interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular have overloaded operations that would make everything ambiguous if not eliminated.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-28 21:27 ` Randy Brukardt @ 2014-03-29 9:44 ` Dmitry A. Kazakov 2014-03-31 23:55 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-29 9:44 UTC (permalink / raw) On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net... >> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote: > ... >> Real issue: Multi-methods (String vs String) and full multiple dispatch >> (String vs Character) > > That's an alternative, but the question is whether that can be implemented > with less overhead than the scheme I suggested. I believe the answer is no, > at least within generalized string packages (which hopefully will become the > norm for new string operations in Ada). If and only if the generalized packages would define operations class-wide. The idea is to rather make them primitive operations, so that a vendor (if he wanted to) could provide type-specific implementation for the cases of major interest, e.g. overriding function "&" (L, R : String) return String; instead of inheriting (covariantly) ineffective parent's function "&" (L, R : Root_String_Type) return Root_String_Type; Root_String_Type would be an equivalent of Wide_Wide_String or UTF8_String or any other full Unicode character set string. >> To reiterate the point. The implementation of strings in Ada is all OK, it >> is the interface to this implementation which sucks. > > Right, but that manifests itself in duplicated and overly restrictive > packages, which would have to be reworked in order to use a more general > interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular > have overloaded operations that would make everything ambiguous if not > eliminated.) If all string types are members of single class, then all corresponding overloaded operations are primitive operations on the class. Overloading of overridden operations in guaranteed unambiguous. That is when you build a new hierarchy of string types. Whether Unbounded_String should become a member of this new hierarchy or be replaced there with a new type is another question. Of course The former would be greatly preferable. This requires yet another feature Ada lacks - interface inheritance. Unbounded_String must drop parent's implementation/representation and inherit only the interface. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-29 9:44 ` Dmitry A. Kazakov @ 2014-03-31 23:55 ` Randy Brukardt 2014-04-01 8:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-03-31 23:55 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net... > On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net... >>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote: >> ... >>> Real issue: Multi-methods (String vs String) and full multiple dispatch >>> (String vs Character) >> >> That's an alternative, but the question is whether that can be >> implemented >> with less overhead than the scheme I suggested. I believe the answer is >> no, >> at least within generalized string packages (which hopefully will become >> the >> norm for new string operations in Ada). > > If and only if the generalized packages would define operations > class-wide. > The idea is to rather make them primitive operations, so that a vendor (if > he wanted to) could provide type-specific implementation for the cases of > major interest, e.g. > > overriding function "&" (L, R : String) return String; > > instead of inheriting (covariantly) ineffective parent's > > function "&" (L, R : Root_String_Type) return Root_String_Type; I don't understand how you are thinking the class-wide operations would work if everything isn't primitive. That's the only way for an Ada class-wide type to even be useful. So, of course each type will define useful primitive operations, and all of the root string operations will be primitive. (Indeed, the language definition already makes that so in the case of "&".) > Root_String_Type would be an equivalent of Wide_Wide_String or UTF8_String > or any other full Unicode character set string. "Root_String_Type" would be abstract, and the other types would be derived from it. New types corresponding to each interesting representation would be defined. The existing types would still exist but be obsolescent. ... >> Right, but that manifests itself in duplicated and overly restrictive >> packages, which would have to be reworked in order to use a more general >> interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular >> have overloaded operations that would make everything ambiguous if not >> eliminated.) > > If all string types are members of single class, then all corresponding > overloaded operations are primitive operations on the class. Overloading > of > overridden operations in guaranteed unambiguous. That is when you build a > new hierarchy of string types. Yes, of course, this is what I've proposing. > Whether Unbounded_String should become a member of this new hierarchy or > be > replaced there with a new type is another question. It's not a question. There's no way to do that because the operations already defined for Unbounded_String would make it ambigious if given string literals (and all Root_String_Type'Class types would have string literals). It would be completely unusable. As such, all new types is the only possibility. That's what makes this idea politically messy. > Of course The former > would be greatly preferable. This requires yet another feature Ada lacks - > interface inheritance. Unbounded_String must drop parent's > implementation/representation and inherit only the interface. That's not the problem at all. (The parent here would have no representation, so there is nothing to drop.) The problem is that Unbounded_String defines operations like function "&" (Left : Unbounded_String; Right : String) return Unbounded_String; which would be ambiguous with the normal "&" if both String and Unbounded_String had string literals (as they must for Root_String_Type to work). Indeed, that's the only reason that Ada doesn't have a way to define string literals for a private type -- we talked about it years ago but determined that it cannot be used with any of the existing string packages. As such, it would have been a weird thing to define. We can't get rid of these problematical operations -- it would be way too incompatible. So new packages is the only way to go. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-31 23:55 ` Randy Brukardt @ 2014-04-01 8:20 ` Dmitry A. Kazakov 2014-04-01 10:51 ` G.B. 2014-04-02 22:39 ` Randy Brukardt 0 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-01 8:20 UTC (permalink / raw) On Mon, 31 Mar 2014 18:55:07 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net... >> On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net... >>>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote: >>> ... >>>> Real issue: Multi-methods (String vs String) and full multiple dispatch >>>> (String vs Character) >>> >>> That's an alternative, but the question is whether that can be implemented >>> with less overhead than the scheme I suggested. I believe the answer is no, >>> at least within generalized string packages (which hopefully will become >>> the norm for new string operations in Ada). >> >> If and only if the generalized packages would define operations class-wide. >> The idea is to rather make them primitive operations, so that a vendor (if >> he wanted to) could provide type-specific implementation for the cases of >> major interest, e.g. >> >> overriding function "&" (L, R : String) return String; >> >> instead of inheriting (covariantly) ineffective parent's >> >> function "&" (L, R : Root_String_Type) return Root_String_Type; > [...] > So, of course each type will define useful primitive > operations, and all of the root string operations will be primitive. In that case there will be no overhead when an operation is overridden. > It's not a question. There's no way to do that because the operations > already defined for Unbounded_String would make it ambigious if given string > literals (and all Root_String_Type'Class types would have string literals). > It would be completely unusable. When you inherit from a type you "define" inherited operations. It is not ambiguous since operations are primitive. So long there is no overloading there will be no ambiguity. >> Of course The former >> would be greatly preferable. This requires yet another feature Ada lacks - >> interface inheritance. Unbounded_String must drop parent's >> implementation/representation and inherit only the interface. > > That's not the problem at all. (The parent here would have no > representation, so there is nothing to drop.) Unbounded_String will be derived from String, or String derived from Unbounded_String. The point is to keep it a hierarchy. And the real problem with all that is that there is more than one vector of inheritance: 1. memory management (fixed, bounded, unbounded) 2. range (character, wide_character, wide_wide_character) 3. encoding (UCS-4, UCS-2, UTF-8, ASCII) > The problem is that Unbounded_String defines operations like > > function "&" (Left : Unbounded_String; Right : String) return > Unbounded_String; > > which would be ambiguous with the normal "&" if both String and > Unbounded_String had string literals (as they must for Root_String_Type to > work). No, it is unambiguous, because provided Unbounded_String is a descendant of String (or reversely) function "&" (Left : Unbounded_String; Right : String) return Unbounded_String; is a part of the implementation of the MD operation function "&" (Left, Right : Root_String_Type) return Root_String_Type; > We can't get rid of these problematical operations -- it would be way too > incompatible. So new packages is the only way to go. You can, and everything will stay compatible if the type system is fixed first (MD, MI etc). Within present type system it is indeed unfixable and moreover, new packages will likely become as messy as the old ones. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-01 8:20 ` Dmitry A. Kazakov @ 2014-04-01 10:51 ` G.B. 2014-04-01 12:40 ` Dmitry A. Kazakov 2014-04-02 22:39 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: G.B. @ 2014-04-01 10:51 UTC (permalink / raw) On 01.04.14 10:20, Dmitry A. Kazakov wrote: > part of the implementation of the MD operation > > function "&" (Left, Right : Root_String_Type) return > Root_String_Type; How would MD work, practically, and efficiently, with numeric types? Should "+" be multiply dispatching, say? I'll assume that the compiler should then statically find the "+" determined by the type if its operands. Is this feasible? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-01 10:51 ` G.B. @ 2014-04-01 12:40 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-01 12:40 UTC (permalink / raw) On Tue, 01 Apr 2014 12:51:08 +0200, G.B. wrote: > On 01.04.14 10:20, Dmitry A. Kazakov wrote: >> part of the implementation of the MD operation >> >> function "&" (Left, Right : Root_String_Type) return >> Root_String_Type; > > How would MD work, practically, and efficiently, with numeric > types? Should "+" be multiply dispatching, say? Certainly so. > I'll assume > that the compiler should then statically find the "+" > determined by the type if its operands. Just as it already does, right now. When types are statically known, and they are not allowed not be known in present Ada, no dispatch is involved. Ergo, MD of non-tagged types has *NO* influence on any existing Ada program. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-01 8:20 ` Dmitry A. Kazakov 2014-04-01 10:51 ` G.B. @ 2014-04-02 22:39 ` Randy Brukardt 2014-04-03 2:59 ` Shark8 2014-04-05 11:10 ` Dmitry A. Kazakov 1 sibling, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-02 22:39 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net... ... >>> Of course The former >>> would be greatly preferable. This requires yet another feature Ada >>> lacks - >>> interface inheritance. Unbounded_String must drop parent's >>> implementation/representation and inherit only the interface. >> >> That's not the problem at all. (The parent here would have no >> representation, so there is nothing to drop.) > > Unbounded_String will be derived from String, or String derived from > Unbounded_String. The point is to keep it a hierarchy. Why? There is no interesting relationship between String and Unbounded_String other than the interface (which is inherited from the root type). There is no opportunity to share implementations, which is the other reason to inherit one from another. Just inheriting things because something *thinks* they should be related is silly. There is no advantage to using String'Class (if such a thing existed) rather than Root_String'Class, since all the former does is restrict what your subprogram can do; it doesn't add any capability. (In any case, in my model [which is designed for minimum change to the existing Ada language], String, Wide_String, and Wide_Wide_String stay untagged array types; they have no relationship to the hierarchy of Root_String'Class, possibly other than being defined in conversions.) > And the real problem > with all that is that there is more than one vector of inheritance: > 1. memory management (fixed, bounded, unbounded) > 2. range (character, wide_character, wide_wide_character) > 3. encoding (UCS-4, UCS-2, UTF-8, ASCII) 1 and 3 are irrelevant, because they shouldn't have any effect on the interface -- they're things that should be totally hidden outside of streaming for 3. Perhaps 2 should have some affect on the interfaces, but that's easily handled with a second level of abtsract types defining those interfaces. Besides, 1 can totally be defined after the fact with packages. That's the model that I'm suggesting. "Unbounded_String" is a container for a Root_String'Class type; it adds unbounded memory management to whatever the string type does. There is no reason that one has to do that as part of the string abstraction. >> The problem is that Unbounded_String defines operations like >> >> function "&" (Left : Unbounded_String; Right : String) return >> Unbounded_String; >> >> which would be ambiguous with the normal "&" if both String and >> Unbounded_String had string literals (as they must for Root_String_Type >> to >> work). > > No, it is unambiguous, because provided Unbounded_String is a descendant > of > String (or reversely) > > function "&" (Left : Unbounded_String; Right : String) return > Unbounded_String; > > is a part of the implementation of the MD operation > > function "&" (Left, Right : Root_String_Type) return > Root_String_Type; That doesn't help at all. We still don't know which body to execute when a string literal is used, because it matches all string types. You would have to qualify all string literals in an MD world, and that's something programmers would never tolerate. >> We can't get rid of these problematical operations -- it would be way too >> incompatible. So new packages is the only way to go. > > You can, and everything will stay compatible if the type system is fixed > first (MD, MI etc). Within present type system it is indeed unfixable and > moreover, new packages will likely become as messy as the old ones. As I said before, I am skeptical that an MD system (even ignoring MI) could be implemented efficiently enough to be used in critical operations like strings. As soon as you go to MD, the linear tag model has to ba abandoned, and some sort of search mechanism used for finding bodies to dispatch to. (Why? Consider "&". There are three types involved, at least 15 variations of those types [encoding * range; many more if one thinks storage has to be involved], giving 15**3 possibilities just for that operation alone. It's obviously impractical to store that as a flat data structure, especially as most slots will be empty.) The flat tag dispatching model involves a single index into a tag data structure, almost always using a compile-time known offset [only univerally shared generics have to do something at runtime, and even that's simple]. That adds the cost of just a handful instructions and one or two extra memory reads [one to get the tag address, one to get the body address] for a dispatching call. That's almost never going to be significant, as it is dwarfed by parameter passing and the execution of the body. OTOH, if dispatching requires looking in various lookup tables to figure out where the body address is, that overhead is substantially more expensive and at least potentially begins to be a significant part of call overhead. It's possible that there are things one could do at link-time to cut such overhead (there is for MI, for instance), but that would require an all-Ada system (which is a rarity these days). I'm skeptical, but I'm not certain so I could be convinced otherwise. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-02 22:39 ` Randy Brukardt @ 2014-04-03 2:59 ` Shark8 2014-04-05 11:10 ` Dmitry A. Kazakov 1 sibling, 0 replies; 240+ messages in thread From: Shark8 @ 2014-04-03 2:59 UTC (permalink / raw) On 02-Apr-14 15:39, Randy Brukardt wrote: > It's possible that there are things one could do at link-time to cut such > overhead (there is for MI, for instance), but that would require an all-Ada > system (which is a rarity these days). An all-Ada [build] system would, IMO, be a great thing; especially if we were to use formal methods and get the base nice and formally proven -- that /is/ the end-goal for my SQUID project: formal verification of the translator (and, to a lesser degree, tools). ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-02 22:39 ` Randy Brukardt 2014-04-03 2:59 ` Shark8 @ 2014-04-05 11:10 ` Dmitry A. Kazakov 2014-04-08 1:15 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-05 11:10 UTC (permalink / raw) On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net... > ... >>>> Of course The former >>>> would be greatly preferable. This requires yet another feature Ada >>>> lacks - >>>> interface inheritance. Unbounded_String must drop parent's >>>> implementation/representation and inherit only the interface. >>> >>> That's not the problem at all. (The parent here would have no >>> representation, so there is nothing to drop.) >> >> Unbounded_String will be derived from String, or String derived from >> Unbounded_String. The point is to keep it a hierarchy. > > Why? There is no interesting relationship between String and > Unbounded_String other than the interface (which is inherited from the root > type). The relationship is that you can mix Unbounded_String and String in operations like "&". > There is no opportunity to share implementations, which is the other > reason to inherit one from another. Most of implementations of String can be shared by Unbounded_String. This is what people do manually all the time converting Unbounded_String to String and back. > Just inheriting things because something *thinks* they should be related is > silly. There is no advantage to using String'Class (if such a thing existed) > rather than Root_String'Class, since all the former does is restrict what > your subprogram can do; it doesn't add any capability. You have just said that constrained types are useless. What is the advantage of using String (1..80). It does not add any capability... >> And the real problem >> with all that is that there is more than one vector of inheritance: >> 1. memory management (fixed, bounded, unbounded) >> 2. range (character, wide_character, wide_wide_character) >> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII) > > 1 and 3 are irrelevant, because they shouldn't have any effect on the > interface -- they're things that should be totally hidden outside of > streaming for 3. Perhaps 2 should have some affect on the interfaces, but > that's easily handled with a second level of abtsract types defining those > interfaces. Presently 1-3 are exposed, and I don't understand how you are you going to hide them: type A (Length : Positive) is record X : String (1..Length); end record; type B is record X : Unbounded_String; end record; Looks a quite visible difference to me. > Besides, 1 can totally be defined after the fact with packages. That's the > model that I'm suggesting. This is equivalent to deriving from fixed string, which is the common denominator. > "Unbounded_String" is a container for a > Root_String'Class type; it adds unbounded memory management to whatever the > string type does. There is no reason that one has to do that as part of the > string abstraction. But then you necessarily loose all operations String cannot have, e.g. Append, Replace, etc. The idea is of course that Unbounded_String, Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface. >>> The problem is that Unbounded_String defines operations like >>> >>> function "&" (Left : Unbounded_String; Right : String) return >>> Unbounded_String; >>> >>> which would be ambiguous with the normal "&" if both String and >>> Unbounded_String had string literals (as they must for Root_String_Type >>> to >>> work). >> >> No, it is unambiguous, because provided Unbounded_String is a descendant >> of String (or reversely) >> >> function "&" (Left : Unbounded_String; Right : String) return >> Unbounded_String; >> >> is a part of the implementation of the MD operation >> >> function "&" (Left, Right : Root_String_Type) return >> Root_String_Type; > > That doesn't help at all. We still don't know which body to execute when a > string literal is used, because it matches all string types. You are mixing different issues. As I said, there is no ambiguity in "&". Literals is a completely different case. They are ambiguous already. > You would have > to qualify all string literals in an MD world, and that's something > programmers would never tolerate. Ambiguity of literals can be resolved using preference rules like ones invented for Universal_Integer. We could introduce Universal_String etc. Another method could be making Latin-1 literals contravariant String, i.e. package Dont_Make_Me_Primitive is function "A" return String; function "AB" return String; function "ABC" return String; ... end Dont_Make_Me_Primitive; not inherited by Unbounded_String, Wide_String etc. That will introduce desired preference. And, yes, you will be able to assign "ABC" to Unbounded_String because ":=" is a MD operation with one body dealing with that: procedure ":=" (Left : in out Unbounded_String; Right : String); Otherwise, yes, preference rules are necessary to resolve A & B & C Between String'(A & B) & C and Unbounded_String'(A & B) & C >>> We can't get rid of these problematical operations -- it would be way too >>> incompatible. So new packages is the only way to go. >> >> You can, and everything will stay compatible if the type system is fixed >> first (MD, MI etc). Within present type system it is indeed unfixable and >> moreover, new packages will likely become as messy as the old ones. > > As I said before, I am skeptical that an MD system (even ignoring MI) could > be implemented efficiently enough to be used in critical operations like > strings. As soon as you go to MD, the linear tag model has to ba abandoned, > and some sort of search mechanism used for finding bodies to dispatch to. An MD operation needs an N-D array indexed by tags of controlling arguments. Dispatching is indexing the array. (However there are serious problems with implementation of MD which I have no idea how to resolve. MI is much simpler) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-05 11:10 ` Dmitry A. Kazakov @ 2014-04-08 1:15 ` Randy Brukardt 2014-04-08 9:15 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-08 1:15 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net... > On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net... >> ... >>>>> Of course The former >>>>> would be greatly preferable. This requires yet another feature Ada >>>>> lacks - >>>>> interface inheritance. Unbounded_String must drop parent's >>>>> implementation/representation and inherit only the interface. >>>> >>>> That's not the problem at all. (The parent here would have no >>>> representation, so there is nothing to drop.) >>> >>> Unbounded_String will be derived from String, or String derived from >>> Unbounded_String. The point is to keep it a hierarchy. >> >> Why? There is no interesting relationship between String and >> Unbounded_String other than the interface (which is inherited from the >> root >> type). > > The relationship is that you can mix Unbounded_String and String in > operations like "&". Yeah, just like mixing apples and oranges. Mixed operations are not the Ada way of typing. >> There is no opportunity to share implementations, which is the other >> reason to inherit one from another. > > Most of implementations of String can be shared by Unbounded_String. This > is what people do manually all the time converting Unbounded_String to > String and back. No, not really. Most implementations of Root_String'Class could be shared amongst string types. But specific implementations are tied to particular representations; that's exactly what we want to get rid off. Moreover, there cannot be automatic sharing of operations; that weakens the type system. One only wants to share operations that are explicitly intended to be shared; that's the point of declaring packages operating on Root_String'Class rather than some specific type. >> Just inheriting things because something *thinks* they should be related >> is >> silly. There is no advantage to using String'Class (if such a thing >> existed) >> rather than Root_String'Class, since all the former does is restrict what >> your subprogram can do; it doesn't add any capability. > > You have just said that constrained types are useless. What is the > advantage of using String (1..80). It does not add any capability... Constrained types *are* useless -- Ada has no such thing. It only has unconstrained types (remember that names only apply to subtypes). And in particular, a constrained class-wide type is an evil thing, because it's mixing things that should not be mixed: relaxing and tightening constraints at the same time. >>> And the real problem >>> with all that is that there is more than one vector of inheritance: >>> 1. memory management (fixed, bounded, unbounded) >>> 2. range (character, wide_character, wide_wide_character) >>> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII) >> >> 1 and 3 are irrelevant, because they shouldn't have any effect on the >> interface -- they're things that should be totally hidden outside of >> streaming for 3. Perhaps 2 should have some affect on the interfaces, but >> that's easily handled with a second level of abtsract types defining >> those >> interfaces. > > Presently 1-3 are exposed, and I don't understand how you are you going to > hide them: > > type A (Length : Positive) is record > X : String (1..Length); > end record; > > type B is record > X : Unbounded_String; > end record; > > Looks a quite visible difference to me. Object declarations of course use concrete, specific types. So what's your point? The majority of operations would take Root_String'Class and thus work on any object. Ones that don't would have been restricted for some good reason, and would work as now. What's so hard about that? >> Besides, 1 can totally be defined after the fact with packages. That's >> the >> model that I'm suggesting. > > This is equivalent to deriving from fixed string, which is the common > denominator. No, I'm deriving from an abstract type with no representation. There's a huge difference. >> "Unbounded_String" is a container for a >> Root_String'Class type; it adds unbounded memory management to whatever >> the >> string type does. There is no reason that one has to do that as part of >> the >> string abstraction. > > But then you necessarily loose all operations String cannot have, e.g. > Append, Replace, etc. The idea is of course that Unbounded_String, > Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface. Ada.Strings.Fixed has all of those operations. Why would we lose them? The problem with Ada.Strings as it is is that the operations are subtly different; there's no good reason for that. ... >> You would have >> to qualify all string literals in an MD world, and that's something >> programmers would never tolerate. > > Ambiguity of literals can be resolved using preference rules like ones > invented for Universal_Integer. We could introduce Universal_String etc. That doesn't work at all; universal integer only has a preference against itself. All other types are equal. So you still have problem of being unable to tell between String and Unbounded_String. And preference rules for user-defined types cause all kinds of visibility and maintenance headaches. > Another method could be making Latin-1 literals contravariant String, i.e. > > package Dont_Make_Me_Primitive is > function "A" return String; > function "AB" return String; > function "ABC" return String; > ... > end Dont_Make_Me_Primitive; > > not inherited by Unbounded_String, Wide_String etc. That will introduce > desired preference. Then Unbounded_String will not have any literals, and you'd still have problems with Wide_Wide_String vs. String. > And, yes, you will be able to assign "ABC" to Unbounded_String because > ":=" > is a MD operation with one body dealing with that: > > procedure ":=" (Left : in out Unbounded_String; Right : String); But that's unimplementable. > Otherwise, yes, preference rules are necessary to resolve > > A & B & C > > Between > > String'(A & B) & C > > and > > Unbounded_String'(A & B) & C Right, and such preferences are always trouble in a programming language. They are a prime source of beaujolais effects, which Ada considers completely unacceptable. (Adding or removing a declaration should never change a legal program into a different legal program with a different meaning.) >>>> We can't get rid of these problematical operations -- it would be way >>>> too >>>> incompatible. So new packages is the only way to go. >>> >>> You can, and everything will stay compatible if the type system is fixed >>> first (MD, MI etc). Within present type system it is indeed unfixable >>> and >>> moreover, new packages will likely become as messy as the old ones. >> >> As I said before, I am skeptical that an MD system (even ignoring MI) >> could >> be implemented efficiently enough to be used in critical operations like >> strings. As soon as you go to MD, the linear tag model has to ba >> abandoned, >> and some sort of search mechanism used for finding bodies to dispatch to. > > An MD operation needs an N-D array indexed by tags of controlling > arguments. Dispatching is indexing the array. Sure, but you can't represent the array that way, because you don't know N at compile-time (someone can define new types and link them in after the fact). And even if you did, it would be an impracticaly large a data structure in most cases. (Consider that there are something like 20 string types in a Root_String'Class model, or that there are around 100 window types in Claw.) That being the case, you have to use some sort of lookup scheme, and whether that can be efficient enough is a question. > (However there are serious problems with implementation of MD which I have > no idea how to resolve. MI is much simpler) I suppose MI is simpler, but it has a similar problem with tag construction. (At least there is only one dimension for interfaces; full MI would turn things into a much worse situation, as hidden types would have to be allowed - and then its possible for a type to have multiple copies of the same interface.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 1:15 ` Randy Brukardt @ 2014-04-08 9:15 ` Dmitry A. Kazakov 2014-04-08 10:15 ` G.B. 2014-04-08 23:37 ` Randy Brukardt 0 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-08 9:15 UTC (permalink / raw) On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net... >> On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net... >>> ... >>>>>> Of course The former >>>>>> would be greatly preferable. This requires yet another feature Ada >>>>>> lacks - >>>>>> interface inheritance. Unbounded_String must drop parent's >>>>>> implementation/representation and inherit only the interface. >>>>> >>>>> That's not the problem at all. (The parent here would have no >>>>> representation, so there is nothing to drop.) >>>> >>>> Unbounded_String will be derived from String, or String derived from >>>> Unbounded_String. The point is to keep it a hierarchy. >>> >>> Why? There is no interesting relationship between String and >>> Unbounded_String other than the interface (which is inherited from the >>> root >>> type). >> >> The relationship is that you can mix Unbounded_String and String in >> operations like "&". > > Yeah, just like mixing apples and oranges. Like mixing McIntosh and Jonathan apples. > Mixed operations are not the Ada way of typing. It is Ada's way of SUBtyping. Obviously Unbounded_String and String are related subtypes, promoted to types due to implementation reasons only. >>> There is no opportunity to share implementations, which is the other >>> reason to inherit one from another. >> >> Most of implementations of String can be shared by Unbounded_String. This >> is what people do manually all the time converting Unbounded_String to >> String and back. > > No, not really. Most implementations of Root_String'Class could be shared > amongst string types. That would be very inconvenient. Certainly, less class-wide operations are provided better is the design. > But specific implementations are tied to particular > representations; that's exactly what we want to get rid off. How a specific implementation could be tied to a class-wide type? That does not make sense. The model where operations are primitive has the decisive advantage that the operation can be inherited or overridden in order to provide a more efficient version. > Moreover, there cannot be automatic sharing of operations; that weakens the > type system. One only wants to share operations that are explicitly intended > to be shared; that's the point of declaring packages operating on > Root_String'Class rather than some specific type. I don't understand the term "shared operation." If you don't want to provide an implementation you declare the operation abstract. If you don't want an operation in the class, you move it into the body. Where is a problem? >>> Just inheriting things because something *thinks* they should be related >>> is silly. There is no advantage to using String'Class (if such a thing existed) >>> rather than Root_String'Class, since all the former does is restrict what >>> your subprogram can do; it doesn't add any capability. >> >> You have just said that constrained types are useless. What is the >> advantage of using String (1..80). It does not add any capability... > > Constrained types *are* useless -- Ada has no such thing. It only has > unconstrained types (remember that names only apply to subtypes). And in > particular, a constrained class-wide type is an evil thing, because it's > mixing things that should not be mixed: relaxing and tightening constraints > at the same time. OK, constraining is useless, discriminants are evil, specific instances of classes are wrong. We have to agree to disagree. >>>> And the real problem >>>> with all that is that there is more than one vector of inheritance: >>>> 1. memory management (fixed, bounded, unbounded) >>>> 2. range (character, wide_character, wide_wide_character) >>>> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII) >>> >>> 1 and 3 are irrelevant, because they shouldn't have any effect on the >>> interface -- they're things that should be totally hidden outside of >>> streaming for 3. Perhaps 2 should have some affect on the interfaces, but >>> that's easily handled with a second level of abtsract types defining >>> those >>> interfaces. >> >> Presently 1-3 are exposed, and I don't understand how you are you going to >> hide them: >> >> type A (Length : Positive) is record >> X : String (1..Length); >> end record; >> >> type B is record >> X : Unbounded_String; >> end record; >> >> Looks a quite visible difference to me. > > Object declarations of course use concrete, specific types. So what's your > point? The point is that all aspects I mentioned cannot be hidden = have crucial effect on the interface and is in part the interface. > The majority of operations would take Root_String'Class and thus work > on any object. Ones that don't would have been restricted for some good > reason, and would work as now. What's so hard about that? It does not make any sense to me. Consider the operation Append. Which class does it belong to? Does it act on String? Is the argument UCS-2? >>> Besides, 1 can totally be defined after the fact with packages. That's >>> the model that I'm suggesting. >> >> This is equivalent to deriving from fixed string, which is the common >> denominator. > > No, I'm deriving from an abstract type with no representation. There's a > huge difference. No difference whatsoever. We are talking about interfaces. The interface of Unbounded_String is not the interface of String. When you force a set of types to one class you must drop parts of the interfaces uncommon to all members. This is why single parent will never work for any more or less non-trivial set of types. String types and numeric types are such sets. It is not even worth trying. The result is doomed. >>> "Unbounded_String" is a container for a >>> Root_String'Class type; it adds unbounded memory management to whatever >>> the string type does. There is no reason that one has to do that as part of >>> the string abstraction. >> >> But then you necessarily loose all operations String cannot have, e.g. >> Append, Replace, etc. The idea is of course that Unbounded_String, >> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface. > > Ada.Strings.Fixed has all of those operations. Append (S, SUNDANESE_LETTER_KHA); >>> You would have >>> to qualify all string literals in an MD world, and that's something >>> programmers would never tolerate. >> >> Ambiguity of literals can be resolved using preference rules like ones >> invented for Universal_Integer. We could introduce Universal_String etc. > > That doesn't work at all; universal integer only has a preference against > itself. All other types are equal. They will have no literals of their own, in this model. >> Another method could be making Latin-1 literals contravariant String, i.e. >> >> package Dont_Make_Me_Primitive is >> function "A" return String; >> function "AB" return String; >> function "ABC" return String; >> ... >> end Dont_Make_Me_Primitive; >> >> not inherited by Unbounded_String, Wide_String etc. That will introduce >> desired preference. > > Then Unbounded_String will not have any literals, Yes, it will inherit to String and thus be able to mix String in its operations, that will be equivalent to having literals/ > and you'd still have > problems with Wide_Wide_String vs. String. No, because wider literals will go to Wide_String and most wide literal to Wide_Wide_String. The idea is to dissect literals according to the code point planes. >> And, yes, you will be able to assign "ABC" to Unbounded_String because >> ":=" is a MD operation with one body dealing with that: >> >> procedure ":=" (Left : in out Unbounded_String; Right : String); > > But that's unimplementable. Assignment is an operation as any other. >> Otherwise, yes, preference rules are necessary to resolve >> >> A & B & C >> >> Between >> >> String'(A & B) & C >> >> and >> >> Unbounded_String'(A & B) & C > > Right, and such preferences are always trouble in a programming language. It is the nature of things. When you define an n-ary operation on a type hierarchy you have the problem. You can say that is why you don't want n-ary operation and/or type hierarchies and go straight back to FORTRAN-IV. But large scale and safe software design is unthinkable without this stuff. So either you force the programmer to do all the work manually, see string types and operations in Ada for the fruits of this approach, or else you provide a reasonable support in the language for dealing with real-world problems, making programmer's life safer and easier. > They are a prime source of beaujolais effects, which Ada considers > completely unacceptable. (Adding or removing a declaration should never > change a legal program into a different legal program with a different > meaning.) Hierarchies of types are not insulated against each other. You cannot simply add or remove declaration of an operation in the hierarchy. That will lead to changes in the dispatching tables, need to define/override something, if the operation is abstract, which is why freezing rules are here etc. It is the nature of a constraint which is far more important than any "beaujolais effects" - that no dispatch can fail at run-time. All slots of any dispatching table must be statically checked for being either properly inherited or overridden. That *necessarily* requires making something illegal which otherwise would be legal. "No-beaujolais" is a nicety for separate compilation, another is strong typing imperative. I gladly trade former for the latter if necessary. >>>>> We can't get rid of these problematical operations -- it would be way >>>>> too incompatible. So new packages is the only way to go. >>>> >>>> You can, and everything will stay compatible if the type system is fixed >>>> first (MD, MI etc). Within present type system it is indeed unfixable >>>> and moreover, new packages will likely become as messy as the old ones. >>> >>> As I said before, I am skeptical that an MD system (even ignoring MI) >>> could be implemented efficiently enough to be used in critical operations like >>> strings. As soon as you go to MD, the linear tag model has to ba abandoned, >>> and some sort of search mechanism used for finding bodies to dispatch to. >> >> An MD operation needs an N-D array indexed by tags of controlling >> arguments. Dispatching is indexing the array. > > Sure, but you can't represent the array that way, because you don't know N > at compile-time (someone can define new types and link them in after the > fact). I don't need to know it at compile time. I only need to know its subarray that includes the types visible in the context being compiled. That subarray is sufficient to get through. N must be known at bind/link-time. > And even if you did, it would be an impracticaly large a data > structure in most cases. (Consider that there are something like 20 string > types in a Root_String'Class model, N is not the total number of related types, N is the depth of the given hierarchy. You will have to map Tag to some dense index in the operation's inheritance path and then go into the array with this index. Raw tag is a poor index. >> (However there are serious problems with implementation of MD which I have >> no idea how to resolve. MI is much simpler) > > I suppose MI is simpler, but it has a similar problem with tag construction. > (At least there is only one dimension for interfaces; full MI would turn > things into a much worse situation, as hidden types would have to be > allowed - and then its possible for a type to have multiple copies of the > same interface.) That is a highly desired effect: to support additive model of inheritance. E.g. additive MI from doubly-linked list element. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 9:15 ` Dmitry A. Kazakov @ 2014-04-08 10:15 ` G.B. 2014-04-08 10:56 ` Dmitry A. Kazakov 2014-04-08 23:37 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: G.B. @ 2014-04-08 10:15 UTC (permalink / raw) On 08.04.14 11:15, Dmitry A. Kazakov wrote: >> Constrained types*are* useless -- Ada has no such thing. It only has >> >unconstrained types (remember that names only apply to subtypes). And in >> >particular, a constrained class-wide type is an evil thing, because it's >> >mixing things that should not be mixed: relaxing and tightening constraints >> >at the same time. > OK, constraining is useless, discriminants are evil, specific instances of > classes are wrong. We have to agree to disagree. Reminder: an Ada "type", formally, is different from the "type" that Dmitry has in mind (seeing subtype constraints as establishing a "type", IIRC, which, for the most part, it isn't doing, in Ada). It might help to have a USENET specific type of link that establishes evidence of the difference in terminology. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 10:15 ` G.B. @ 2014-04-08 10:56 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-08 10:56 UTC (permalink / raw) On Tue, 08 Apr 2014 12:15:45 +0200, G.B. wrote: > On 08.04.14 11:15, Dmitry A. Kazakov wrote: >>> Constrained types*are* useless -- Ada has no such thing. It only has >>> >unconstrained types (remember that names only apply to subtypes). And in >>> >particular, a constrained class-wide type is an evil thing, because it's >>> >mixing things that should not be mixed: relaxing and tightening constraints >>> >at the same time. >> OK, constraining is useless, discriminants are evil, specific instances of >> classes are wrong. We have to agree to disagree. > > Reminder: an Ada "type", formally, is different from the "type" > that Dmitry has in mind (seeing subtype constraints as > establishing a "type", IIRC, which, for the most part, it isn't > doing, in Ada). > > It might help to have a USENET specific type of link > that establishes evidence of the difference in terminology. Can be found in any textbook: type is a set of values bound by operations defined on these values Yes, Ada's subtype is a type, no less than C++'s class is. But however you call it, Randy's point was about putting a constraint on some set of values being useless. I can guess that his position is motivated by the ideas of LSP subtyping. Surely Ada's subtyping is in contradiction with LSP-subtyping. That does not make Ada's subtyping any useless or evil. On the contrary, it rather does the LSP-subtyping. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 9:15 ` Dmitry A. Kazakov 2014-04-08 10:15 ` G.B. @ 2014-04-08 23:37 ` Randy Brukardt 2014-04-09 10:40 ` Dmitry A. Kazakov 1 sibling, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-08 23:37 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net... > On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote: ... >> Mixed operations are not the Ada way of typing. > > It is Ada's way of SUBtyping. Obviously Unbounded_String and String are > related subtypes, promoted to types due to implementation reasons only. Obvious to you only. Any single program/subsystem should stick to a single string type. The fact that you can't do that in Ada (unless that type is String) is the bug that needs to be fixed. >>>> There is no opportunity to share implementations, which is the other >>>> reason to inherit one from another. >>> >>> Most of implementations of String can be shared by Unbounded_String. >>> This >>> is what people do manually all the time converting Unbounded_String to >>> String and back. >> >> No, not really. Most implementations of Root_String'Class could be shared >> amongst string types. > > That would be very inconvenient. Certainly, less class-wide operations are > provided better is the design. "In"convinient? Why? Use all and prefix notation lets one use class-wide operations in many circumstances. And in any case, the whole point is to eliminate the requirement to use a single, specific string type for operations that should be generic (generic in the English, not Ada, sense). >> But specific implementations are tied to particular >> representations; that's exactly what we want to get rid off. > > How a specific implementation could be tied to a class-wide type? That > does > not make sense. Very, very little of string operations should be tied at all to any particular implementation. In particular, nothing in Ada.Strings.* is primitive to string types per-se; they're all higher level operations created out of lower-level primitives. They should therefore be class-wide so there only needs to be one implementation. > The model where operations are primitive has the decisive advantage that > the operation can be inherited or overridden in order to provide a more > efficient version. That wouldn't improve the performance enough to matter. If there is a problem with this scheme, it's that it could be very inefficient. But that's mostly because of the use of dispatching, and that's required for the goal to be reached (for most of the existing predefined operations to have versions that take/return Root_String'Class rather than String). If we can't reach that goal, there is no point to doing this at all. My experience is that tagged types with lots of primitives are virtually un-extendable -- it just takes too much work to create an extension. The vast majority of those primitives have to be overridden (unless you are using redispatching, which I agree is a bad idea in general), and it just slows the process down to the point where nothing gets accomplished. (I essentially abandoned work on the Claw Builder for this reason.) >> Moreover, there cannot be automatic sharing of operations; that weakens >> the >> type system. One only wants to share operations that are explicitly >> intended >> to be shared; that's the point of declaring packages operating on >> Root_String'Class rather than some specific type. > > I don't understand the term "shared operation." > > If you don't want to provide an implementation you declare the operation > abstract. If you don't want an operation in the class, you move it into > the > body. Where is a problem? As above, it's too much work to extend a type that requires overridding more than a handful of primitives. It takes 3 days of work to get a compilable, testable extension of the window type in the Claw Builder -- anything over 4 hours or so is unacceptable. ... >> Object declarations of course use concrete, specific types. So what's >> your >> point? > > The point is that all aspects I mentioned cannot be hidden = have crucial > effect on the interface and is in part the interface. Umm, no, the "interface" doesn't have anything to do with concrete implementations. And since you didn't mention any aspects at all, I'm even sure what you're talking about. All you did is declare some components of specific types. Maybe you're talking about the constraints, but we already agreed to disagree on that. I don't think they have anything whatsoever to do with the interface, and in fact explicitly should *not* be part of the interface. >> The majority of operations would take Root_String'Class and thus work >> on any object. Ones that don't would have been restricted for some good >> reason, and would work as now. What's so hard about that? > > It does not make any sense to me. Consider the operation Append. Which > class does it belong to? Does it act on String? Is the argument UCS-2? Append takes two operands of Root_String'Class, and returns an Root_String'Class with the type of its first argument. What's the problem? ... >> No, I'm deriving from an abstract type with no representation. There's a >> huge difference. > > No difference whatsoever. We are talking about interfaces. The interface > of > Unbounded_String is not the interface of String. That's true, but that's a bug. They *should* be the same; only the runtime behavior should differ (when exceptions are raised and the like). > When you force a set of > types to one class you must drop parts of the interfaces uncommon to all > members. This is why single parent will never work for any more or less > non-trivial set of types. String types and numeric types are such sets. It > is not even worth trying. The result is doomed. Possibly, but then programming language design in general is doomed. The only solutions that would work are crazily inefficient. But the real truth is that you're confusing the totality of the operations of a type with the small targeted part of those operations that form a valuable abstraction. Interfaces that are useful are small and targeted. The main advantage of Ada's interface types is to mix and match those small interfaces on a variety of types. But we don't need to do that here. The only interface that matters is the one that allows useful operations to be constructed on Root_String'Class. Other interfaces are irrelevant, because there is nothing that we might want to do with them. (And of course, if you want to define other interfaces, go ahead - that's the purpose of MI.) >>>> "Unbounded_String" is a container for a >>>> Root_String'Class type; it adds unbounded memory management to whatever >>>> the string type does. There is no reason that one has to do that as >>>> part of >>>> the string abstraction. >>> >>> But then you necessarily loose all operations String cannot have, e.g. >>> Append, Replace, etc. The idea is of course that Unbounded_String, >>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface. >> >> Ada.Strings.Fixed has all of those operations. > > Append (S, SUNDANESE_LETTER_KHA); Yes, that's good. If the underlying type cannot store the letter, Constraint_Error is raised. As with all tagged types, you trade-off compile-time checking for generality. You can't have both (I know people try, but they are mad - they'll have just as much luck creating a perpetual motion machine). >>>> You would have >>>> to qualify all string literals in an MD world, and that's something >>>> programmers would never tolerate. >>> >>> Ambiguity of literals can be resolved using preference rules like ones >>> invented for Universal_Integer. We could introduce Universal_String etc. >> >> That doesn't work at all; universal integer only has a preference against >> itself. All other types are equal. > > They will have no literals of their own, in this model. They have no literals now, in this model. You're just describing the way things are, and then expect it to work differently. ... >> and you'd still have >> problems with Wide_Wide_String vs. String. > > No, because wider literals will go to Wide_String and most wide literal to > Wide_Wide_String. The idea is to dissect literals according to the code > point planes. So the behavior of the program changes when the contents of a string literal changes? No thanks. ... >> They are a prime source of beaujolais effects, which Ada considers >> completely unacceptable. (Adding or removing a declaration should never >> change a legal program into a different legal program with a different >> meaning.) > > Hierarchies of types are not insulated against each other. You cannot > simply add or remove declaration of an operation in the hierarchy. That > will lead to changes in the dispatching tables, need to define/override > something, if the operation is abstract, which is why freezing rules are > here etc. > > It is the nature of a constraint which is far more important than any > "beaujolais effects" - that no dispatch can fail at run-time. > > All slots of any dispatching table must be statically checked for being > either properly inherited or overridden. That *necessarily* requires > making > something illegal which otherwise would be legal. "No-beaujolais" is a > nicety for separate compilation, another is strong typing imperative. I > gladly trade former for the latter if necessary. In other words, you are willing to weaken Ada's contracts in order to get your supposed "strong typing imperative". Essentially, in your world, you cannot change a package specification because you cannot know what effect such changes have on clients (clients that you don't know much about). That means that there is no hope for reusable software - the originator of the software has to be able to modify it in order to improve or correct it. If that breaks all clients, then either one can do nothing at all, or people just have to stick to their existing (buggy) versions. Neither is acceptable. >>>>>> We can't get rid of these problematical operations -- it would be way >>>>>> too incompatible. So new packages is the only way to go. >>>>> >>>>> You can, and everything will stay compatible if the type system is >>>>> fixed >>>>> first (MD, MI etc). Within present type system it is indeed unfixable >>>>> and moreover, new packages will likely become as messy as the old >>>>> ones. >>>> >>>> As I said before, I am skeptical that an MD system (even ignoring MI) >>>> could be implemented efficiently enough to be used in critical >>>> operations like >>>> strings. As soon as you go to MD, the linear tag model has to ba >>>> abandoned, >>>> and some sort of search mechanism used for finding bodies to dispatch >>>> to. >>> >>> An MD operation needs an N-D array indexed by tags of controlling >>> arguments. Dispatching is indexing the array. >> >> Sure, but you can't represent the array that way, because you don't know >> N >> at compile-time (someone can define new types and link them in after the >> fact). > > I don't need to know it at compile time. I only need to know its subarray > that includes the types visible in the context being compiled. That > subarray is sufficient to get through. N must be known at bind/link-time. > >> And even if you did, it would be an impracticaly large a data >> structure in most cases. (Consider that there are something like 20 >> string >> types in a Root_String'Class model, > > N is not the total number of related types, N is the depth of the given > hierarchy. You will have to map Tag to some dense index in the operation's > inheritance path and then go into the array with this index. Raw tag is a > poor index. But it's all we have. Sure, you can map a tag (this requires a loop, either a brute force lookup or some fancier but much more code-intensive version), but that's going to make dispatching far more expensive. You can't do this mapping at compile-time because what mapping you need depends on the interfaces in use. >>> (However there are serious problems with implementation of MD which I >>> have >>> no idea how to resolve. MI is much simpler) >> >> I suppose MI is simpler, but it has a similar problem with tag >> construction. >> (At least there is only one dimension for interfaces; full MI would turn >> things into a much worse situation, as hidden types would have to be >> allowed - and then its possible for a type to have multiple copies of the >> same interface.) > > That is a highly desired effect: to support additive model of inheritance. > E.g. additive MI from doubly-linked list element. It doesn't work, though, because you have to know *which* copy of the interface you are dispatching through. The operations can be different for each such interface (if they can't, you've completely given up on privacy). You could of course just abandon privacy and maintainability for your type-system, but the result would bear no resemblance to Ada. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 23:37 ` Randy Brukardt @ 2014-04-09 10:40 ` Dmitry A. Kazakov 2014-04-10 3:28 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-09 10:40 UTC (permalink / raw) On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net... >> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote: > ... >>> Mixed operations are not the Ada way of typing. >> >> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are >> related subtypes, promoted to types due to implementation reasons only. > > Obvious to you only. Any single program/subsystem should stick to a single > string type. The fact that you can't do that in Ada (unless that type is > String) is the bug that needs to be fixed. I don't understand what you are trying to say. Is it that no program shall use both Unbounded_String and String or that there must be no String (Unbounded_String) at all? >>>>> There is no opportunity to share implementations, which is the other >>>>> reason to inherit one from another. >>>> >>>> Most of implementations of String can be shared by Unbounded_String. This >>>> is what people do manually all the time converting Unbounded_String to >>>> String and back. >>> >>> No, not really. Most implementations of Root_String'Class could be shared >>> amongst string types. >> >> That would be very inconvenient. Certainly, less class-wide operations are >> provided better is the design. > > "In"convinient? Why? Class-wide operations are inefficient, ambiguous, require type casts (and thus unsafe). > And in any case, the whole point is to > eliminate the requirement to use a single, specific string type for > operations that should be generic (generic in the English, not Ada, sense). And the whole point of keeping operation primitive is to have its interface generic and the implementation type-specific. >> The model where operations are primitive has the decisive advantage that >> the operation can be inherited or overridden in order to provide a more >> efficient version. > > That wouldn't improve the performance enough to matter. If there is a > problem with this scheme, it's that it could be very inefficient. But that's > mostly because of the use of dispatching, and that's required for the goal > to be reached (for most of the existing predefined operations to have > versions that take/return Root_String'Class rather than String). If we can't > reach that goal, there is no point to doing this at all. There will be no dispatching because types are known statically for most applications. Secondly, even if dispatching is present it is manyfold more efficient that dispatching within the class-wide bodies per character basis, which where your proposal leads. >>> Moreover, there cannot be automatic sharing of operations; that weakens >>> the type system. One only wants to share operations that are explicitly >>> intended to be shared; that's the point of declaring packages operating on >>> Root_String'Class rather than some specific type. >> >> I don't understand the term "shared operation." >> >> If you don't want to provide an implementation you declare the operation >> abstract. If you don't want an operation in the class, you move it into >> the body. Where is a problem? > > As above, it's too much work to extend a type that requires overridding more > than a handful of primitives. String types are library types. You cannot extend String now, so the use case you are talking about does not exist. >>> The majority of operations would take Root_String'Class and thus work >>> on any object. Ones that don't would have been restricted for some good >>> reason, and would work as now. What's so hard about that? >> >> It does not make any sense to me. Consider the operation Append. Which >> class does it belong to? Does it act on String? Is the argument UCS-2? > > Append takes two operands of Root_String'Class, and returns an > Root_String'Class with the type of its first argument. What's the problem? Append is a procedure. Modifiers of Unbounded_String are in-place operations, that is the major use case for having Unbounded_String at all. >>> No, I'm deriving from an abstract type with no representation. There's a >>> huge difference. >> >> No difference whatsoever. We are talking about interfaces. The interface >> of Unbounded_String is not the interface of String. > > That's true, but that's a bug. They *should* be the same; only the runtime > behavior should differ (when exceptions are raised and the like). They should not and cannot. The type String cannot have procedure Append because String size is contracted to be constant. Immutable bounds is the major use case of String. Mutable bounds is of Unbounded_String. You cannot have both "same." >> When you force a set of >> types to one class you must drop parts of the interfaces uncommon to all >> members. This is why single parent will never work for any more or less >> non-trivial set of types. String types and numeric types are such sets. It >> is not even worth trying. The result is doomed. > > Possibly, but then programming language design in general is doomed. The > only solutions that would work are crazily inefficient. Everything should work exactly so it does now, but without explicit type conversions. >>>>> "Unbounded_String" is a container for a >>>>> Root_String'Class type; it adds unbounded memory management to whatever >>>>> the string type does. There is no reason that one has to do that as >>>>> part of the string abstraction. >>>> >>>> But then you necessarily loose all operations String cannot have, e.g. >>>> Append, Replace, etc. The idea is of course that Unbounded_String, >>>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface. >>> >>> Ada.Strings.Fixed has all of those operations. >> >> Append (S, SUNDANESE_LETTER_KHA); > > Yes, that's good. If the underlying type cannot store the letter, > Constraint_Error is raised. Yes! You want weak typing all the way! In my system the above will be compile error because 1. String does not have Append; 2. String is Latin-1. > As with all tagged types, you trade-off compile-time checking for > generality. You can't have both (I know people try, but they are mad - > they'll have just as much luck creating a perpetual motion machine). I can, this what a proper types system is for. If you don't change the type system you end up with a weakly typed language, which is where Ada sails to since 2005. >>>>> You would have >>>>> to qualify all string literals in an MD world, and that's something >>>>> programmers would never tolerate. >>>> >>>> Ambiguity of literals can be resolved using preference rules like ones >>>> invented for Universal_Integer. We could introduce Universal_String etc. >>> >>> That doesn't work at all; universal integer only has a preference against >>> itself. All other types are equal. >> >> They will have no literals of their own, in this model. > > They have no literals now, in this model. You're just describing the way > things are, and then expect it to work differently. Yes, a common type hierarchy will make it working differently. >>> and you'd still have >>> problems with Wide_Wide_String vs. String. >> >> No, because wider literals will go to Wide_String and most wide literal to >> Wide_Wide_String. The idea is to dissect literals according to the code >> point planes. > > So the behavior of the program changes when the contents of a string literal > changes? Contents of a literal is the literal itself. That is the meaning of the word "literal." Yes, if you change the literal the behavior changes. Compare: I : Integer_8 := 100; vs. I : Integer_8 := 100_000; > No thanks. After you lumped everything into class-wide operations making it weakly typed? >>> They are a prime source of beaujolais effects, which Ada considers >>> completely unacceptable. (Adding or removing a declaration should never >>> change a legal program into a different legal program with a different >>> meaning.) >> >> Hierarchies of types are not insulated against each other. You cannot >> simply add or remove declaration of an operation in the hierarchy. That >> will lead to changes in the dispatching tables, need to define/override >> something, if the operation is abstract, which is why freezing rules are >> here etc. >> >> It is the nature of a constraint which is far more important than any >> "beaujolais effects" - that no dispatch can fail at run-time. >> >> All slots of any dispatching table must be statically checked for being >> either properly inherited or overridden. That *necessarily* requires making >> something illegal which otherwise would be legal. "No-beaujolais" is a >> nicety for separate compilation, another is strong typing imperative. I >> gladly trade former for the latter if necessary. > > In other words, you are willing to weaken Ada's contracts in order to get > your supposed "strong typing imperative". No, it is strengthening of the contracts. You removed beaujolais effects by weakening the contracts to the point where separately compiled units could retain their contracts independently. Strengthening may lead to loosing this property. > Essentially, in your world, you cannot change a package specification > because you cannot know what effect such changes have on clients (clients > that you don't know much about). The effect is exactly known - the clients become illegal. That is the idea of strong contracts. Instead of keeping clients legal but risking unanticipated behavioral changes, strong contracts make clients illegal when there is a possibility of changed behavior. If you can statically prove that the behavior does not change, there is no need to introduce the "effect." > That means that there is no hope for > reusable software - the originator of the software has to be able to modify > it in order to improve or correct it. If that breaks all clients, then > either one can do nothing at all, or people just have to stick to their > existing (buggy) versions. Neither is acceptable. Ada has no support for dynamic linking anyway, so it is how it is right now. Introducing MD won't make bad any worse. On the other hand, it is well known that OO interfaces are quite fragile for dynamic linking with or without MD. But this is another problem, which must be addressed first, when the type system is OK. >>> And even if you did, it would be an impracticaly large a data >>> structure in most cases. (Consider that there are something like 20 >>> string types in a Root_String'Class model, >> >> N is not the total number of related types, N is the depth of the given >> hierarchy. You will have to map Tag to some dense index in the operation's >> inheritance path and then go into the array with this index. Raw tag is a >> poor index. > > But it's all we have. Sure, you can map a tag (this requires a loop, either > a brute force lookup or some fancier but much more code-intensive version), > but that's going to make dispatching far more expensive. You can't do this > mapping at compile-time because what mapping you need depends on the > interfaces in use. I can build a perfect hash at bind/link time when all involved tags become known. >>>> (However there are serious problems with implementation of MD which I >>>> have no idea how to resolve. MI is much simpler) >>> >>> I suppose MI is simpler, but it has a similar problem with tag >>> construction. >>> (At least there is only one dimension for interfaces; full MI would turn >>> things into a much worse situation, as hidden types would have to be >>> allowed - and then its possible for a type to have multiple copies of the >>> same interface.) >> >> That is a highly desired effect: to support additive model of inheritance. >> E.g. additive MI from doubly-linked list element. > > It doesn't work, though, because you have to know *which* copy of the > interface you are dispatching through. Operations will be renamed in order to have it unambiguous. It was always my desire that Ada would require renaming in all cases when something gets hidden. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-09 10:40 ` Dmitry A. Kazakov @ 2014-04-10 3:28 ` Randy Brukardt 2014-04-10 8:42 ` Georg Bauhaus 2014-04-10 15:31 ` Dmitry A. Kazakov 0 siblings, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-10 3:28 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net... > On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net... >>> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote: >> ... >>>> Mixed operations are not the Ada way of typing. >>> >>> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are >>> related subtypes, promoted to types due to implementation reasons only. >> >> Obvious to you only. Any single program/subsystem should stick to a >> single >> string type. The fact that you can't do that in Ada (unless that type is >> String) is the bug that needs to be fixed. > > I don't understand what you are trying to say. Is it that no program shall > use both Unbounded_String and String or that there must be no String > (Unbounded_String) at all? There should be no reason for a single subsystem to use more than one string type. The fact that that is not true in Ada today is the cause of most of the problems. As a correllary, as many operations as possible should work with all possible string types (Root_String'Class in my formulation) -- most of the time when you need to use multiple string types, its because you have libraries that only work with one type (String, Unbounded_String, whatever) and you need to use some other type. So you end up converting back and forth. If most the libraries simply take Root_String'Class, that doesn't happen. ... >>> That would be very inconvenient. Certainly, less class-wide operations >>> are >>> provided better is the design. >> >> "In"convinient? Why? > > Class-wide operations are inefficient, ambiguous, require type casts (and > thus unsafe). The first I rather understand, but it's the entire point of the change (to get as many operations as possible to work with any string type). If that proves too inefficient, then there is no solution. But I do think it has to be tried in order to determine if its truly too inefficient (worrying about that is often premature optimization). [This is the reason that I don't dismiss out-of-hand your ideas on MI and MD -- because while I think they're likely to be too inefficient, I really don't know that. Of course, since I think as much as possible needs to be class-wide, dispatching performance is very important, and MD in particular would have a substantial cost there.] Ambiguous? That's the idea -- most consumers of strings don't care anything about the properties of the string, just the sequence of code points that it represents. Require type casts? No idea why you think that - that only happens in bad abstractions where you find yourself upcasting to get at components that "you know are there". Such things are just plain bad, and surely aren't going to happen here as nothing of the implementation is going to be exposed. (I.e. either use Root_String'Class, or use a specific type - and under no circumstances should you change mid-stream.) >> And in any case, the whole point is to >> eliminate the requirement to use a single, specific string type for >> operations that should be generic (generic in the English, not Ada, >> sense). > > And the whole point of keeping operation primitive is to have its > interface > generic and the implementation type-specific. We don't want "type-specific" implementations of most things -- that's just adding a maintenance headache where one isn't needed. Why would anyone want a "type-specific" implementation of file open? Or exception messages? That's precisely the cause of the problem that we currently have. ... >> That wouldn't improve the performance enough to matter. If there is a >> problem with this scheme, it's that it could be very inefficient. But >> that's >> mostly because of the use of dispatching, and that's required for the >> goal >> to be reached (for most of the existing predefined operations to have >> versions that take/return Root_String'Class rather than String). If we >> can't >> reach that goal, there is no point to doing this at all. > > There will be no dispatching because types are known statically for most > applications. Secondly, even if dispatching is present it is manyfold more > efficient that dispatching within the class-wide bodies per character > basis, which where your proposal leads. Well, my proposal supports slices as a primitive operation, so there's no reason for dispatching on single characters unless you really need to access single characters. But you're saying that we shouldn't solve the problem at all, since the entire problem is forcing the use of specific types in language-defined libraries (and similarly in user-defined libraries). By definition, most of the operations would be on class-wide types and thus dispatching. You seem so focused on virtually useless operations like Append -- they have no real value in an Ada application, as the primitives (slicing and &) do the job better anyway. One is forced to use them for unbounded string, mainly because you don't have very good access to the primitives for those types -- that's the whole idea of this change. ... >>> It does not make any sense to me. Consider the operation Append. Which >>> class does it belong to? Does it act on String? Is the argument UCS-2? >> >> Append takes two operands of Root_String'Class, and returns an >> Root_String'Class with the type of its first argument. What's the >> problem? > > Append is a procedure. Modifiers of Unbounded_String are in-place > operations, that is the major use case for having Unbounded_String at all. OK, then it takes an in out parameter of Root_String'Class, and an in parameter of Root_String'Class. What's the problem? In any case, Append is a pretty useless operation; the majority of the operations in Ada.Strings are that. It takes longer to figure out how they work and find the right one than it does to just write the silly operation explicitly. It might make sense to make the most general Index primitive (as it's pretty much the only operation that really could benefit from a custom implementation), but that's about it. It's very important that the root interface be kept as small as possible. >>>> No, I'm deriving from an abstract type with no representation. There's >>>> a >>>> huge difference. >>> >>> No difference whatsoever. We are talking about interfaces. The interface >>> of Unbounded_String is not the interface of String. >> >> That's true, but that's a bug. They *should* be the same; only the >> runtime >> behavior should differ (when exceptions are raised and the like). > > They should not and cannot. The type String cannot have procedure Append > because String size is contracted to be constant. Immutable bounds is the > major use case of String. Mutable bounds is of Unbounded_String. You > cannot > have both "same." Of course you can. Consider Bounded string, which has a bound, but it's partly mutable. Or better, consider the containers -- they have bounded and unbounded versions. Semantically, they all have bounds, it's just that the unbounded version increases the bound automatically when needed. There would be no problem having a fixed size container (other than such a thing would be redunant with the existing arrays). Append is defined in Ada.Strings.Fixed, after all, so of course it works for a fixed length string. >>> When you force a set of >>> types to one class you must drop parts of the interfaces uncommon to all >>> members. This is why single parent will never work for any more or less >>> non-trivial set of types. String types and numeric types are such sets. >>> It >>> is not even worth trying. The result is doomed. >> >> Possibly, but then programming language design in general is doomed. The >> only solutions that would work are crazily inefficient. > > Everything should work exactly so it does now, but without explicit type > conversions. Yeah, and every girl should want to go out with you, without an explicit invitation. :-) >>>>>> "Unbounded_String" is a container for a >>>>>> Root_String'Class type; it adds unbounded memory management to >>>>>> whatever >>>>>> the string type does. There is no reason that one has to do that as >>>>>> part of the string abstraction. >>>>> >>>>> But then you necessarily loose all operations String cannot have, e.g. >>>>> Append, Replace, etc. The idea is of course that Unbounded_String, >>>>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this >>>>> interface. >>>> >>>> Ada.Strings.Fixed has all of those operations. >>> >>> Append (S, SUNDANESE_LETTER_KHA); >> >> Yes, that's good. If the underlying type cannot store the letter, >> Constraint_Error is raised. > > Yes! You want weak typing all the way! Yes, that's exactly the idea of class-wide operations -- one weakens the typing (by allowing classes of operations) in order to get more generality. There is always a trade-off between generality and the strength of typing -- and I surely agree with you that generics don't help in any significant way with that. > In my system the above will be compile error because > > 1. String does not have Append; String *does* have Append (in Ada.Strings.Fixed). Why do you think those operations are part of Unbounded_String but not part of String simply because someone stuck the latter ones in a library? ... >> As with all tagged types, you trade-off compile-time checking for >> generality. You can't have both (I know people try, but they are mad - >> they'll have just as much luck creating a perpetual motion machine). > > I can, this what a proper types system is for. If you don't change the > type > system you end up with a weakly typed language, which is where Ada sails > to > since 2005. You're delusional on this point. Indeed, you refuse to pay any attention when I point out why your system won't work. You just keep relying on some sort of magic to make it work - and then go on to laughably claim that it would be compatible without a shred of evidence that that could possibly be so. I should know better than to engage with you on anything that involves your crazy type system, because the useful ideas that I hope to find out are completely lost in this impractical, magic reimagining of the type system. I'm hoping to come up with a solutions within the existing type system, because there is absolutely no evidence that there is a problem it. Indeed, the fact that I can come up with a viable all-Ada 2012 solution to the string problem shows that. I really don't care whether or not some other type system that's never going to happen would work differently. And that's the last word on that subject. ... >>>> They are a prime source of beaujolais effects, which Ada considers >>>> completely unacceptable. (Adding or removing a declaration should never >>>> change a legal program into a different legal program with a different >>>> meaning.) >>> >>> Hierarchies of types are not insulated against each other. You cannot >>> simply add or remove declaration of an operation in the hierarchy. That >>> will lead to changes in the dispatching tables, need to define/override >>> something, if the operation is abstract, which is why freezing rules are >>> here etc. >>> >>> It is the nature of a constraint which is far more important than any >>> "beaujolais effects" - that no dispatch can fail at run-time. >>> >>> All slots of any dispatching table must be statically checked for being >>> either properly inherited or overridden. That *necessarily* requires >>> making >>> something illegal which otherwise would be legal. "No-beaujolais" is a >>> nicety for separate compilation, another is strong typing imperative. I >>> gladly trade former for the latter if necessary. >> >> In other words, you are willing to weaken Ada's contracts in order to get >> your supposed "strong typing imperative". > > No, it is strengthening of the contracts. You removed beaujolais effects > by > weakening the contracts to the point where separately compiled units could > retain their contracts independently. Strengthening may lead to loosing > this property. In order to "program in the large", separate units have to be able to "retain their contracts independently". Otherwise, it's impossible for separate development teams to work on the same program -- it's those independent contracts that make it safe for one team to add new items and not have it cause the program to change behavior without warning. This is a property of Ada which every Ada programmer depends upon, but since it's not an obvious property, most people don't realize how critical it is. > Essentially, in your world, you cannot change a package specification >> because you cannot know what effect such changes have on clients (clients >> that you don't know much about). > > The effect is exactly known - the clients become illegal. That is the idea > of strong contracts. Instead of keeping clients legal but risking > unanticipated behavioral changes, strong contracts make clients illegal > when there is a possibility of changed behavior. If you can statically > prove that the behavior does not change, there is no need to introduce the > "effect." If the clients become illegal, then you don't have Beaujolias, and all is well. But that's not the system you described. You descibed one with preference rules, and when those exist, an addition or deletion potentially causes one legal program to become a different legal program - because the preference rule causes a different routine to be called rather than making the call illegal. That's not acceptable for Ada (and it shouldn't be acceptable for any programming language). >> That means that there is no hope for >> reusable software - the originator of the software has to be able to >> modify >> it in order to improve or correct it. If that breaks all clients, then >> either one can do nothing at all, or people just have to stick to their >> existing (buggy) versions. Neither is acceptable. > > Ada has no support for dynamic linking anyway, so it is how it is right > now. Introducing MD won't make bad any worse. MD isn't the problem; preference rules are the problem. And what does dynamic linking have to do with anything? You should be able to get the new version of GTK or Claw and recompile -- if legal, the program should work the same way. Period. That's not the case in a system with preference rules for user-defined operations. ... >> But it's all we have. Sure, you can map a tag (this requires a loop, >> either >> a brute force lookup or some fancier but much more code-intensive >> version), >> but that's going to make dispatching far more expensive. You can't do >> this >> mapping at compile-time because what mapping you need depends on the >> interfaces in use. > > I can build a perfect hash at bind/link time when all involved tags become > known. "can" means "possible", not "practical". That might be possible if the number of tags is small, but that's not the case in a lot of OO systems. (A Claw program starts with somewhere around 80.) Finding a perfect hash gets very time consuming if the number of items is large - I don't think people will be very happy with binding that takes 12 hours. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 3:28 ` Randy Brukardt @ 2014-04-10 8:42 ` Georg Bauhaus 2014-04-10 21:52 ` Randy Brukardt 2014-04-10 15:31 ` Dmitry A. Kazakov 1 sibling, 1 reply; 240+ messages in thread From: Georg Bauhaus @ 2014-04-10 8:42 UTC (permalink / raw) On 10/04/14 05:28, Randy Brukardt wrote: >>> But it's all we have. Sure, you can map a tag (this requires a loop, >>> >>either >>> >>a brute force lookup or some fancier but much more code-intensive >>> >>version), >>> >>but that's going to make dispatching far more expensive. You can't do >>> >>this >>> >>mapping at compile-time because what mapping you need depends on the >>> >>interfaces in use. >> > >> >I can build a perfect hash at bind/link time when all involved tags become >> >known. > "can" means "possible", not "practical". That might be possible if the > number of tags is small, but that's not the case in a lot of OO systems. (A > Claw program starts with somewhere around 80.) Finding a perfect hash gets > very time consuming if the number of items is large - I don't think people > will be very happy with binding that takes 12 hours. Are you certain about the cost of computing perfect hashes? I tried gperf(1) on a hundred words and ran it a thousand times in a loop. The loop has taken just a few seconds: a=1000 while test $a -gt 0 do head -100 /usr/share/dict/words |gperf > /dev/null a=$(($a - 1)) done ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 8:42 ` Georg Bauhaus @ 2014-04-10 21:52 ` Randy Brukardt 0 siblings, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-10 21:52 UTC (permalink / raw) "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message news:53465969$0$6708$9b4e6d93@newsspool3.arcor-online.net... > On 10/04/14 05:28, Randy Brukardt wrote: ... >>> >I can build a perfect hash at bind/link time when all involved tags >>> >become >>> >known. >> "can" means "possible", not "practical". That might be possible if the >> number of tags is small, but that's not the case in a lot of OO systems. >> (A >> Claw program starts with somewhere around 80.) Finding a perfect hash >> gets >> very time consuming if the number of items is large - I don't think >> people >> will be very happy with binding that takes 12 hours. > > Are you certain about the cost of computing perfect hashes? Certain? Only an idiot is certain about anything. But my understanding is that calculating perfect hashes is an NP-complete problem. It's possible to speed up the algorithm (maybe), but it always is going to be quadratic in the size of the items. So while handling 100 items might only take a second or two, ten times as many must take at least 100 times more time. The problem with that in a compilation system is that the first customer with a program with a lot of tags would find performance unacceptable. (What "a lot" is is debatable.) Two stories about this: (1) A friend of mine was working for a company developing a computer typesetting system. They has been testing prototypes for several weeks, and all was going well. A demonstration for company executives was arranged. The executive asked for a 72 point headline to be produced. The machine took several minutes to produce each letter. The algorithm used was quadratic in the type size, and all of the testing had been on small text. Within a week, the product was canceled, and the entire team fired. My friend was out of work. (2) Early in the development of Janus/Ada, we created and debugged an expression resolution algorithm. An algorithm as complex as Ada resolution hadn't really been used in compilers before, and the few articles on the topic didn't make much sense. So we built our own. It worked great for several years. An new ACVC version came out. The compiler hung on one of the new tests. We were unable to find the infinite loop causing the problem. Eventually we figured out that that was because the loop wasn't infinite; it was coming from resolving an expression with 50 concats in a row. Experiments showed that the compiler was working just fine, but the expected compilation time on that expression was roughly 20.5 years. The problem being that there were a lot of "&" operations being tested, and each level tested those operations for all possible combinations of types. So something like 8**50 tests were being performed, and that was a problem. Obviously, we needed to compile the ACVC (now ACATS) a lot quicker than that. I found a quick fix by testing the operands in the reverse order. Doing it left to right caused the most ambiguous operations to be tested first, which maximized the runtime. You could still trigger the problem with lots of parens, but just writing A & B & C & ... wouldn't cause trouble. (I don't know if we ever actually fixed the problem, or if it just never appeared again.) Moral of both of these stories: One does not want to knowingly depend on quadratic operations, because as soon as someone sticks in a larger than anticipated input, you will have trouble. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 3:28 ` Randy Brukardt 2014-04-10 8:42 ` Georg Bauhaus @ 2014-04-10 15:31 ` Dmitry A. Kazakov 2014-04-10 22:08 ` Randy Brukardt ` (2 more replies) 1 sibling, 3 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-10 15:31 UTC (permalink / raw) On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net... >> On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net... >>>> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote: >>> ... >>>>> Mixed operations are not the Ada way of typing. >>>> >>>> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are >>>> related subtypes, promoted to types due to implementation reasons only. >>> >>> Obvious to you only. Any single program/subsystem should stick to a single >>> string type. The fact that you can't do that in Ada (unless that type is >>> String) is the bug that needs to be fixed. >> >> I don't understand what you are trying to say. Is it that no program shall >> use both Unbounded_String and String or that there must be no String >> (Unbounded_String) at all? > > There should be no reason for a single subsystem to use more than one string > type. Where that follows from? > The fact that that is not true in Ada today is the cause of most of > the problems. This is even more perplexing. It is two different statements: 1. I can invent a string type for all purposes, thus all applications will use it. 2. Any given application needs only one string type, but different applications may require different string types. Both statements are evidently false. > As a correllary, as many operations as possible should work with all > possible string types (Root_String'Class in my formulation) -- most of the > time when you need to use multiple string types, its because you have > libraries that only work with one type (String, Unbounded_String, whatever) > and you need to use some other type. Libraries and applications use different types because each type has certain advantages and disadvantages over any other type. This is why many string types are needed, deploying different memory management strategies, different encodings and different subsets of Unicode. > So you end up converting back and > forth. If most the libraries simply take Root_String'Class, that doesn't > happen. It is as unrealistic as throwing out all numeric types and using arbitrary precision arithmetic instead. It simply does not work for real-life applications. > Ambiguous? That's the idea -- most consumers of strings don't care anything > about the properties of the string, just the sequence of code points that it > represents. Class-wide operations are overloaded, which is why. > Require type casts? No idea why you think that - that only happens in bad > abstractions where you find yourself upcasting to get at components that > "you know are there". Such things are just plain bad, and surely aren't > going to happen here as nothing of the implementation is going to be > exposed. (I.e. either use Root_String'Class, or use a specific type - and > under no circumstances should you change mid-stream.) When the result is class-wide you have to cast it to the specific type. You cannot go all the way with class-wide objects. It does not work. > >> And in any case, the whole point is to >>> eliminate the requirement to use a single, specific string type for >>> operations that should be generic (generic in the English, not Ada, >>> sense). >> >> And the whole point of keeping operation primitive is to have its >> interface generic and the implementation type-specific. > > We don't want "type-specific" implementations of most things -- that's just > adding a maintenance headache where one isn't needed. It is need for 1. safety (because you statically know that certain specific operation may not fail, while class-wide operations can) 2. efficiency There is no maintenance overhead whatsoever. Here is the proof. Let you can provide a generic implementation (as you suggested), then this implementation can be safely inherited. Therefore whether you provide an overriding or leave it as is that has no influence of the program behavior => no maintenance problem. > Why would anyone want > a "type-specific" implementation of file open? Because generic operation would not work. What lseek is supposed to do with terminal input? Files are different per nature of medium they represent, so are strings. There are interfaces common for various subsets of files and strings. But there is no single usable interface for the set of all files or the set of all strings. The model of type extension does not function in real-life. > Or exception messages? That's > precisely the cause of the problem that we currently have. The cause is that the language does not support factoring out interfaces in their variety. It either forces single interface for all objects or no common interface at all. That leads to the design of string types Ada had (no common interface). Your idea of single interface will fail as well. No interface is C programmed in Ada. Yours is SmallTalk in Ada, with any method applicable to any object and MessageNotUnderstood raised at run-time. I bet that most Ada programmers would prefer C-esque approach to that. It is uncomfortable but at least safe. > But you're saying that we shouldn't solve the problem at all, since the > entire problem is forcing the use of specific types in language-defined > libraries (and similarly in user-defined libraries). Making operations primitive does not force user-defined libraries to anything. They still can be designed in generic terms. But since there will more classes than single root string, it will be also possible to design specialized libraries as well. And I see a general language problem in inability to add primitive operations without huge efforts, e.g. type My_Type_With_New_Ops is new Old_Type with null record; There must be better means for that especially due to MD. MD will not work when involved types are frozen. > You seem so focused on virtually useless operations like Append -- they have > no real value in an Ada application, as the primitives (slicing and &) do > the job better anyway. One is forced to use them for unbounded string, > mainly because you don't have very good access to the primitives for those > types -- that's the whole idea of this change. Append is very useful because Unbounded_Strings are usually constructed incrementally by adding pieces. But that is beside the point. I am focused on the language features which would allow the programmer to describe conglomerates of types like string types. String types is just an example to illustrate language weaknesses. Same applies to numeric types, to matrices, to containers/indices/iterators. Wherever you look you see the same problem, the language type system is deficient. >>>> It does not make any sense to me. Consider the operation Append. Which >>>> class does it belong to? Does it act on String? Is the argument UCS-2? >>> >>> Append takes two operands of Root_String'Class, and returns an >>> Root_String'Class with the type of its first argument. What's the >>> problem? >> >> Append is a procedure. Modifiers of Unbounded_String are in-place >> operations, that is the major use case for having Unbounded_String at all. > > OK, then it takes an in out parameter of Root_String'Class, and an in > parameter of Root_String'Class. What's the problem? The problem is passing String as the in out parameter there. You have a behavior change undetected at compile time. This is not Ada. >>>>> No, I'm deriving from an abstract type with no representation. There's >>>>> a huge difference. >>>> >>>> No difference whatsoever. We are talking about interfaces. The interface >>>> of Unbounded_String is not the interface of String. >>> >>> That's true, but that's a bug. They *should* be the same; only the >>> runtime behavior should differ (when exceptions are raised and the like). >> >> They should not and cannot. The type String cannot have procedure Append >> because String size is contracted to be constant. Immutable bounds is the >> major use case of String. Mutable bounds is of Unbounded_String. You >> cannot have both "same." > > Of course you can. Consider Bounded string, which has a bound, but it's > partly mutable. Or better, consider the containers -- they have bounded and > unbounded versions. Semantically, they all have bounds, it's just that the > unbounded version increases the bound automatically when needed. There would > be no problem having a fixed size container (other than such a thing would > be redunant with the existing arrays). Append is defined in > Ada.Strings.Fixed, after all, so of course it works for a fixed length > string. Where? >> Everything should work exactly so it does now, but without explicit type >> conversions. > > Yeah, and every girl should want to go out with you, without an explicit > invitation. :-) Yes! That would be even better than MD! (:-)) >>>> Append (S, SUNDANESE_LETTER_KHA); >>> >>> Yes, that's good. If the underlying type cannot store the letter, >>> Constraint_Error is raised. >> >> Yes! You want weak typing all the way! > > Yes, that's exactly the idea of class-wide operations -- one weakens the > typing (by allowing classes of operations) in order to get more generality. It is not generality it is a bug. If String cannot implement this interface. Why should it pretend to have? >> In my system the above will be compile error because >> >> 1. String does not have Append; > > String *does* have Append (in Ada.Strings.Fixed). Why do you think those > operations are part of Unbounded_String but not part of String simply > because someone stuck the latter ones in a library? A.4.3 does not declare Append. declare S : String (1..10); begin Append (S, "A"); -- What is this supposed to do? > If the clients become illegal, then you don't have Beaujolias, and all is > well. But that's not the system you described. You descibed one with > preference rules, and when those exist, an addition or deletion potentially > causes one legal program to become a different legal program - because the > preference rule causes a different routine to be called rather than making > the call illegal. I never said that preference rules should have this effect. Why should they, an example? >>> That means that there is no hope for >>> reusable software - the originator of the software has to be able to >>> modify it in order to improve or correct it. If that breaks all clients, then >>> either one can do nothing at all, or people just have to stick to their >>> existing (buggy) versions. Neither is acceptable. >> >> Ada has no support for dynamic linking anyway, so it is how it is right >> now. Introducing MD won't make bad any worse. > > MD isn't the problem; preference rules are the problem. That requires a proof which shows that no set of rules can exist that fulfills the requirements X, Y, Z. So far it is word against word. Not even X, Y, Z is formulated. > And what does dynamic linking have to do with anything? You should be able > to get the new version of GTK or Claw and recompile -- if legal, the program > should work the same way. Period. That's not the case in a system with > preference rules for user-defined operations. I see no problem why it shouldn't be possible. As for dynamic linking, the point is to use a new version *without* recompiling and re-linking. >>> But it's all we have. Sure, you can map a tag (this requires a loop, either >>> a brute force lookup or some fancier but much more code-intensive version), >>> but that's going to make dispatching far more expensive. You can't do this >>> mapping at compile-time because what mapping you need depends on the >>> interfaces in use. >> >> I can build a perfect hash at bind/link time when all involved tags become >> known. > > "can" means "possible", not "practical". That might be possible if the > number of tags is small, but that's not the case in a lot of OO systems. (A > Claw program starts with somewhere around 80.) Finding a perfect hash gets > very time consuming if the number of items is large - I don't think people > will be very happy with binding that takes 12 hours. A suboptimal hash wont make much harm. You use different algorithms for debug and release version optimized for speed. I don't see it as a problem. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 15:31 ` Dmitry A. Kazakov @ 2014-04-10 22:08 ` Randy Brukardt 2014-04-11 6:20 ` Dmitry A. Kazakov 2014-04-10 22:39 ` Randy Brukardt 2014-04-11 19:04 ` Niklas Holsti 2 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-10 22:08 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... ... > This is even more perplexing. It is two different statements: > > 1. I can invent a string type for all purposes, thus all applications will > use it. Certainly not. > 2. Any given application needs only one string type, but different > applications may require different string types. This is, in general, true. There probably are some wild outlier cases where this is not true, but it should be very rare. It's certainly the rule I've used in my programs. The problem is that Unbounded_String (in it's existing Ada implementation) cannot truly be used in place of String. > Both statements are evidently false. Sure, if you literally mean *all* programs. But I've never meant that. >> As a correllary, as many operations as possible should work with all >> possible string types (Root_String'Class in my formulation) -- most of >> the >> time when you need to use multiple string types, its because you have >> libraries that only work with one type (String, Unbounded_String, >> whatever) >> and you need to use some other type. > > Libraries and applications use different types because each type has > certain advantages and disadvantages over any other type. This is why many > string types are needed, deploying different memory management strategies, > different encodings and different subsets of Unicode. Right, and each application should use one such type. As far as libraries go, there's clearly two kinds. The only one I care about in this context are trying to provide some sort of general usage of strings. Restrictions on the type of strings that they operate on just get in the way. >> So you end up converting back and >> forth. If most the libraries simply take Root_String'Class, that doesn't >> happen. > > It is as unrealistic as throwing out all numeric types and using arbitrary > precision arithmetic instead. It simply does not work for real-life > applications. Huh? It's exactly how I would define Root_Integer'Class if we had such a thing. But the operations would be implemented using dispatching, no arbitrary precision arithmetic. >> Ambiguous? That's the idea -- most consumers of strings don't care >> anything >> about the properties of the string, just the sequence of code points that >> it >> represents. > > Class-wide operations are overloaded, which is why. Overloaded with what? The whole idea with class-wide operations is that there is only one of each. Only one body to maintain, works for everything. >.. here". Such things are just plain bad, and surely aren't >> going to happen here as nothing of the implementation is going to be >> exposed. (I.e. either use Root_String'Class, or use a specific type - and >> under no circumstances should you change mid-stream.) > > When the result is class-wide you have to cast it to the specific type. > You > cannot go all the way with class-wide objects. It does not work. Wow, proof by repeated assertion. It does indeed work, especially using containers holding class-wide items. You only go to specific types via dispatching, and one does that fairly rarely. It's more of a problem with a object with a heavy, large interface, because one ends up missing operations. (Everything is impractical with a large interface - OO makes little sense for such types.) But that doesn't occur for simple things like string or integer, because the interface is small and complete. --- It's becoming clear that there is no more to be learned here. We have no agreement even on the problem here, so there is no point about worrying about solutions. You are simply denying that the interesting problem can be solved at all, so there is no further point in talking to you on this topic. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 22:08 ` Randy Brukardt @ 2014-04-11 6:20 ` Dmitry A. Kazakov 2014-04-11 21:34 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-11 6:20 UTC (permalink / raw) On Thu, 10 Apr 2014 17:08:37 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... > ... >> It is as unrealistic as throwing out all numeric types and using arbitrary >> precision arithmetic instead. It simply does not work for real-life >> applications. > > Huh? It's exactly how I would define Root_Integer'Class if we had such a > thing. And no any program needs both Integer_16 and Unsigned_8 anyway. Right? >>> Ambiguous? That's the idea -- most consumers of strings don't care anything >>> about the properties of the string, just the sequence of code points that it >>> represents. >> >> Class-wide operations are overloaded, which is why. > > Overloaded with what? With operations of other classes especially operations of subclasses. Return a class-wide object is a nightmare. I had a lot of problems with class-wide operations in recent projects. It is not only ambiguity, but also a hell of type conversions and other tricks required when you have to return a class-wide. It works only on paper. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-11 6:20 ` Dmitry A. Kazakov @ 2014-04-11 21:34 ` Randy Brukardt 0 siblings, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-11 21:34 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:n89glydkjsjz.17f34lyu7q1j4.dlg@40tude.net... > On Thu, 10 Apr 2014 17:08:37 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... >> ... >>> It is as unrealistic as throwing out all numeric types and using >>> arbitrary >>> precision arithmetic instead. It simply does not work for real-life >>> applications. >> >> Huh? It's exactly how I would define Root_Integer'Class if we had such a >> thing. > > And no any program needs both Integer_16 and Unsigned_8 anyway. Right? > >>>> Ambiguous? That's the idea -- most consumers of strings don't care >>>> anything >>>> about the properties of the string, just the sequence of code points >>>> that it >>>> represents. >>> >>> Class-wide operations are overloaded, which is why. >> >> Overloaded with what? > > With operations of other classes especially operations of subclasses. > Return a class-wide object is a nightmare. I had a lot of problems with > class-wide operations in recent projects. It is not only ambiguity, but > also a hell of type conversions and other tricks required when you have to > return a class-wide. It works only on paper. Then OOP doesn't work, because that's the only sensible use of OOP (to get "generic" operations while still preserving individual characteristics). Otherwise, you might as well build a set of unrelated types and use generics. I can believe that there are problems inhibiting the use of class-wide types in this way, but those are precisely the problems that the language needs to address. Without class-wide programming, OOP is simply a waste of effort (and runtime). Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 15:31 ` Dmitry A. Kazakov 2014-04-10 22:08 ` Randy Brukardt @ 2014-04-10 22:39 ` Randy Brukardt 2014-04-11 6:40 ` Dmitry A. Kazakov 2014-04-11 19:04 ` Niklas Holsti 2 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-10 22:39 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... > On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: ... >>> Ada has no support for dynamic linking anyway, so it is how it is right >>> now. Introducing MD won't make bad any worse. >> >> MD isn't the problem; preference rules are the problem. > > That requires a proof which shows that no set of rules can exist that > fulfills the requirements X, Y, Z. So far it is word against word. Not > even > X, Y, Z is formulated. Actually, there was such a formal proof constructed during the design of Ada 9x. Unfortunately, that's pretty much all I remember about it, so it's not much help in this discussion. But it's quite clear that (sane) preference rules cause Beaujolias. Consider an expression node for which two choices (let's call them A and B) remain after eliminating obvious mismatches. (This situation can be common when literals are involved, as they match so many types). Ada of course makes the expression illegal in this case, specifically to avoid Beaujolias. But let's consider a preference rule instead. The rule choses A over B, and then the program is legal and runs. Now consider adding another operation C in some package that's referenced by the semantic closure ("with" in Ada) of our expression. Assume that C also is a possible choice for our expression node. If the preference rule picks C rather than A (or picks B for that matter), then we have the classic Beaujolias scenario when a legal program does something different because an operation is added to an unrelated package. It doesn't matter what the preference rule is, one can always construct such a scenario. Unless, of course, the preference rule depends on something other than the name and type profiles declared in the source code. Using temporal information would work, of course, but it would be a nightmare for portability, as starting a new project with the same source code would change that information and cause the program to run differently. I believe that any rule not involving the contents of the source code would have similar problems. The only time a preference rule is safe is if no user can add or delete operations for the types in question. That's why it's OK for univeral_integer. (It also means that future versions of the language can't add or delete operations for universal_integer, which might be a problem someday.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 22:39 ` Randy Brukardt @ 2014-04-11 6:40 ` Dmitry A. Kazakov 2014-04-11 21:44 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-11 6:40 UTC (permalink / raw) On Thu, 10 Apr 2014 17:39:39 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... >> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: > ... >>>> Ada has no support for dynamic linking anyway, so it is how it is right >>>> now. Introducing MD won't make bad any worse. >>> >>> MD isn't the problem; preference rules are the problem. >> >> That requires a proof which shows that no set of rules can exist that >> fulfills the requirements X, Y, Z. So far it is word against word. Not >> even X, Y, Z is formulated. > > Actually, there was such a formal proof constructed during the design of Ada > 9x. Unfortunately, that's pretty much all I remember about it, so it's not > much help in this discussion. > > But it's quite clear that (sane) preference rules cause Beaujolias. > > Consider an expression node for which two choices (let's call them A and B) > remain after eliminating obvious mismatches. (This situation can be common > when literals are involved, as they match so many types). Ada of course > makes the expression illegal in this case, specifically to avoid Beaujolias. > > But let's consider a preference rule instead. The rule choses A over B, and > then the program is legal and runs. > > Now consider adding another operation C in some package that's referenced by > the semantic closure ("with" in Ada) of our expression. Assume that C also > is a possible choice for our expression node. If the preference rule picks C > rather than A (or picks B for that matter), then we have the classic > Beaujolias scenario when a legal program does something different because an > operation is added to an unrelated package. Your example refers to overloading possible for operations on unrelated types. I don't see how this is scenario could be possible for a primitive MD operation. One of the requirements put on MD is that *all* combinations of tags up to the root of the inheritance tree be defined and checked at compile time. This requirement automatically precludes appearance of C from air. It cannot be primitive and thus the preference rules would not apply to it. This requirement is actually a problem of MD, I don't know how to solve, i.e. how to stretch a hierarchy across several packages. Let two packages define two types P and Q and a cross operation F between. When in a third package R gets derived from P, then how and where we define F for R and Q, provided this third package may know nothing about the package of Q. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-11 6:40 ` Dmitry A. Kazakov @ 2014-04-11 21:44 ` Randy Brukardt 2014-04-12 8:45 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-11 21:44 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... > On Thu, 10 Apr 2014 17:39:39 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net... >>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: >> ... >>>>> Ada has no support for dynamic linking anyway, so it is how it is >>>>> right >>>>> now. Introducing MD won't make bad any worse. >>>> >>>> MD isn't the problem; preference rules are the problem. >>> >>> That requires a proof which shows that no set of rules can exist that >>> fulfills the requirements X, Y, Z. So far it is word against word. Not >>> even X, Y, Z is formulated. >> >> Actually, there was such a formal proof constructed during the design of >> Ada >> 9x. Unfortunately, that's pretty much all I remember about it, so it's >> not >> much help in this discussion. >> >> But it's quite clear that (sane) preference rules cause Beaujolias. >> >> Consider an expression node for which two choices (let's call them A and >> B) >> remain after eliminating obvious mismatches. (This situation can be >> common >> when literals are involved, as they match so many types). Ada of course >> makes the expression illegal in this case, specifically to avoid >> Beaujolias. >> >> But let's consider a preference rule instead. The rule choses A over B, >> and >> then the program is legal and runs. >> >> Now consider adding another operation C in some package that's referenced >> by >> the semantic closure ("with" in Ada) of our expression. Assume that C >> also >> is a possible choice for our expression node. If the preference rule >> picks C >> rather than A (or picks B for that matter), then we have the classic >> Beaujolias scenario when a legal program does something different because >> an >> operation is added to an unrelated package. > > Your example refers to overloading possible for operations on unrelated > types. I don't see how this is scenario could be possible for a primitive > MD operation. One of the requirements put on MD is that *all* combinations > of tags up to the root of the inheritance tree be defined and checked at > compile time. This requirement automatically precludes appearance of C > from > air. It cannot be primitive and thus the preference rules would not apply > to it. Doesn't matter. First, you'd have to prevent adding or removing new primitive operations to a hierarchy. That seems like a nasty limitation. Second, you can introduce a new primitive operation by withing ["ripple"] or using ["Beaujolias"] an existing package that wasn't previously part of the client. Introducing an otherwise unused package ought not change the behavior of a client. > This requirement is actually a problem of MD, I don't know how to solve, > i.e. how to stretch a hierarchy across several packages. Let two packages > define two types P and Q and a cross operation F between. When in a third > package R gets derived from P, then how and where we define F for R and Q, > provided this third package may know nothing about the package of Q. I suppose if you could actually solve such a problem without introducing crazy usage requirements, you could get the same effect as a preference rule safely. But I'd guess (and I admit it is a guess) that the problems are essentially the same and the fact that one clearly fails the test means that the other would clearly fail the test as well. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-11 21:44 ` Randy Brukardt @ 2014-04-12 8:45 ` Dmitry A. Kazakov 2014-04-14 23:39 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-12 8:45 UTC (permalink / raw) On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... >> Your example refers to overloading possible for operations on unrelated >> types. I don't see how this is scenario could be possible for a primitive >> MD operation. One of the requirements put on MD is that *all* combinations >> of tags up to the root of the inheritance tree be defined and checked at >> compile time. This requirement automatically precludes appearance of C from >> air. It cannot be primitive and thus the preference rules would not apply >> to it. > > Doesn't matter. First, you'd have to prevent adding or removing new > primitive operations to a hierarchy. That seems like a nasty limitation. What? This limitation is with us since Ada 95! You cannot add a primitive operation after the freezing point in Ada. You cannot remove a primitive operation at all. > Second, you can introduce a new primitive operation by withing ["ripple"] or > using ["Beaujolias"] an existing package that wasn't previously part of the > client. Introducing an otherwise unused package ought not change the > behavior of a client. It will not, because the rule [*] should be that tags higher in the hierarchy (counting from the root) than the highest known tag in the expression should not be considered. E.g. if you have Root <- A <- B <- C Then in the expression A + B, the variant C'(A + B) is automatically depreciated. >> This requirement is actually a problem of MD, I don't know how to solve, >> i.e. how to stretch a hierarchy across several packages. Let two packages >> define two types P and Q and a cross operation F between. When in a third >> package R gets derived from P, then how and where we define F for R and Q, >> provided this third package may know nothing about the package of Q. > > I suppose if you could actually solve such a problem without introducing > crazy usage requirements, you could get the same effect as a preference rule > safely. Possibly. > But I'd guess (and I admit it is a guess) that the problems are > essentially the same and the fact that one clearly fails the test means that > the other would clearly fail the test as well. If so, then OO failed, as you used to say! ---------------- * This rule is akin to no re-dispatch rule -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 8:45 ` Dmitry A. Kazakov @ 2014-04-14 23:39 ` Randy Brukardt 2014-04-15 7:55 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-14 23:39 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net... > On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... > >>> Your example refers to overloading possible for operations on unrelated >>> types. I don't see how this is scenario could be possible for a >>> primitive >>> MD operation. One of the requirements put on MD is that *all* >>> combinations >>> of tags up to the root of the inheritance tree be defined and checked at >>> compile time. This requirement automatically precludes appearance of C >>> from >>> air. It cannot be primitive and thus the preference rules would not >>> apply >>> to it. >> >> Doesn't matter. First, you'd have to prevent adding or removing new >> primitive operations to a hierarchy. That seems like a nasty limitation. > > What? This limitation is with us since Ada 95! You cannot add a primitive > operation after the freezing point in Ada. You cannot remove a primitive > operation at all. This is an issue with program maintenance, not with an unchanging declaration -- so freezing is completely irrelevant. If someone decides there is a need to add a primitive operation to the root (for instance), then a preference rule towrd the root could potentially silently change the behavior of a otherwise tested/proved program. That's the sort of thing that needs to be prevented, lest maintenance become too dangerous to allow in existing systems. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-14 23:39 ` Randy Brukardt @ 2014-04-15 7:55 ` Dmitry A. Kazakov 2014-04-15 21:27 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-15 7:55 UTC (permalink / raw) On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net... >> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... >> >>>> Your example refers to overloading possible for operations on unrelated >>>> types. I don't see how this is scenario could be possible for a >>>> primitive >>>> MD operation. One of the requirements put on MD is that *all* >>>> combinations >>>> of tags up to the root of the inheritance tree be defined and checked at >>>> compile time. This requirement automatically precludes appearance of C >>>> from >>>> air. It cannot be primitive and thus the preference rules would not >>>> apply >>>> to it. >>> >>> Doesn't matter. First, you'd have to prevent adding or removing new >>> primitive operations to a hierarchy. That seems like a nasty limitation. >> >> What? This limitation is with us since Ada 95! You cannot add a primitive >> operation after the freezing point in Ada. You cannot remove a primitive >> operation at all. > > This is an issue with program maintenance, not with an unchanging > declaration -- so freezing is completely irrelevant. If someone decides > there is a need to add a primitive operation to the root (for instance), > then a preference rule towrd the root could potentially silently change the > behavior of a otherwise tested/proved program. That's the sort of thing that > needs to be prevented, lest maintenance become too dangerous to allow in > existing systems. It is not prevented now and cannot be prevented in the future. If you change the package specification, which is the only way to add an operation you potentially change anything. This requires recompilation of all clients, which is OK, as you said earlier. Thus the problem does not exist. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 7:55 ` Dmitry A. Kazakov @ 2014-04-15 21:27 ` Randy Brukardt 2014-04-16 7:52 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-15 21:27 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:f2mjap6bd64o$.1kk55f3m1qbn1$.dlg@40tude.net... > On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net... >>> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote: >>> >>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... >>> >>>>> Your example refers to overloading possible for operations on >>>>> unrelated >>>>> types. I don't see how this is scenario could be possible for a >>>>> primitive >>>>> MD operation. One of the requirements put on MD is that *all* >>>>> combinations >>>>> of tags up to the root of the inheritance tree be defined and checked >>>>> at >>>>> compile time. This requirement automatically precludes appearance of C >>>>> from >>>>> air. It cannot be primitive and thus the preference rules would not >>>>> apply >>>>> to it. >>>> >>>> Doesn't matter. First, you'd have to prevent adding or removing new >>>> primitive operations to a hierarchy. That seems like a nasty >>>> limitation. >>> >>> What? This limitation is with us since Ada 95! You cannot add a >>> primitive >>> operation after the freezing point in Ada. You cannot remove a primitive >>> operation at all. >> >> This is an issue with program maintenance, not with an unchanging >> declaration -- so freezing is completely irrelevant. If someone decides >> there is a need to add a primitive operation to the root (for instance), >> then a preference rule towrd the root could potentially silently change >> the >> behavior of a otherwise tested/proved program. That's the sort of thing >> that >> needs to be prevented, lest maintenance become too dangerous to allow in >> existing systems. > > It is not prevented now and cannot be prevented in the future. If you > change the package specification, which is the only way to add an > operation > you potentially change anything. This requires recompilation of all > clients, which is OK, as you said earlier. Thus the problem does not > exist. (A) we're specifically talking about a single addition or deletion, *not* a general "change". (B) Of course we're changing the specification and recompiling. But we don't want the same client code to mean something different after that recompilation without detection -- in the case of a single addition or deletion (again, *not* a change). The reason here is that maintainers need to be free to ADD new operations/entities without changing the behavior of any pre-existing client (which necessarily does not use those new operations/entities). Otherwise, maintenance is just a turkey shoot in which you really have no idea what will happen -- deadly in large systems, especially with reused code that's not in your control (think of a new version of GTK or Claw). OTOH, if maintainers *change* an operation/entity, then the language can (and should) provide no assurances. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 21:27 ` Randy Brukardt @ 2014-04-16 7:52 ` Dmitry A. Kazakov 2014-04-16 21:53 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-16 7:52 UTC (permalink / raw) On Tue, 15 Apr 2014 16:27:05 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:f2mjap6bd64o$.1kk55f3m1qbn1$.dlg@40tude.net... >> On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net... >>>> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote: >>>> >>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>>>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net... >>>> >>>>>> Your example refers to overloading possible for operations on >>>>>> unrelated >>>>>> types. I don't see how this is scenario could be possible for a >>>>>> primitive >>>>>> MD operation. One of the requirements put on MD is that *all* >>>>>> combinations >>>>>> of tags up to the root of the inheritance tree be defined and checked >>>>>> at >>>>>> compile time. This requirement automatically precludes appearance of C >>>>>> from >>>>>> air. It cannot be primitive and thus the preference rules would not >>>>>> apply >>>>>> to it. >>>>> >>>>> Doesn't matter. First, you'd have to prevent adding or removing new >>>>> primitive operations to a hierarchy. That seems like a nasty >>>>> limitation. >>>> >>>> What? This limitation is with us since Ada 95! You cannot add a >>>> primitive >>>> operation after the freezing point in Ada. You cannot remove a primitive >>>> operation at all. >>> >>> This is an issue with program maintenance, not with an unchanging >>> declaration -- so freezing is completely irrelevant. If someone decides >>> there is a need to add a primitive operation to the root (for instance), >>> then a preference rule towrd the root could potentially silently change >>> the >>> behavior of a otherwise tested/proved program. That's the sort of thing >>> that >>> needs to be prevented, lest maintenance become too dangerous to allow in >>> existing systems. >> >> It is not prevented now and cannot be prevented in the future. If you >> change the package specification, which is the only way to add an >> operation >> you potentially change anything. This requires recompilation of all >> clients, which is OK, as you said earlier. Thus the problem does not >> exist. > > (A) we're specifically talking about a single addition or deletion, *not* a > general "change". And how is it different from single dispatch? Let you override f in S. Then f(X), given X is of S, will call to the new body. > (B) Of course we're changing the specification and recompiling. But we don't > want the same client code to mean something different after that > recompilation without detection -- in the case of a single addition or > deletion (again, *not* a change). It must mean something different. That was the *purpose* of the change to make the client code mean it different *when* the clients use the types and operations for which the change was made. > The reason here is that maintainers need to be free to ADD new > operations/entities without changing the behavior of any pre-existing client > (which necessarily does not use those new operations/entities). Again, no difference between SD and MD. If you add a new primitive operation (not override an existing one), there cannot be any effect on the clients because they did not use the operation. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-16 7:52 ` Dmitry A. Kazakov @ 2014-04-16 21:53 ` Randy Brukardt 2014-04-17 7:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-16 21:53 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net... ... >> (A) we're specifically talking about a single addition or deletion, *not* >> a >> general "change". > > And how is it different from single dispatch? Let you override f in S. > Then > f(X), given X is of S, will call to the new body. "overriding" is a change of an existing operation, not what I'm talking about here. >> (B) Of course we're changing the specification and recompiling. But we >> don't >> want the same client code to mean something different after that >> recompilation without detection -- in the case of a single addition or >> deletion (again, *not* a change). > > It must mean something different. That was the *purpose* of the change to > make the client code mean it different *when* the clients use the types > and > operations for which the change was made. > >> The reason here is that maintainers need to be free to ADD new >> operations/entities without changing the behavior of any pre-existing >> client >> (which necessarily does not use those new operations/entities). > > Again, no difference between SD and MD. If you add a new primitive > operation (not override an existing one), there cannot be any effect on > the > clients because they did not use the operation. But that's not now and never has been true. Why? Because the new operation can have the same name as some existing operation, and the entire point of this discussion is that preference rules in overloading resolution have potentially bad effects in such cases. Anyway, what I get from your responses is that you don't think that there is any real issue with maintenance (in that you think a change is a change is a change, and if there is a change, then behavior might change). Perhaps you are right, but that's been one of the cornerstones of the Ada design since the beginning, and abandoning it for convinience would be essentally the same as abandoning the "maintainability" goals of Ada. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-16 21:53 ` Randy Brukardt @ 2014-04-17 7:39 ` Dmitry A. Kazakov 2014-04-17 17:29 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-17 7:39 UTC (permalink / raw) On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net... > ... >>> The reason here is that maintainers need to be free to ADD new >>> operations/entities without changing the behavior of any pre-existing >>> client (which necessarily does not use those new operations/entities). >> >> Again, no difference between SD and MD. If you add a new primitive >> operation (not override an existing one), there cannot be any effect on >> the clients because they did not use the operation. > > But that's not now and never has been true. Why? Because the new operation > can have the same name as some existing operation, and the entire point of > this discussion is that preference rules in overloading resolution have > potentially bad effects in such cases. No, it can have the same name only if the signature is different. That would be overloading, thus whatever rules of preference for MD are, they would not apply. If you want to say that overloading is a can of worms. Yes it is. But that has nothing to do with MD vs. SD and ambiguity resolution there. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-17 7:39 ` Dmitry A. Kazakov @ 2014-04-17 17:29 ` Randy Brukardt 2014-04-17 19:54 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-17 17:29 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1239ezez4bgf7.e2ihtjo019ka.dlg@40tude.net... > On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net... >> ... >>>> The reason here is that maintainers need to be free to ADD new >>>> operations/entities without changing the behavior of any pre-existing >>>> client (which necessarily does not use those new operations/entities). >>> >>> Again, no difference between SD and MD. If you add a new primitive >>> operation (not override an existing one), there cannot be any effect on >>> the clients because they did not use the operation. >> >> But that's not now and never has been true. Why? Because the new >> operation >> can have the same name as some existing operation, and the entire point >> of >> this discussion is that preference rules in overloading resolution have >> potentially bad effects in such cases. > > No, it can have the same name only if the signature is different. That > would be overloading, thus whatever rules of preference for MD are, they > would not apply. > > If you want to say that overloading is a can of worms. Yes it is. But that > has nothing to do with MD vs. SD and ambiguity resolution there. Well, talking about Ada, there is only overloading resolution. The same rules apply to all calls, there is nothing special about primitive operations. One could certainly imagine other rules, but they wouldn't fit into the framework of Ada resolution without a lot of reworking. Like a lot of your ideas, they would make much more sense in a new language rather than in the context of the existing Ada language. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-17 17:29 ` Randy Brukardt @ 2014-04-17 19:54 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-17 19:54 UTC (permalink / raw) On Thu, 17 Apr 2014 12:29:29 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1239ezez4bgf7.e2ihtjo019ka.dlg@40tude.net... >> On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net... >>> ... >>>>> The reason here is that maintainers need to be free to ADD new >>>>> operations/entities without changing the behavior of any pre-existing >>>>> client (which necessarily does not use those new operations/entities). >>>> >>>> Again, no difference between SD and MD. If you add a new primitive >>>> operation (not override an existing one), there cannot be any effect on >>>> the clients because they did not use the operation. >>> >>> But that's not now and never has been true. Why? Because the new operation >>> can have the same name as some existing operation, and the entire point of >>> this discussion is that preference rules in overloading resolution have >>> potentially bad effects in such cases. >> >> No, it can have the same name only if the signature is different. That >> would be overloading, thus whatever rules of preference for MD are, they >> would not apply. >> >> If you want to say that overloading is a can of worms. Yes it is. But that >> has nothing to do with MD vs. SD and ambiguity resolution there. > > Well, talking about Ada, there is only overloading resolution. The same > rules apply to all calls, there is nothing special about primitive > operations. One could certainly imagine other rules, but they wouldn't fit > into the framework of Ada resolution without a lot of reworking. The point I made was about possibility to have preference rules for MD without "bad effects." In order to disprove it you should present a case showing that no set of rules could prevent such effects. Regarding "reworking" there is no reworking because MD is non-existent in Ada. > Like a lot of your ideas, they would make much more sense in a new language > rather than in the context of the existing Ada language. This again requires a proof, which would be quite difficult to make, because the only reason why MD or other sound type construct would be impossible in Ada then due to some fatal design errors in the language core. I trust Ada design most of the time. It surprises me that you seemingly do not. But then you should present these alleged design faults. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-10 15:31 ` Dmitry A. Kazakov 2014-04-10 22:08 ` Randy Brukardt 2014-04-10 22:39 ` Randy Brukardt @ 2014-04-11 19:04 ` Niklas Holsti 2014-04-11 20:43 ` Dmitry A. Kazakov 2 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-11 19:04 UTC (permalink / raw) On 14-04-10 17:31 , Dmitry A. Kazakov wrote: > On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: [snip] >> We don't want "type-specific" implementations of most things -- that's just >> adding a maintenance headache where one isn't needed. > > It is need for > > 1. safety (because you statically know that certain specific operation may > not fail, while class-wide operations can) > > 2. efficiency > > There is no maintenance overhead whatsoever. Here is the proof. Let you can > provide a generic implementation (as you suggested), then this > implementation can be safely inherited. If you change a class-wide operation to an inherited (i.e. primitive) operation, you have to change its dispatching calls to redispatching calls, if you want the same behaviour as for the class-wide operation. But (based on your earlier messages) you refuse to use redispatch, so this change is not possible for you. Your proof fails when limited to your subset of Ada, where redispatch is absent. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-11 19:04 ` Niklas Holsti @ 2014-04-11 20:43 ` Dmitry A. Kazakov 2014-04-11 22:04 ` Niklas Holsti 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-11 20:43 UTC (permalink / raw) On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote: > On 14-04-10 17:31 , Dmitry A. Kazakov wrote: >> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: > > [snip] > >>> We don't want "type-specific" implementations of most things -- that's just >>> adding a maintenance headache where one isn't needed. >> >> It is need for >> >> 1. safety (because you statically know that certain specific operation may >> not fail, while class-wide operations can) >> >> 2. efficiency >> >> There is no maintenance overhead whatsoever. Here is the proof. Let you can >> provide a generic implementation (as you suggested), then this >> implementation can be safely inherited. > > If you change a class-wide operation to an inherited (i.e. primitive) > operation, you have to change its dispatching calls to redispatching > calls, if you want the same behaviour as for the class-wide operation. No. I meant that the behavior of class-wide operation was defined = there were no re-dispatch to operations that could be overridden to some unanticipated behavior. If not, then Randy's argument about maintenance is automatically false. > But (based on your earlier messages) you refuse to use redispatch, so > this change is not possible for you. Your proof fails when limited to > your subset of Ada, where redispatch is absent. The premise of the proof was that the operation's behavior was well-defined. Otherwise, it is already unmaintainable. Regarding use cases where re-dispatch comes in question, which certainly exist, I think that from the safety and maintenance point of view, the type system should provide means of body composition beyond simple inherit vs. override. We know, for example, that constructors (initialize) and destructors (finalize) require other means of composition. More elaborated composition tools should eliminate re-dispatch (and most class-wide operations) => give safety and maintainability. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-11 20:43 ` Dmitry A. Kazakov @ 2014-04-11 22:04 ` Niklas Holsti 2014-04-12 8:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-11 22:04 UTC (permalink / raw) On 14-04-11 22:43 , Dmitry A. Kazakov wrote: > On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote: > >> On 14-04-10 17:31 , Dmitry A. Kazakov wrote: >>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: >> >> [snip] >> >>>> We don't want "type-specific" implementations of most things -- that's just >>>> adding a maintenance headache where one isn't needed. >>> >>> It is need for >>> >>> 1. safety (because you statically know that certain specific operation may >>> not fail, while class-wide operations can) >>> >>> 2. efficiency >>> >>> There is no maintenance overhead whatsoever. Here is the proof. Let you can >>> provide a generic implementation (as you suggested), then this >>> implementation can be safely inherited. >> >> If you change a class-wide operation to an inherited (i.e. primitive) >> operation, you have to change its dispatching calls to redispatching >> calls, if you want the same behaviour as for the class-wide operation. > > No. I meant that the behavior of class-wide operation was defined = there > were no re-dispatch to operations that could be overridden to some > unanticipated behavior. You mean that a class-wide operation should not call any primitive operations of its parameters? Your programming style / Ada subset is becoming "curiouser and curiouser". When _do_ you use dispatching? > Regarding use cases where re-dispatch comes in question, which certainly > exist, Ah, that is comforting. I thought you were totally against redispatch. > I think that from the safety and maintenance point of view, the type > system should provide means of body composition beyond simple inherit vs. > override. That is certainly an interesting issue. You are thinking of something of the same kind as the "inner" of Simula? In my own code, the primitive operations of a type are typically layered into levels: higher-level operations and lower-level ones. An overriding higher-level primitive operation is typically implemented by calling (with redispatch) lower-level primitive operations of the parameter object. The *same* (i.e. overridden) operation of the parent type is usually not called, nor does a primitive operation of a parent type call the same primitive operation from the actual derived type; only operations from lower layers are called. > We know, for example, that constructors (initialize) and > destructors (finalize) require other means of composition. More elaborated > composition tools should eliminate re-dispatch (and most class-wide > operations) => give safety and maintainability. Maybe... suggest something and we'll see. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-11 22:04 ` Niklas Holsti @ 2014-04-12 8:20 ` Dmitry A. Kazakov 2014-04-12 8:39 ` Nasser M. Abbasi 2014-04-13 19:43 ` Niklas Holsti 0 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-12 8:20 UTC (permalink / raw) On Sat, 12 Apr 2014 00:04:48 +0200, Niklas Holsti wrote: > On 14-04-11 22:43 , Dmitry A. Kazakov wrote: >> On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote: >> >>> On 14-04-10 17:31 , Dmitry A. Kazakov wrote: >>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: >>> >>> [snip] >>> >>>>> We don't want "type-specific" implementations of most things -- that's just >>>>> adding a maintenance headache where one isn't needed. >>>> >>>> It is need for >>>> >>>> 1. safety (because you statically know that certain specific operation may >>>> not fail, while class-wide operations can) >>>> >>>> 2. efficiency >>>> >>>> There is no maintenance overhead whatsoever. Here is the proof. Let you can >>>> provide a generic implementation (as you suggested), then this >>>> implementation can be safely inherited. >>> >>> If you change a class-wide operation to an inherited (i.e. primitive) >>> operation, you have to change its dispatching calls to redispatching >>> calls, if you want the same behaviour as for the class-wide operation. >> >> No. I meant that the behavior of class-wide operation was defined = there >> were no re-dispatch to operations that could be overridden to some >> unanticipated behavior. > > You mean that a class-wide operation should not call any primitive > operations of its parameters? They should, that was not the point. Which was maintainability. A class-wide operation cannot be more maintainable than a primitive operation. At least, it would require the level of contract thoroughness Ada presently does not possess, not even close. >> Regarding use cases where re-dispatch comes in question, which certainly >> exist, > > Ah, that is comforting. I thought you were totally against redispatch. Yes I am. Re-dispatch is a flawed solution to a real problem. I don't deny existence of the problem. I am against the solution, which is inherently unsafe and constraining (precludes by-copy semantics). >> I think that from the safety and maintenance point of view, the type >> system should provide means of body composition beyond simple inherit vs. >> override. > > That is certainly an interesting issue. You are thinking of something of > the same kind as the "inner" of Simula? Yes, but it looks too low-level and hackish to me. The concept should somehow play together with the notion of polymorphic operation defined on the class (set of types). Between these two ends: independent bodies of a primitive operation and single body of a class-wide operation, there lies a whole spectrum of unexplored possibilities. > In my own code, the primitive operations of a type are typically layered > into levels: higher-level operations and lower-level ones. An overriding > higher-level primitive operation is typically implemented by calling > (with redispatch) lower-level primitive operations of the parameter > object. The *same* (i.e. overridden) operation of the parent type is > usually not called, nor does a primitive operation of a parent type call > the same primitive operation from the actual derived type; only > operations from lower layers are called. Yes, this is the way I implement it too. The difference is that I try to keep "higher-level" operations class-wide. Then I try to maintain the "no abstraction inversion" rule, i.e. never call a "higher-level" operation from a "lower-level" one. Note that when "higher-level" operations are made class-wide, there is also a formalized separation of two, as they act on different types. >> We know, for example, that constructors (initialize) and >> destructors (finalize) require other means of composition. More elaborated >> composition tools should eliminate re-dispatch (and most class-wide >> operations) => give safety and maintainability. > > Maybe... suggest something and we'll see. It is useless to suggest anything, as you know. And, I am not a language designer anyway. I am a programmer. As a programmer, from my experience with Ada, I tell the language designers that they got it all wrong since Ada 2005. I don't want yet another dynamically typed or functional language. I need a language for software engineering. More static checks, more means to make static checks possible. The whole language should revolute around helping restructuring my programs in order to support static checks. No Constraint_Error to me, please! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 8:20 ` Dmitry A. Kazakov @ 2014-04-12 8:39 ` Nasser M. Abbasi 2014-04-12 9:38 ` Dmitry A. Kazakov 2014-04-13 19:43 ` Niklas Holsti 1 sibling, 1 reply; 240+ messages in thread From: Nasser M. Abbasi @ 2014-04-12 8:39 UTC (permalink / raw) On 4/12/2014 3:20 AM, Dmitry A. Kazakov wrote: > I need a language for software engineering. More static checks, > more means to make static checks possible. The whole language should > revolute around helping restructuring my programs in order to support > static checks. No Constraint_Error to me, please! > New languages seems to be all going the other way? the new language Julia http://en.wikipedia.org/wiki/Julia_%28programming_language%29 It is all about dynamic multiple dispatching http://en.wikipedia.org/wiki/Multiple_dispatch In Julia, the way I understand it, when defining a function with some signature, then a compiled instance of this function is made for all the possible primitive types (int16, int32, real32, real64, etc...) and when the program is run, the run-time automatically dispatches to the correct matching function based on the argument used at time the call is made. It seemed to me just Ada generics, but done automatically. Those good old fashioned, strong static type checking at compile time computer languages, seem like, well, old fashioned these days. --Nasser ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 8:39 ` Nasser M. Abbasi @ 2014-04-12 9:38 ` Dmitry A. Kazakov 2014-04-12 9:55 ` Georg Bauhaus 2014-04-12 10:17 ` Nasser M. Abbasi 0 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-12 9:38 UTC (permalink / raw) On Sat, 12 Apr 2014 03:39:44 -0500, Nasser M. Abbasi wrote: > On 4/12/2014 3:20 AM, Dmitry A. Kazakov wrote: > >> I need a language for software engineering. More static checks, >> more means to make static checks possible. The whole language should >> revolute around helping restructuring my programs in order to support >> static checks. No Constraint_Error to me, please! > > New languages seems to be all going the other way? They are going nowhere. There were no new language ideas for decades. > In Julia, the way I understand it, when defining a function > with some signature, then a compiled instance of this function > is made for all the possible primitive types (int16, int32, > real32, real64, etc...) Is made by whom? > and when the program is run, > the run-time automatically dispatches to the correct matching > function based on the argument used at time the call is made. Really? What is the "correct matching" function of int16/real32? Can I have real_bounded_interval_64? What would be int16/real_bounded_interval_64? Who does linear system equation resolution function for int16? The idea that there exist "primitive" and "non-primitive" types is garbage. The idea that any operation is applicable to any type is garbage. > Those good old fashioned, strong static type checking > at compile time computer languages, seem like, well, old > fashioned these days. If even members of ARG seem not to believe in merits of strong typing or whatever typing... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 9:38 ` Dmitry A. Kazakov @ 2014-04-12 9:55 ` Georg Bauhaus 2014-04-12 10:45 ` Dmitry A. Kazakov 2014-04-12 10:17 ` Nasser M. Abbasi 1 sibling, 1 reply; 240+ messages in thread From: Georg Bauhaus @ 2014-04-12 9:55 UTC (permalink / raw) On 12/04/14 11:38, Dmitry A. Kazakov wrote: >> >In Julia, the way I understand it, when defining a function >> >with some signature, then a compiled instance of this function >> >is made for all the possible primitive types (int16, int32, >> >real32, real64, etc...) > Is made by whom? > MIT. Announced for efficient scientific computing. Think: mathematician sitting in front of a terminal, wanting all available processors to compute a result and display it graphically. But without Matlab, and fast, and reasonably type checked. The download is 1.5 GiB and starts bootstrapping after compiling femto Lisp. It's the MIT, after all. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 9:55 ` Georg Bauhaus @ 2014-04-12 10:45 ` Dmitry A. Kazakov 2014-04-14 23:45 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-12 10:45 UTC (permalink / raw) On Sat, 12 Apr 2014 11:55:32 +0200, Georg Bauhaus wrote: > On 12/04/14 11:38, Dmitry A. Kazakov wrote: >>> >In Julia, the way I understand it, when defining a function >>> >with some signature, then a compiled instance of this function >>> >is made for all the possible primitive types (int16, int32, >>> >real32, real64, etc...) >> Is made by whom? > > MIT. I meant the implementation of all possible cross breeds of parameters. > Announced for efficient scientific computing. Sure. "This lotion is against cockroaches and a foot perspiration remedy. One drop of the lotion put in a glass of water turns it into a glass of vodka. Three drops of the same lotion do a glass of Cognac." -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 10:45 ` Dmitry A. Kazakov @ 2014-04-14 23:45 ` Randy Brukardt 0 siblings, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-14 23:45 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1bmn1nyjcs0ms.1hs63q2q8nzke.dlg@40tude.net... > On Sat, 12 Apr 2014 11:55:32 +0200, Georg Bauhaus wrote: > >> On 12/04/14 11:38, Dmitry A. Kazakov wrote: >>>> >In Julia, the way I understand it, when defining a function >>>> >with some signature, then a compiled instance of this function >>>> >is made for all the possible primitive types (int16, int32, >>>> >real32, real64, etc...) >>> Is made by whom? >> >> MIT. > > I meant the implementation of all possible cross breeds of parameters. > >> Announced for efficient scientific computing. > > Sure. > > "This lotion is against cockroaches and a foot perspiration remedy. One > drop of the lotion put in a glass of water turns it into a glass of vodka. > Three drops of the same lotion do a glass of Cognac." "It's a desert topping AND a floor wax!" - Saturday Night Live, 1975. (The American version of the above, and one of my favorite comedy bits of all time, because everybody wants something like it, no matter what the field of endevour.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 9:38 ` Dmitry A. Kazakov 2014-04-12 9:55 ` Georg Bauhaus @ 2014-04-12 10:17 ` Nasser M. Abbasi 2014-04-12 10:48 ` Dmitry A. Kazakov 1 sibling, 1 reply; 240+ messages in thread From: Nasser M. Abbasi @ 2014-04-12 10:17 UTC (permalink / raw) On 4/12/2014 4:38 AM, Dmitry A. Kazakov wrote: >> In Julia, the way I understand it, when defining a function >> with some signature, then a compiled instance of this function >> is made for all the possible primitive types (int16, int32, >> real32, real64, etc...) > > Is made by whom? > If you mean in implementation, it is the by the "just-in-time (JIT) compilation, implemented using LLVM" The actual language is designed in MIT. >> and when the program is run, >> the run-time automatically dispatches to the correct matching >> function based on the argument used at time the call is made. > > Really? What is the "correct matching" function of int16/real32? Can I have > real_bounded_interval_64? What would be int16/real_bounded_interval_64? Who > does linear system equation resolution function for int16? > From http://julia.readthedocs.org/en/latest/manual/introduction/ it says "The ability to define function behavior across many combinations of argument types via multiple dispatch" ..... "While the casual programmer need not explicitly use types or multiple dispatch, they are the core unifying features of Julia: functions are defined on different combinations of argument types, and applied by dispatching to the most specific matching definition." It seems to be strongly typed language, but in dynamic sense, (when running the program, one finds their errors) and not at compile time. I am no expert in Julia, I just build it on Linux and played with it a little, since it has syntax that is close to Matlab in some sense. The above link talks more about the design of the language itself. I only mentioned it, since dynamic languages seems to be the trend these days, and this was a good example. > The idea that there exist "primitive" and "non-primitive" types is garbage. > The idea that any operation is applicable to any type is garbage. > >> Those good old fashioned, strong static type checking >> at compile time computer languages, seem like, well, old >> fashioned these days. > > If even members of ARG seem not to believe in merits of strong typing or > whatever typing... > Yes, strong static typing is a good thing. --Nasser ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 10:17 ` Nasser M. Abbasi @ 2014-04-12 10:48 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-12 10:48 UTC (permalink / raw) On Sat, 12 Apr 2014 05:17:42 -0500, Nasser M. Abbasi wrote: > On 4/12/2014 4:38 AM, Dmitry A. Kazakov wrote: > >> Really? What is the "correct matching" function of int16/real32? Can I have >> real_bounded_interval_64? What would be int16/real_bounded_interval_64? Who >> does linear system equation resolution function for int16? > > From http://julia.readthedocs.org/en/latest/manual/introduction/ it says > > "The ability to define function behavior across > many combinations of argument types via multiple dispatch" An ability to define is not a definition. I asked who defines, not if it were possible to define. Though people from MIT should know better not to define natural logarithm for int16... > It seems to be strongly typed language, but > in dynamic sense, (when running the program, one finds > their errors) and not at compile time. This makes the language untyped. Type errors at run-time are bugs or else lack of typing. Weak typing is when at run-time there is possible deviation of behavior, yet no errors. Strong typing is when the deviation of behavior is promoted to statically detected type error. Since semantics is incomputable no language is absolutely strong. But Ada is stronger than C. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-12 8:20 ` Dmitry A. Kazakov 2014-04-12 8:39 ` Nasser M. Abbasi @ 2014-04-13 19:43 ` Niklas Holsti 2014-04-13 21:07 ` Dmitry A. Kazakov 2014-04-15 0:08 ` Randy Brukardt 1 sibling, 2 replies; 240+ messages in thread From: Niklas Holsti @ 2014-04-13 19:43 UTC (permalink / raw) On 14-04-12 11:20 , Dmitry A. Kazakov wrote: > On Sat, 12 Apr 2014 00:04:48 +0200, Niklas Holsti wrote: > >> On 14-04-11 22:43 , Dmitry A. Kazakov wrote: >>> On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote: >>> >>>> On 14-04-10 17:31 , Dmitry A. Kazakov wrote: >>>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: >>>> >>>> [snip] >>>> >>>>>> We don't want "type-specific" implementations of most things -- that's just >>>>>> adding a maintenance headache where one isn't needed. >>>>> >>>>> It is need for >>>>> >>>>> 1. safety (because you statically know that certain specific operation may >>>>> not fail, while class-wide operations can) >>>>> >>>>> 2. efficiency >>>>> >>>>> There is no maintenance overhead whatsoever. Here is the proof. Let you can >>>>> provide a generic implementation (as you suggested), then this >>>>> implementation can be safely inherited. >>>> >>>> If you change a class-wide operation to an inherited (i.e. primitive) >>>> operation, you have to change its dispatching calls to redispatching >>>> calls, if you want the same behaviour as for the class-wide operation. >>> >>> No. I meant that the behavior of class-wide operation was defined = there >>> were no re-dispatch to operations that could be overridden to some >>> unanticipated behavior. >> >> You mean that a class-wide operation should not call any primitive >> operations of its parameters? > > They should, that was not the point. Which was maintainability. A > class-wide operation cannot be more maintainable than a primitive > operation. At least, it would require the level of contract thoroughness > Ada presently does not possess, not even close. > >>> Regarding use cases where re-dispatch comes in question, which certainly >>> exist, >> >> Ah, that is comforting. I thought you were totally against redispatch. > > Yes I am. Re-dispatch is a flawed solution to a real problem. Oh. Then I'm not comforted after all. > I don't deny > existence of the problem. I am against the solution, which is inherently > unsafe and constraining (precludes by-copy semantics). But class-wide operations which contain dispatching calls also preclude by-copy semantics, don't they? Unless you consider a class-wide type as similar to an access type, and pass a reference (pointer) by copy. Which would be a silly meaning of "by-copy". A class-wide operation, in my view, is just like a primitive operation except that (1) (re-)dispatching is implicit and automatic for all calls to primitive operations of the parameter object (because the parameter is a class-wide type) and (2) the operation cannot be overridden. Because of (2) I don't often use class-wide operations, but instead make the operation primitive for the root type and use re-dispatching. (This is why I don't understand your and Randy's abhorrence of re-dispatching -- to me, there is no basic difference between dispatching calls in class-wide operations, and re-dispatching calls in primitive operations.) >>> I think that from the safety and maintenance point of view, the type >>> system should provide means of body composition beyond simple inherit vs. >>> override. >> >> That is certainly an interesting issue. You are thinking of something of >> the same kind as the "inner" of Simula? > > Yes, but it looks too low-level and hackish to me. I agree, for the "inner" thing itself. Some language constructs in the same area (composition of bodies along the inheritance axis) could be useful, but I don't now see the problems to be solved by these constructs, because re-dispatching works well enough for me. > The concept should somehow play together with the notion of polymorphic > operation defined on the class (set of types). Between these two ends: > independent bodies of a primitive operation and single body of a class-wide > operation, there lies a whole spectrum of unexplored possibilities. I feel that my use of re-dispatching gives me something like that. And I don't see the problems in re-dispatching that you and Randy worry about. >> In my own code, the primitive operations of a type are typically layered >> into levels: higher-level operations and lower-level ones. An overriding >> higher-level primitive operation is typically implemented by calling >> (with redispatch) lower-level primitive operations of the parameter >> object. The *same* (i.e. overridden) operation of the parent type is >> usually not called, nor does a primitive operation of a parent type call >> the same primitive operation from the actual derived type; only >> operations from lower layers are called. > > Yes, this is the way I implement it too. The difference is that I try to > keep "higher-level" operations class-wide. I have a few class-wide ops, but not many. They are for sure the higher-level, if not highest-level ops. > Then I try to maintain the "no > abstraction inversion" rule, i.e. never call a "higher-level" operation > from a "lower-level" one. Yes, same here. > Note that when "higher-level" operations are made class-wide, there is also > a formalized separation of two, as they act on different types. I think I have some classes with more than two levels of operations, so this separation would not work fully there. >>> We know, for example, that constructors (initialize) and >>> destructors (finalize) require other means of composition. More elaborated >>> composition tools should eliminate re-dispatch (and most class-wide >>> operations) => give safety and maintainability. >> >> Maybe... suggest something and we'll see. > > It is useless to suggest anything, as you know. Suggestions have to be very well motivated, as befits Ada's goals of long-term stability and portability. > And, I am not a language > designer anyway. I am a programmer. As a programmer, from my experience > with Ada, I tell the language designers that they got it all wrong since > Ada 2005. I don't want yet another dynamically typed or functional > language. I need a language for software engineering. More static checks, > more means to make static checks possible. The whole language should > revolute around helping restructuring my programs in order to support > static checks. No Constraint_Error to me, please! That's a good goal, but I don't think it should be the only goal for Ada. Ada's problem and challenge is that it very ambitiously aims to combine high-level, expressive, and therefore somewhat dynamic language features with predictable, efficient execution as required for critical embedded systems. I think that it will be more and more difficult to extend and evolve Ada in both directions (high-level, expressive, dynamic; vs. low-level, predictable, static) without in practice dividing the language into two: a "high-Ada" and a "low-Ada", with some compilers targeting the high and others the low. A bit of that can already be seen now, with some compilers supporting only some Ada standards and some limited profiles such as Ravenscar. This division may be the only way to support further Ada-style programming at both high and low levels. It may not be too bad a thing, as long as there is a decent amount of overlap (common middle ground) between high-Ada and low-Ada. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-13 19:43 ` Niklas Holsti @ 2014-04-13 21:07 ` Dmitry A. Kazakov 2014-04-18 19:10 ` Niklas Holsti 2014-04-15 0:08 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-13 21:07 UTC (permalink / raw) On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: > On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >> I don't deny >> existence of the problem. I am against the solution, which is inherently >> unsafe and constraining (precludes by-copy semantics). > > But class-wide operations which contain dispatching calls also preclude > by-copy semantics, don't they? Not at all. There is no problem for a class-wide operation to act on by-copy types. A by-copy class-wide object is a tuple (tag, type-specific value). Upon dispatch the value is passed copy-in/copy-out to the type specific operation. > A class-wide operation, in my view, is just like a primitive operation > except that (1) (re-)dispatching is implicit and automatic for all calls > to primitive operations of the parameter object (because the parameter > is a class-wide type) and (2) the operation cannot be overridden. There is no re-dispatching in a class-wide operation. It is defined on class-wide objects, so it simply neither dispatch nor re-dispatch. > (This is why I don't understand your and Randy's abhorrence of > re-dispatching -- to me, there is no basic difference between > dispatching calls in class-wide operations, and re-dispatching calls in > primitive operations.) The difference is in types involved. A body of a primitive operation is defined on a particular specific type. A re-dispatch within the body breaks this type contract by calling an operation defined on *another* type. This is an untyped behavior. >> The concept should somehow play together with the notion of polymorphic >> operation defined on the class (set of types). Between these two ends: >> independent bodies of a primitive operation and single body of a class-wide >> operation, there lies a whole spectrum of unexplored possibilities. > > I feel that my use of re-dispatching gives me something like that. And I > don't see the problems in re-dispatching that you and Randy worry about. Untyped programming style has known problems. The point is not that an improperly typed program could not expose correct behavior. Of course it can, "it worked to me" is never an argument. One could design a working program directly in machine code. That does not imply that this would be a good idea. >> Then I try to maintain the "no >> abstraction inversion" rule, i.e. never call a "higher-level" operation >> from a "lower-level" one. > > Yes, same here. But re-dispatch would be exactly this kind of inversion. Remember, no higher-level operation is primitive, since I make all higher-level operations class-wide or else self-contained. >> And, I am not a language >> designer anyway. I am a programmer. As a programmer, from my experience >> with Ada, I tell the language designers that they got it all wrong since >> Ada 2005. I don't want yet another dynamically typed or functional >> language. I need a language for software engineering. More static checks, >> more means to make static checks possible. The whole language should >> revolute around helping restructuring my programs in order to support >> static checks. No Constraint_Error to me, please! > > That's a good goal, but I don't think it should be the only goal for Ada. > > Ada's problem and challenge is that it very ambitiously aims to combine > high-level, expressive, and therefore somewhat dynamic language features > with predictable, efficient execution as required for critical embedded > systems. It depends on your understanding of dynamic features. To me it is all OK to have dynamic features (AKA generic programming) under certain conditions. One is that the language remains typed. Ada 95 solved that by introducing a separate type for class-wide objects. Another is that generalized contracts remain statically checked. Again, it is partially so, because Ada 95 guaranteed that dispatch never fail, an operation is either inherited or else requires overriding. There is no gaps in the dispatching table (except for missing MD). But Ada 83 missed that goal when introduced Constraint_Error for discriminated types, array bounds, overflows without means to check exception contracts statically. Ada 2005/2012 broke things even further by adding dynamic constraints, predicates etc. A related requirement is that whatever categories the language introduces they must be spelt as objects, types, operations. The language must be well-structured. Ada 85/95 was, though it had no so much typed things, like ranges and attributes. Ada 2005/2012 ruined much of that. > I think that it will be more and more difficult to extend and evolve Ada > in both directions (high-level, expressive, dynamic; vs. low-level, > predictable, static) without in practice dividing the language into two: > a "high-Ada" and a "low-Ada", with some compilers targeting the high and > others the low. I don't believe in this separation. To me dynamic vs. static is not high vs. low. In first place, there is no fully dynamic system. For any given system observed as dynamic, you can always lump together involved objects, call the result a type and things become static again. So, the requirement is that you can have your dynamic things as much you want, but you MUST introduce an explicit named type for the resulting set of objects. Just as Ada 95 did with T'Class. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-13 21:07 ` Dmitry A. Kazakov @ 2014-04-18 19:10 ` Niklas Holsti 2014-04-18 21:18 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-18 19:10 UTC (permalink / raw) (Apologies for a delayed reply.) On 14-04-14 00:07 , Dmitry A. Kazakov wrote: > On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: > >> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: > >>> I don't deny >>> existence of the problem. I am against the solution, which is inherently >>> unsafe and constraining (precludes by-copy semantics). >> >> But class-wide operations which contain dispatching calls also preclude >> by-copy semantics, don't they? > > Not at all. There is no problem for a class-wide operation to act on > by-copy types. > > A by-copy class-wide object is a tuple (tag, type-specific value). Upon > dispatch the value is passed copy-in/copy-out to the type specific > operation. OK, but from the implementation point of view, that form of by-copy passing could be used for all operations of a tagged class, whether class-wide or primitive, with or without redispatching. So it is not evident why you said earlier that redispatching prevents by-copy semantics. If I may guess, your reasoning is perhaps that if we have a tagged type T, and a derived type TT with added components, and a primitive operation Foo on T which is inherited by TT and uses by-copy semantics, then calling Foo on a TT object X should really copy only the T part of X, and therefore Foo could not execute a redispatching call to some operation Bar on T which is overridden for TT, because the conversion T'Class(X) in the redispatching call would have no way to (re)generate the TT components of X, because they were not copied. I think that argument is wrong from the formal point of view, because when Foo is inherited from T to TT, the inherited operation formally acts on TT, therefore the by-copy passing would copy all of X, including the TT components. Another case that comes to mind is an explicit call to the original (not inherited) form of Foo, using a call with a conversion of the form Foo(T(X)) where X is of type TT. Here, there is more reason to feel that by-copy passing should copy only the T part of X (or, rather, the conversion should return only the T part of X), and then redispatching from Foo would indeed be impossible. But if T(X) is seen simply as a view conversion, not a value conversion, then X could still be passed by-copy using your (tag, type-specific value) form. (Of course this is all irrelevant to current Ada, where tagged types are by-reference and T(X) in the call is a view conversion.) >> A class-wide operation, in my view, is just like a primitive operation >> except that (1) (re-)dispatching is implicit and automatic for all calls >> to primitive operations of the parameter object (because the parameter >> is a class-wide type) and (2) the operation cannot be overridden. > > There is no re-dispatching in a class-wide operation. It is defined on > class-wide objects, so it simply neither dispatch nor re-dispatch. Huh? If a class-wide operation calls a primitive operation, using a controlling parameter of the class-wide type, that is certainly a dispatching call. >> (This is why I don't understand your and Randy's abhorrence of >> re-dispatching -- to me, there is no basic difference between >> dispatching calls in class-wide operations, and re-dispatching calls in >> primitive operations.) > > The difference is in types involved. A body of a primitive operation is > defined on a particular specific type. A re-dispatch within the body > breaks this type contract by calling an operation defined on *another* > type. This is an untyped behavior. Not in my opinion, of course. In any primitive operation, I consider a parameter of type T to be just a T-view of an object which may be of type T or of a derived type. This matches how Ada is now defined and implemented; your statement reflects another language, or an Ada subset. I'll stop arguing about redispatching for now. Our views are different. The only reason I entered this discussion about redispatching is that I am upset when someone (often you, Dmitry) makes the blank statement that one should "never redispatch", as if redispatching would lead to erroneous execution and program crashes as surely as reading an uninitialized variable might. Redispatching is well defined in Ada and does not cause erroneous execution or bounded errors. The only arguments against redispatching either come from a more constrained idea of types (effectively an Ada subset) or from a fear of increased dynamic choice of callees, in particular fear of choosing an inappropriate operation of a different type. Both arguments concern design and coding styles and their impact on the likelihood of design or coding errors, not of correct or erroneous execution. My objective has only been to make this clear to people who might be misled by the blanket condemnations of redispatching. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-18 19:10 ` Niklas Holsti @ 2014-04-18 21:18 ` Dmitry A. Kazakov 2014-04-19 7:35 ` Niklas Holsti 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-18 21:18 UTC (permalink / raw) On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: > (Apologies for a delayed reply.) > > On 14-04-14 00:07 , Dmitry A. Kazakov wrote: >> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: >> >>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >> >>>> I don't deny >>>> existence of the problem. I am against the solution, which is inherently >>>> unsafe and constraining (precludes by-copy semantics). >>> >>> But class-wide operations which contain dispatching calls also preclude >>> by-copy semantics, don't they? >> >> Not at all. There is no problem for a class-wide operation to act on >> by-copy types. >> >> A by-copy class-wide object is a tuple (tag, type-specific value). Upon >> dispatch the value is passed copy-in/copy-out to the type specific >> operation. > > OK, but from the implementation point of view, that form of by-copy > passing could be used for all operations of a tagged class, whether > class-wide or primitive, with or without redispatching. So it is not > evident why you said earlier that redispatching prevents by-copy semantics. Re-dispatching presumes the same object. For by-copy objects a conversion of T to T'Class would produce a new object on which dispatch would happen. It would make no sense to call this re-dispatch. But more importantly is that "re-dispatch" will always dispatch to the operations of the manifested type. I will consider this in details below. > If I may guess, your reasoning is perhaps that if we have a tagged type > T, and a derived type TT with added components, and a primitive > operation Foo on T which is inherited by TT and uses by-copy semantics, > then calling Foo on a TT object X should really copy only the T part of > X, and therefore Foo could not execute a redispatching call to some > operation Bar on T which is overridden for TT, because the conversion > T'Class(X) in the redispatching call would have no way to (re)generate > the TT components of X, because they were not copied. > > I think that argument is wrong from the formal point of view, because > when Foo is inherited from T to TT, the inherited operation formally > acts on TT, therefore the by-copy passing would copy all of X, including > the TT components. Consider this: type T is non-tagged null record; procedure Foo (X : T); procedure Bar (X : T); type TT is new T with record I : Integer; end record; overriding procedure Bar (X : T); procedure Foo (X : T) is begin T'Class (X).Bar; end Foo; O : T'Class := T'(null record); O.Foo; The representation of O is (T'Tag, null record). When it dispatches on O to Foo, T'Tag is stripped away and null record is passed to T's Foo. Within Foo X has the representation null record, *always*. When X is converted in Foo to T'Class, the result is (T'Tag, null record), because the type of X is declared as T. When it dispatches on the result Bar, it is T's Bar that is called, always, because the tag is T'Tag. As you see, there is no re-dispatch possible with by-copy semantics. Re-dispatch requires: 1. by-reference semantics (no new objects) 2. extension (parent representations stored within derived objects) 3. embedded tags (class-wide and type-specific representations to be same) > Another case that comes to mind is an explicit call to the original (not > inherited) form of Foo, using a call with a conversion of the form > Foo(T(X)) where X is of type TT. Here, there is more reason to feel that > by-copy passing should copy only the T part of X (or, rather, the > conversion should return only the T part of X), and then redispatching > from Foo would indeed be impossible. But if T(X) is seen simply as a > view conversion, not a value conversion, then X could still be passed > by-copy using your (tag, type-specific value) form. It is the tag in the pair (Tag, Value) which determine the type of Value. You cannot use T'Tag with TT value, that is inconsistent. >>> A class-wide operation, in my view, is just like a primitive operation >>> except that (1) (re-)dispatching is implicit and automatic for all calls >>> to primitive operations of the parameter object (because the parameter >>> is a class-wide type) and (2) the operation cannot be overridden. >> >> There is no re-dispatching in a class-wide operation. It is defined on >> class-wide objects, so it simply neither dispatch nor re-dispatch. > > Huh? If a class-wide operation calls a primitive operation, using a > controlling parameter of the class-wide type, that is certainly a > dispatching call. Yes, but this is a call to some different operation. I thought you were talking about the class-wide operation itself. This operation does not [re-]dispatch. What happens in its body is a different issue. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-18 21:18 ` Dmitry A. Kazakov @ 2014-04-19 7:35 ` Niklas Holsti 2014-04-19 8:19 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-19 7:35 UTC (permalink / raw) On 14-04-19 00:18 , Dmitry A. Kazakov wrote: > On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: > >> (Apologies for a delayed reply.) >> >> On 14-04-14 00:07 , Dmitry A. Kazakov wrote: >>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: >>> >>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >>> >>>>> I don't deny >>>>> existence of the problem. I am against the solution, which is inherently >>>>> unsafe and constraining (precludes by-copy semantics). >>>> >>>> But class-wide operations which contain dispatching calls also preclude >>>> by-copy semantics, don't they? >>> >>> Not at all. There is no problem for a class-wide operation to act on >>> by-copy types. >>> >>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon >>> dispatch the value is passed copy-in/copy-out to the type specific >>> operation. >> >> OK, but from the implementation point of view, that form of by-copy >> passing could be used for all operations of a tagged class, whether >> class-wide or primitive, with or without redispatching. So it is not >> evident why you said earlier that redispatching prevents by-copy semantics. > > Re-dispatching presumes the same object. No it doesn't. Why should it? Redispatch merely selects an operation based on the actual type (tag) of the parameter value. Whether the operation acts on the same object or on a copy is a separate question. > For by-copy objects a conversion > of T to T'Class would produce a new object on which dispatch would happen. > It would make no sense to call this re-dispatch. In earlier discussion threads, you have criticized redispatching as logically redundant because it inspects the object's tag twice, making two dispatching decisions where one should be enough. Here, even if T'Class makes a new object, the new object has the same tag value, and a dispatching call on it makes a new decision using the same tag value as was used to dispatch to the calling operation. I don't see why two successive dispatching decisions on the same tag value should not be called redispatching. It is irrelevant whether the tag value is copied between the decisions. > But more importantly is that "re-dispatch" will always dispatch to the > operations of the manifested type. I will consider this in details below. > > ... Consider this: > > type T is non-tagged null record; Are you talking about Ada here? Or about the ideal Dmitry-language? > procedure Foo (X : T); > procedure Bar (X : T); > > type TT is new T with record > I : Integer; > end record; > overriding procedure Bar (X : T); > > procedure Foo (X : T) is > begin > T'Class (X).Bar; Ah, you are taking the class of a non-tagged type. So this is the Dmitry-language, not Ada, nor a by-copy variant of Ada. > end Foo; > > O : T'Class := T'(null record); > > O.Foo; > > The representation of O is (T'Tag, null record). When it dispatches on O to > Foo, T'Tag is stripped away and null record is passed to T's Foo. Within > Foo X has the representation null record, *always*. When X is converted in > Foo to T'Class, the result is (T'Tag, null record), because the type of X > is declared as T. When it dispatches on the result Bar, it is T's Bar that > is called, always, because the tag is T'Tag. > > As you see, there is no re-dispatch possible with by-copy semantics. You are presenting a particular form of by-copy, in which the tag (and no doubt all extension components) are removed when the value is copied in a call to a non-class-wide operation. Obviously redispatch is not possible then. But that is not the only possible way of passing parameters by copy. >>>> A class-wide operation, in my view, is just like a primitive operation >>>> except that (1) (re-)dispatching is implicit and automatic for all calls >>>> to primitive operations of the parameter object (because the parameter >>>> is a class-wide type) and (2) the operation cannot be overridden. >>> >>> There is no re-dispatching in a class-wide operation. It is defined on >>> class-wide objects, so it simply neither dispatch nor re-dispatch. >> >> Huh? If a class-wide operation calls a primitive operation, using a >> controlling parameter of the class-wide type, that is certainly a >> dispatching call. > > Yes, but this is a call to some different operation. I thought you were > talking about the class-wide operation itself. This operation does not > [re-]dispatch. What happens in its body is a different issue. Ok, a misunderstanding between us, we do agree that there is no dispatching when a class-wide operation is called. But a side issue. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 7:35 ` Niklas Holsti @ 2014-04-19 8:19 ` Dmitry A. Kazakov 2014-04-19 8:39 ` Dmitry A. Kazakov 2014-04-19 9:05 ` Niklas Holsti 0 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-19 8:19 UTC (permalink / raw) On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote: > On 14-04-19 00:18 , Dmitry A. Kazakov wrote: >> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: >> >>> (Apologies for a delayed reply.) >>> >>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote: >>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: >>>> >>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >>>> >>>>>> I don't deny >>>>>> existence of the problem. I am against the solution, which is inherently >>>>>> unsafe and constraining (precludes by-copy semantics). >>>>> >>>>> But class-wide operations which contain dispatching calls also preclude >>>>> by-copy semantics, don't they? >>>> >>>> Not at all. There is no problem for a class-wide operation to act on >>>> by-copy types. >>>> >>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon >>>> dispatch the value is passed copy-in/copy-out to the type specific >>>> operation. >>> >>> OK, but from the implementation point of view, that form of by-copy >>> passing could be used for all operations of a tagged class, whether >>> class-wide or primitive, with or without redispatching. So it is not >>> evident why you said earlier that redispatching prevents by-copy semantics. >> >> Re-dispatching presumes the same object. > > No it doesn't. Why should it? Redispatch merely selects an operation > based on the actual type (tag) of the parameter value. This is called dispatch. > Whether the > operation acts on the same object or on a copy is a separate question. "Re-" presumes that dispatch happens again. What is in common to these two instances of dispatch what makes it re-dispatch? It is 1) the same polymorphic operation and 2) the same object. Take either away and it is not re-dispatch anymore: 1. Different operations: X.Foo; X.Bar; -- This is not re-dispatch! 2. Different objects: X.Foo; Y.Foo; -- This is not re-dispatch! >> For by-copy objects a conversion >> of T to T'Class would produce a new object on which dispatch would happen. >> It would make no sense to call this re-dispatch. > > I don't see why two > successive dispatching decisions on the same tag value should not be > called redispatching. It is irrelevant whether the tag value is copied > between the decisions. See above. >> But more importantly is that "re-dispatch" will always dispatch to the >> operations of the manifested type. I will consider this in details below. >> >> ... Consider this: >> >> type T is non-tagged null record; > > Are you talking about Ada here? We were talking about implementation dispatch and re-dispatch for by-copy types. Remember? If yes, that I am also pretty sure you know that this not Ada, so far. >> procedure Foo (X : T); >> procedure Bar (X : T); >> >> type TT is new T with record >> I : Integer; >> end record; >> overriding procedure Bar (X : T); >> >> procedure Foo (X : T) is >> begin >> T'Class (X).Bar; > > Ah, you are taking the class of a non-tagged type. So this is the > Dmitry-language, not Ada, nor a by-copy variant of Ada. There is no such thing as by-copy variant of Ada. >> end Foo; >> >> O : T'Class := T'(null record); >> >> O.Foo; >> >> The representation of O is (T'Tag, null record). When it dispatches on O to >> Foo, T'Tag is stripped away and null record is passed to T's Foo. Within >> Foo X has the representation null record, *always*. When X is converted in >> Foo to T'Class, the result is (T'Tag, null record), because the type of X >> is declared as T. When it dispatches on the result Bar, it is T's Bar that >> is called, always, because the tag is T'Tag. >> >> As you see, there is no re-dispatch possible with by-copy semantics. > > You are presenting a particular form of by-copy, in which the tag (and > no doubt all extension components) are removed when the value is copied > in a call to a non-class-wide operation. Obviously redispatch is not > possible then. But that is not the only possible way of passing > parameters by copy. I gave a use case. If you think that there could be another way to implement it, we could consider it. In particular, the case, which is especially interesting and important for by-copy types, when the derived type has a representation completely different from the base. For instance: type Wide_Wide_Character is ...; -- Full Unicode function Is_Digit (X : Wide_Wide_Character) return Boolean; function Is_Letter (X : Wide_Wide_Character) return Boolean; function Is_Alphanumeric (X : Wide_Wide_Character) return Boolean; type Character is new Wide_Wide_Character without parent's mess ...; overriding function Is_Digit (X : Character) return Boolean; overriding function Is_Letter (X : Character) return Boolean; Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 8:19 ` Dmitry A. Kazakov @ 2014-04-19 8:39 ` Dmitry A. Kazakov 2014-04-19 9:08 ` Niklas Holsti 2014-04-19 9:05 ` Niklas Holsti 1 sibling, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-19 8:39 UTC (permalink / raw) On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote: > "Re-" presumes that dispatch happens again. What is in common to these two > instances of dispatch what makes it re-dispatch? It is 1) the same > polymorphic operation and 2) the same object. Take either away and it is > not re-dispatch anymore: > > 1. Different operations: > > X.Foo; > X.Bar; -- This is not re-dispatch! > > 2. Different objects: > > X.Foo; > Y.Foo; -- This is not re-dispatch! After some consideration, I take the position 1 back. Operation can be different. But the object must be same. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 8:39 ` Dmitry A. Kazakov @ 2014-04-19 9:08 ` Niklas Holsti 2014-04-19 10:06 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-19 9:08 UTC (permalink / raw) On 14-04-19 11:39 , Dmitry A. Kazakov wrote: > On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote: > >> "Re-" presumes that dispatch happens again. What is in common to these two >> instances of dispatch what makes it re-dispatch? It is 1) the same >> polymorphic operation and 2) the same object. Take either away and it is >> not re-dispatch anymore: >> >> 1. Different operations: >> >> X.Foo; >> X.Bar; -- This is not re-dispatch! >> >> 2. Different objects: >> >> X.Foo; >> Y.Foo; -- This is not re-dispatch! > > After some consideration, I take the position 1 back. Operation can be > different. But the object must be same. If we are talking about by-copy types, then whether X and Y are the "same object" is fuzzy. Is a copy the same object as the original? In some logical sense it is, in a physical sense it isn't. Which do you mean? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 9:08 ` Niklas Holsti @ 2014-04-19 10:06 ` Dmitry A. Kazakov 2014-04-19 13:53 ` Niklas Holsti 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-19 10:06 UTC (permalink / raw) On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote: > On 14-04-19 11:39 , Dmitry A. Kazakov wrote: >> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote: >> >>> "Re-" presumes that dispatch happens again. What is in common to these two >>> instances of dispatch what makes it re-dispatch? It is 1) the same >>> polymorphic operation and 2) the same object. Take either away and it is >>> not re-dispatch anymore: >>> >>> 1. Different operations: >>> >>> X.Foo; >>> X.Bar; -- This is not re-dispatch! >>> >>> 2. Different objects: >>> >>> X.Foo; >>> Y.Foo; -- This is not re-dispatch! >> >> After some consideration, I take the position 1 back. Operation can be >> different. But the object must be same. > > If we are talking about by-copy types, then whether X and Y are the > "same object" is fuzzy. Is a copy the same object as the original? A copy is another object. > In some logical sense it is, in a physical sense it isn't. The reverse. It might be logically same, when "=" yields true and physically different. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 10:06 ` Dmitry A. Kazakov @ 2014-04-19 13:53 ` Niklas Holsti 2014-04-19 14:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-19 13:53 UTC (permalink / raw) On 14-04-19 13:06 , Dmitry A. Kazakov wrote: > On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote: > >> On 14-04-19 11:39 , Dmitry A. Kazakov wrote: >>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote: >>> >>>> "Re-" presumes that dispatch happens again. What is in common to these two >>>> instances of dispatch what makes it re-dispatch? It is 1) the same >>>> polymorphic operation and 2) the same object. Take either away and it is >>>> not re-dispatch anymore: >>>> >>>> 1. Different operations: >>>> >>>> X.Foo; >>>> X.Bar; -- This is not re-dispatch! >>>> >>>> 2. Different objects: >>>> >>>> X.Foo; >>>> Y.Foo; -- This is not re-dispatch! >>> >>> After some consideration, I take the position 1 back. Operation can be >>> different. But the object must be same. >> >> If we are talking about by-copy types, then whether X and Y are the >> "same object" is fuzzy. Is a copy the same object as the original? > > A copy is another object. Then (by your definitions) redispatching is never possible based on by-copy parameters, because (in your definition) redispatching only occurs if the first and second dispatching call use the same object, but the pass-by-copy in the first dispatching call (in your view) creates a new object which is then used in the second dispatching call. That is a consistent view (good for you) but it disagrees with my memory of your earlier arguments against redispatching, which were based more on the logical redundancy of two successive dispatching calls on the same tag. >> In some logical sense it is, in a physical sense it isn't. > > The reverse. It might be logically same, when "=" yields true and > physically different. That's what I said, logically the same, physically not. You misread my last sentence. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 13:53 ` Niklas Holsti @ 2014-04-19 14:21 ` Dmitry A. Kazakov 2014-04-19 18:28 ` Niklas Holsti 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-19 14:21 UTC (permalink / raw) On Sat, 19 Apr 2014 16:53:47 +0300, Niklas Holsti wrote: > On 14-04-19 13:06 , Dmitry A. Kazakov wrote: >> On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote: >> >>> On 14-04-19 11:39 , Dmitry A. Kazakov wrote: >>>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote: >>>> >>>>> "Re-" presumes that dispatch happens again. What is in common to these two >>>>> instances of dispatch what makes it re-dispatch? It is 1) the same >>>>> polymorphic operation and 2) the same object. Take either away and it is >>>>> not re-dispatch anymore: >>>>> >>>>> 1. Different operations: >>>>> >>>>> X.Foo; >>>>> X.Bar; -- This is not re-dispatch! >>>>> >>>>> 2. Different objects: >>>>> >>>>> X.Foo; >>>>> Y.Foo; -- This is not re-dispatch! >>>> >>>> After some consideration, I take the position 1 back. Operation can be >>>> different. But the object must be same. >>> >>> If we are talking about by-copy types, then whether X and Y are the >>> "same object" is fuzzy. Is a copy the same object as the original? >> >> A copy is another object. > > Then (by your definitions) redispatching is never possible based on > by-copy parameters, because (in your definition) redispatching only > occurs if the first and second dispatching call use the same object, but > the pass-by-copy in the first dispatching call (in your view) creates a > new object which is then used in the second dispatching call. > > That is a consistent view (good for you) but it disagrees with my memory > of your earlier arguments against redispatching, which were based more > on the logical redundancy of two successive dispatching calls on the > same tag. Why does it disagree? There is no contradiction between A) re-dispatch is impossible with by-copy semantics, and B) when re-dispatch is possible then from the SW design POV, it is redundant, abstraction inversion, weak typing, inefficient, LSP violation, maintenance headache, you name it. Arguably, if re-dispatch is impossible for by-copy types when it should be made unavailable for by-reference types as well. Finally, it was not necessary to introduce view conversions in Ada for the purpose of re-dispatch, because the desired effect were achievable through the Rosen's trick: type T is ... Self : not null access T'Class := T'Unchecked_Access; end record; procedure Foo (X : T) is begin X.Self.Bar; -- I know what I am doing end Foo; Using Self is more visible as dangerous than view conversion, IMO. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 14:21 ` Dmitry A. Kazakov @ 2014-04-19 18:28 ` Niklas Holsti 0 siblings, 0 replies; 240+ messages in thread From: Niklas Holsti @ 2014-04-19 18:28 UTC (permalink / raw) On 14-04-19 17:21 , Dmitry A. Kazakov wrote: > On Sat, 19 Apr 2014 16:53:47 +0300, Niklas Holsti wrote: > >> On 14-04-19 13:06 , Dmitry A. Kazakov wrote: >>> On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote: >>> >>>> On 14-04-19 11:39 , Dmitry A. Kazakov wrote: >>>>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote: >>>>> >>>>>> "Re-" presumes that dispatch happens again. What is in common to these two >>>>>> instances of dispatch what makes it re-dispatch? It is 1) the same >>>>>> polymorphic operation and 2) the same object. Take either away and it is >>>>>> not re-dispatch anymore: >>>>>> >>>>>> 1. Different operations: >>>>>> >>>>>> X.Foo; >>>>>> X.Bar; -- This is not re-dispatch! >>>>>> >>>>>> 2. Different objects: >>>>>> >>>>>> X.Foo; >>>>>> Y.Foo; -- This is not re-dispatch! >>>>> >>>>> After some consideration, I take the position 1 back. Operation can be >>>>> different. But the object must be same. >>>> >>>> If we are talking about by-copy types, then whether X and Y are the >>>> "same object" is fuzzy. Is a copy the same object as the original? >>> >>> A copy is another object. >> >> Then (by your definitions) redispatching is never possible based on >> by-copy parameters, because (in your definition) redispatching only >> occurs if the first and second dispatching call use the same object, but >> the pass-by-copy in the first dispatching call (in your view) creates a >> new object which is then used in the second dispatching call. >> >> That is a consistent view (good for you) but it disagrees with my memory >> of your earlier arguments against redispatching, which were based more >> on the logical redundancy of two successive dispatching calls on the >> same tag. > > Why does it disagree? You are right, it doesn't. I was still thinking about my first conception of your by-copy method, where the tag would also be copied, which would allow redispatch. Sorry. > Arguably, if re-dispatch is impossible for by-copy types when it should be > made unavailable for by-reference types as well. As has been made amply clear, I don't share that opinion. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 8:19 ` Dmitry A. Kazakov 2014-04-19 8:39 ` Dmitry A. Kazakov @ 2014-04-19 9:05 ` Niklas Holsti 2014-04-19 10:18 ` Dmitry A. Kazakov 1 sibling, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-19 9:05 UTC (permalink / raw) On 14-04-19 11:19 , Dmitry A. Kazakov wrote: > On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote: > >> On 14-04-19 00:18 , Dmitry A. Kazakov wrote: >>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: >>> >>>> (Apologies for a delayed reply.) >>>> >>>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote: >>>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: >>>>> >>>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >>>>> >>>>>>> I don't deny >>>>>>> existence of the problem. I am against the solution, which is inherently >>>>>>> unsafe and constraining (precludes by-copy semantics). >>>>>> >>>>>> But class-wide operations which contain dispatching calls also preclude >>>>>> by-copy semantics, don't they? >>>>> >>>>> Not at all. There is no problem for a class-wide operation to act on >>>>> by-copy types. >>>>> >>>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon >>>>> dispatch the value is passed copy-in/copy-out to the type specific >>>>> operation. I think I misunderstood you here. I now think you meant that only the type-specific value (the second component of the tuple) is passed copy-in/copy-out (but the tag is not passed). I misunderstood and thought that you meant passing the entire tuple value (tag, type-specific value) by copy-in/out. >>>> OK, but from the implementation point of view, that form of by-copy >>>> passing could be used for all operations of a tagged class, whether >>>> class-wide or primitive, with or without redispatching. If the tag is not passed (as I now understood you meant), then redispatch is not possible, I agree. >>> Re-dispatching presumes the same object. >> >> No it doesn't. Why should it? Redispatch merely selects an operation >> based on the actual type (tag) of the parameter value. > > This is called dispatch. Yes, redispatch is a form of dispatch. >> Whether the >> operation acts on the same object or on a copy is a separate question. > > "Re-" presumes that dispatch happens again. What is in common to these two > instances of dispatch what makes it re-dispatch? The fact that the calling operation has been reached by a dispatch on the parameter's tag, and now a new dispatching call is made (dynamically within the first dispatching call) based on this same tag. This feature -- a first choice based on the tag, with a nested second choice based on the same tag -- was a feature of redispatching that you criticized in earlier discussions. > It is 1) the same > polymorphic operation and 2) the same object. Take either away and it is > not re-dispatch anymore: > > 1. Different operations: > > X.Foo; > X.Bar; -- This is not re-dispatch! Agreed, because the call to X.Bar does not occur in the body of Foo, so it does not occur dynamically within the first dispatching call. > 2. Different objects: > > X.Foo; > Y.Foo; -- This is not re-dispatch! Of course not. > In particular, the case, which is especially interesting and important for > by-copy types, when the derived type has a representation completely > different from the base. For instance: > > type Wide_Wide_Character is ...; -- Full Unicode > function Is_Digit (X : Wide_Wide_Character) return Boolean; > function Is_Letter (X : Wide_Wide_Character) return Boolean; > function Is_Alphanumeric (X : Wide_Wide_Character) return Boolean; > > type Character is new Wide_Wide_Character without parent's mess ...; > overriding function Is_Digit (X : Character) return Boolean; > overriding function Is_Letter (X : Character) return Boolean; > > Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter. Could you complete your thought here? I don't see a claim or a question yet. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 9:05 ` Niklas Holsti @ 2014-04-19 10:18 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-19 10:18 UTC (permalink / raw) On Sat, 19 Apr 2014 12:05:09 +0300, Niklas Holsti wrote: > On 14-04-19 11:19 , Dmitry A. Kazakov wrote: >> On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote: >> >>> On 14-04-19 00:18 , Dmitry A. Kazakov wrote: >>>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: >>>> >>>>> (Apologies for a delayed reply.) >>>>> >>>>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote: >>>>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: >>>>>> >>>>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >>>>>> >>>>>>>> I don't deny >>>>>>>> existence of the problem. I am against the solution, which is inherently >>>>>>>> unsafe and constraining (precludes by-copy semantics). >>>>>>> >>>>>>> But class-wide operations which contain dispatching calls also preclude >>>>>>> by-copy semantics, don't they? >>>>>> >>>>>> Not at all. There is no problem for a class-wide operation to act on >>>>>> by-copy types. >>>>>> >>>>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon >>>>>> dispatch the value is passed copy-in/copy-out to the type specific >>>>>> operation. > > I think I misunderstood you here. I now think you meant that only the > type-specific value (the second component of the tuple) is passed > copy-in/copy-out (but the tag is not passed). I misunderstood and > thought that you meant passing the entire tuple value (tag, > type-specific value) by copy-in/out. Yes >>> Whether the >>> operation acts on the same object or on a copy is a separate question. >> >> "Re-" presumes that dispatch happens again. What is in common to these two >> instances of dispatch what makes it re-dispatch? > > The fact that the calling operation has been reached by a dispatch on > the parameter's tag, and now a new dispatching call is made (dynamically > within the first dispatching call) based on this same tag. But some other object might also have this tag. E.g. when generic dispatching constructor is used. In my view, the tag is same because the object is. Since tagged types magically make the tag accessible and preserved, you could use it to construct a class-wide object and then dispatch again. As a side note, observe that preserving the tag is not a requirement, semantically. For example, upon object's initialization (finalization), the object's tag ascends (descends) the inheritance path, e.g. in C++. >> In particular, the case, which is especially interesting and important for >> by-copy types, when the derived type has a representation completely >> different from the base. For instance: >> >> type Wide_Wide_Character is ...; -- Full Unicode >> function Is_Digit (X : Wide_Wide_Character) return Boolean; >> function Is_Letter (X : Wide_Wide_Character) return Boolean; >> function Is_Alphanumeric (X : Wide_Wide_Character) return Boolean; >> >> type Character is new Wide_Wide_Character without parent's mess ...; >> overriding function Is_Digit (X : Character) return Boolean; >> overriding function Is_Letter (X : Character) return Boolean; >> >> Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter. > > Could you complete your thought here? I don't see a claim or a question yet. The claim is that there seems no other way to implement Wide_Wide_Character'Class than as I described earlier. The representation of a class-wide object containing, say, ROMAN_DENARIUS_SIGN will be (Wide_Wide_Character'Tag, ROMAN_DENARIUS_SIGN) The representation of a class-wide object containing character 'A' will be (Character'Tag, 'A') Note, this is different from: (Wide_Wide_Character'Tag, LATIN_CAPITAL_LETTER_A) Though both would refer to the same Unicode code point. When you dispatch on (Character'Tag, 'A') to Is_Alphanumeric, the parameter of Is_Alphanumeric will be 'A'. You could not re-dispatch from there to anything but to character's operations. Note, that if Is_Alphanumeric were inherited, rather than overridden, as in the example above, the original body would be composed with a conversion to the parent type. The effect would be: Is_Alphanumeric (Wide_Wide_Character ('A')); Wide_Wide_Character's is Is_Alphanumeric (x) Character's is Is_Alphanumeric is Is_Alphanumeric (Wide_Wide_Character (x)); ^^^ inherited body ^^^ added per inheritance This is exactly the semantics of Ada's tagged types as well. The conversion in the case of a tagged type is a view conversion and thus a null-operation. [Only when there is no MI, actually. In presence of full MI view conversion could require adjusting the reference to the object] The bottom line is, you cannot preserve the tag upon dispatching with by-copy object. Therefore, no re-dispatch will be possible for them. And the mantra sung here that any reasonable change would break Ada is a distraction used to shut up the discussion. Ada 95 design of classes was sound and it is quite possible to extend it to all types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-13 19:43 ` Niklas Holsti 2014-04-13 21:07 ` Dmitry A. Kazakov @ 2014-04-15 0:08 ` Randy Brukardt 2014-04-15 7:21 ` Natasha Kerensikova 2014-04-16 21:44 ` Your wish list for Ada 202X Niklas Holsti 1 sibling, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-15 0:08 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:br07nkFnvrbU1@mid.individual.net... ... > (This is why I don't understand your and Randy's abhorrence of > re-dispatching -- to me, there is no basic difference between > dispatching calls in class-wide operations, and re-dispatching calls in > primitive operations.) I don't think it is a good idea to assume that Dmitry and I have the same opinion on anything, even if the result appears to be the same. :-) I view dispatching operations as the low-level primitives of a type, while class-wide operations (which actually involve dispatching) as higher-level operations of the type. As such, a re-dispatching call means that there is some sort of abstraction inversion going on, and that's usually (but not always) bad. Dispatching operations necessarily have weaker contracts than statically bound calls, and that is especially important for "contracts" that can't be described in Ada and thus can't be checked (either statically or dynamically). After all, most extensions are created by someone other than the originator of the original class, so violations of those implicit contracts are bound to happen. (Errors happen any time humans are involved!) Thus, you have much more confidence in operations that don't involve re-dispatching -- as a practical matter, it is a lot easier to debug statically bound calls rather than dispatching ones. Finally (really a restating of the last point), I find that it's fairly easy to ensure that all of the primitive operations of a particular type have the same world-view. That's not as true when some of the operations are assuming the object is of type T, and some are re-dispatching to some TT derived from T -- I've found many instances where some predicate of TT gets a different answer than the same predicate of the same object viewed as a T. That sort of things leads to all kinds of bugs, because not all of those predicates are explicit in the code (even as statically bound calls). This last issue doesn't arise for a class-wide operation, where every call is going to look at an object of TT as type TT. And that's really the major difference between "dispatching" and "re-dispatching". Perhaps I'm just being too conservative here, but I do like being able to get things to work as expected. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 0:08 ` Randy Brukardt @ 2014-04-15 7:21 ` Natasha Kerensikova 2014-04-15 21:20 ` Randy Brukardt 2014-04-16 6:32 ` Niklas Holsti 2014-04-16 21:44 ` Your wish list for Ada 202X Niklas Holsti 1 sibling, 2 replies; 240+ messages in thread From: Natasha Kerensikova @ 2014-04-15 7:21 UTC (permalink / raw) Hello, On 2014-04-15, Randy Brukardt <randy@rrsoftware.com> wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:br07nkFnvrbU1@mid.individual.net... > ... >> (This is why I don't understand your and Randy's abhorrence of >> re-dispatching -- to me, there is no basic difference between >> dispatching calls in class-wide operations, and re-dispatching calls in >> primitive operations.) > > [...] > > Finally (really a restating of the last point), I find that it's fairly easy > to ensure that all of the primitive operations of a particular type have the > same world-view. That's not as true when some of the operations are assuming > the object is of type T, and some are re-dispatching to some TT derived from > T -- I've found many instances where some predicate of TT gets a different > answer than the same predicate of the same object viewed as a T. That sort > of things leads to all kinds of bugs, because not all of those predicates > are explicit in the code (even as statically bound calls). > > This last issue doesn't arise for a class-wide operation, where every call > is going to look at an object of TT as type TT. And that's really the major > difference between "dispatching" and "re-dispatching". Thanks for the explanation, but I'm a bit lost where the situation I have encountered the most fits in "dispatching" vs "re-dispatching": let's consider an abstract type T, with an abstract operation AO and a huge part of the algorithm implemented in primitive operations for T, making use of AO. Concrete descendants of T are supposed to implement AO, and inherit the rest without overriding. Then in T subprograms I end up with things that look like: AO (T'Class (Self), Other, Arguments); I've always thought of this as "re-disatching". Is it? Is it somehow more acceptable? (maybe it doesn't make any sense to consider it as some "predicate with the same object viewed as T") Are there better language facilities to use in such situations? (I used to use generics for that, and still do when there is absolutely no plan for any child package) Thanks for the clarification, Natasha ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 7:21 ` Natasha Kerensikova @ 2014-04-15 21:20 ` Randy Brukardt 2014-04-16 6:32 ` Niklas Holsti 1 sibling, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-15 21:20 UTC (permalink / raw) "Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message news:slrnlkpnfe.i0l.lithiumcat@nat.rebma.instinctive.eu... ... > let's consider an abstract type T, with an abstract operation AO and a > huge part of the algorithm implemented in primitive operations for T, > making use of AO. Concrete descendants of T are supposed to implement > AO, and inherit the rest without overriding. > > Then in T subprograms I end up with things that look like: > AO (T'Class (Self), Other, Arguments); > > I've always thought of this as "re-disatching". Is it? I think it is as well. > Is it somehow more acceptable? (maybe it doesn't make any sense to > consider it as some "predicate with the same object viewed as T") Perhaps. The only cases where I've intentionally used re-dispatching look like this (one example: action routines in Claw, which are of course implemented by each extension -- but the bulk of the work is shared by all implementations). Such a case seems somehow different, but I don't think I can explain why. > Are there better language facilities to use in such situations? > (I used to use generics for that, and still do when there is absolutely > no plan for any child package) I don't know of any. One could use access-to-subprograms for such usage, but I don't see any big advantage to doing that instead -- there seems to be more chance of getting something wrong that way. (Failure to register, registering the wrong routine, etc. can't happen with the overridding routine solution.) I suspect that the reason re-dispatching is allowed is because there are some cases like this where nothing else would seem to work as well. But perhaps there is a better solution, we just haven't found it yet. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 7:21 ` Natasha Kerensikova 2014-04-15 21:20 ` Randy Brukardt @ 2014-04-16 6:32 ` Niklas Holsti 2014-04-16 7:24 ` Natasha Kerensikova ` (2 more replies) 1 sibling, 3 replies; 240+ messages in thread From: Niklas Holsti @ 2014-04-16 6:32 UTC (permalink / raw) On 14-04-15 10:21 , Natasha Kerensikova wrote: > Hello, [snip] > let's consider an abstract type T, with an abstract operation AO and a > huge part of the algorithm implemented in primitive operations for T, > making use of AO. Concrete descendants of T are supposed to implement > AO, and inherit the rest without overriding. > > Then in T subprograms I end up with things that look like: > AO (T'Class (Self), Other, Arguments); > > > I've always thought of this as "re-disatching". Is it? Yes, as I understand the word. > Are there better language facilities to use in such situations? If, as you say above, descendants of T are supposed to inherit the primitive operations of T *without overriding them*, you could implement those primitive operations instead as class-wide operations (operations on T'Class), and then calls of AO from those class-wide operations would be (simply) dispatching, and not re-dispatching. As I understand them, both Dmitry and Randy would consider the class-wide form a better solution, but it works only if you never need to override these class-wide operations for any descendant types. I am seldom sure about that (never needing to override, not even in the future), so I prefer to have the operations as primitive rather than class-wide, and consequently to use re-dispatch. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-16 6:32 ` Niklas Holsti @ 2014-04-16 7:24 ` Natasha Kerensikova 2014-04-16 7:31 ` Dmitry A. Kazakov 2014-04-16 9:30 ` Redispatching (was: Your wish list for Ada 202X) J-P. Rosen 2 siblings, 0 replies; 240+ messages in thread From: Natasha Kerensikova @ 2014-04-16 7:24 UTC (permalink / raw) Hello, On 2014-04-16, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: > On 14-04-15 10:21 , Natasha Kerensikova wrote: >> I've always thought of this as "re-disatching". Is it? > > Yes, as I understand the word. > >> Are there better language facilities to use in such situations? > > If, as you say above, descendants of T are supposed to inherit the > primitive operations of T *without overriding them*, you could implement > those primitive operations instead as class-wide operations (operations > on T'Class), and then calls of AO from those class-wide operations would > be (simply) dispatching, and not re-dispatching. > > As I understand them, both Dmitry and Randy would consider the > class-wide form a better solution, but it works only if you never need > to override these class-wide operations for any descendant types. > > I am seldom sure about that (never needing to override, not even in the > future), so I prefer to have the operations as primitive rather than > class-wide, and consequently to use re-dispatch. Indeed, I can make the whole algorithm class-wide, I had completely missed the possibility. In the few cases of such redispatching I encountered recently, it makes sense to actively prevent the non-abstract operations from being overridden, because they really need some kind of internal consistency, so you would either override all of them or none. If you would override them all, you can just build a new type with the same interface and use composition. However it turns out that in those cases I actually can't make them class-wide, because those operations are part of an interface publicly implemented by the abstract type. And even if you think of interfaces as evil, it seems the same problem would arise with a purely abstract parent. Is there a technical reason to forbid abstract operations from being implemented by a class-wide operation on a descendant type, and thereby being shared rather than inherited for the whole subtree? Natasha ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-16 6:32 ` Niklas Holsti 2014-04-16 7:24 ` Natasha Kerensikova @ 2014-04-16 7:31 ` Dmitry A. Kazakov 2014-04-16 9:30 ` Redispatching (was: Your wish list for Ada 202X) J-P. Rosen 2 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-16 7:31 UTC (permalink / raw) On Wed, 16 Apr 2014 09:32:15 +0300, Niklas Holsti wrote: > As I understand them, both Dmitry and Randy would consider the > class-wide form a better solution, but it works only if you never need > to override these class-wide operations for any descendant types. BTW, the language design principle: each type must have a class. Let T'Class would have a class (T'Class'Class). Then a class-wide operation of T becomes a primitive operation of T'Class, and thus could be overridden in some subclass. Surely there would be problems with that, starting with the problem is that T'Class is matched by structure rather nominally... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Redispatching (was: Your wish list for Ada 202X) 2014-04-16 6:32 ` Niklas Holsti 2014-04-16 7:24 ` Natasha Kerensikova 2014-04-16 7:31 ` Dmitry A. Kazakov @ 2014-04-16 9:30 ` J-P. Rosen 2014-04-16 19:53 ` Redispatching Niklas Holsti 2 siblings, 1 reply; 240+ messages in thread From: J-P. Rosen @ 2014-04-16 9:30 UTC (permalink / raw) Le 16/04/2014 08:32, Niklas Holsti a écrit : > As I understand them, both Dmitry and Randy would consider the > class-wide form a better solution, but it works only if you never need > to override these class-wide operations for any descendant types. > > I am seldom sure about that (never needing to override, not even in the > future), so I prefer to have the operations as primitive rather than > class-wide, and consequently to use re-dispatch. Actually, it's a different use case. Not much discussed in the litterature, because only Ada has a clear distinction between methods (primitive operations) and class-wide operations. A method is for the case where each type has its own way (method!) of doing things: you don't paint a button like you paint a text. A class-wide operation is usually a combination of (dispatching) calls to methods, to build higher level services; it's for the case where you want to make sure that all objects use the same algorithm; for example, when you move a widget, you want to guarantee that it is erased from its current position and repainted somewhere else, and that nobody will redefine move to do something else! It also ensures that should the algorithm change, the change needs to be done in only one place. As far as redispatching is concerned: since a method is linked to a single class, there should be no redispatching. Feeling a need for redispatching in a method is often a symptom that a class-wide operation is a better fit. And yes, chosing between methods and class-wide ops is not trivial and requires some thoughts; once you have a clear separation between these, it makes development a lot easier. Redispatching is mostly advocated by users of other languages that do not have class-wide operations, and use methods for what should be class-wide. In that case, failing to redispatch leads to incorrect behaviour. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-16 9:30 ` Redispatching (was: Your wish list for Ada 202X) J-P. Rosen @ 2014-04-16 19:53 ` Niklas Holsti 2014-04-17 7:26 ` Redispatching Dmitry A. Kazakov 2014-04-17 8:53 ` Redispatching J-P. Rosen 0 siblings, 2 replies; 240+ messages in thread From: Niklas Holsti @ 2014-04-16 19:53 UTC (permalink / raw) On 14-04-16 12:30 , J-P. Rosen wrote: > Le 16/04/2014 08:32, Niklas Holsti a écrit : >> As I understand them, both Dmitry and Randy would consider the >> class-wide form a better solution, but it works only if you never need >> to override these class-wide operations for any descendant types. >> >> I am seldom sure about that (never needing to override, not even in the >> future), so I prefer to have the operations as primitive rather than >> class-wide, and consequently to use re-dispatch. > > Actually, it's a different use case. Not much discussed in the > litterature, because only Ada has a clear distinction between methods > (primitive operations) and class-wide operations. > > A method is for the case where each type has its own way (method!) of > doing things: you don't paint a button like you paint a text. > > A class-wide operation is usually a combination of (dispatching) calls > to methods, to build higher level services; it's for the case where you > want to make sure that all objects use the same algorithm; I understand this difference (as should have been evident from my previous posts). But you are presenting it as a black-or-white, two-valued choice; in my perception, there are also operations which share features of both extremes. Shades of grey. > for example, > when you move a widget, you want to guarantee that it is erased from its > current position and repainted somewhere else, and that nobody will > redefine move to do something else! It also ensures that should the > algorithm change, the change needs to be done in only one place. But then I derive a widget type which is implemented by a sprite, and this widget can be moved just by changing its (x,y) registers, without "erasing" and "redrawing". The "universal" move operation is not really applicable to this widget, and can be overridden by a special and faster operation. (I know that sprites are no longer used in display HW, but I did not want to invent a more up-to-date example.) > As far as redispatching is concerned: since a method is linked to a > single class, there should be no redispatching. (I think you meant to write "linked to a single type", not "class".) Then you must also be of the opionion that there should be no inheritance of methods, because inheritance makes the same method become linked to different types. Is that your view? Of course I disagree with this. > Feeling a need for > redispatching in a method is often a symptom that a class-wide operation > is a better fit. Except in these intermediate cases where there is an operation which is an almost general, default algorithm, which could be class-wide except that it needs to be overridden for some types in the class. > And yes, chosing between methods and class-wide ops is not trivial and > requires some thoughts; once you have a clear separation between these, > it makes development a lot easier. Of course I disagree with that (becase I do not consider redispatching harmful). But in the absence of empirical research on this question, this is a subjective opinion. > Redispatching is mostly advocated by users of other languages that do > not have class-wide operations, and use methods for what should be > class-wide. In that case, failing to redispatch leads to incorrect > behaviour. I think it is very good that Ada provides a choice, and I don't mind that redispatching is not the default in Ada, even if I use it more often than not. I'm not advocating redispatching in general, but I don't hesitate to use it when it is necessary to give me the behaviour I want. And I refuse to feel ashamed just because C++ or Java users also use redispatching. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-16 19:53 ` Redispatching Niklas Holsti @ 2014-04-17 7:26 ` Dmitry A. Kazakov 2014-04-17 8:22 ` Redispatching Georg Bauhaus 2014-04-18 20:08 ` Redispatching Niklas Holsti 2014-04-17 8:53 ` Redispatching J-P. Rosen 1 sibling, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-17 7:26 UTC (permalink / raw) On Wed, 16 Apr 2014 22:53:28 +0300, Niklas Holsti wrote: > On 14-04-16 12:30 , J-P. Rosen wrote: >> As far as redispatching is concerned: since a method is linked to a >> single class, there should be no redispatching. > > (I think you meant to write "linked to a single type", not "class".) > > Then you must also be of the opionion that there should be no > inheritance of methods, because inheritance makes the same method become > linked to different types. Is that your view? It is confused. A primitive operation (method) is defined on (linked to) the whole class T'Class. Its specific body is defined on a specific type S<:T. Re-dispatch does not violate the contract of the primitive operation, it potentially does the contract of the *type-specific* body where re-dispatch happens. BTW, it is not just re-dispatch. I would argue that when you call a parent's implementation from the body you also potentially violate the contract: procedure F (X : in out S) is begin ... F (T (X)); -- Parent's implementation ... end F; Of course here potential harm is much lesser than in the case of re-dispatch. In short, we know that type coercion is bad, don't we? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-17 7:26 ` Redispatching Dmitry A. Kazakov @ 2014-04-17 8:22 ` Georg Bauhaus 2014-04-18 20:08 ` Redispatching Niklas Holsti 1 sibling, 0 replies; 240+ messages in thread From: Georg Bauhaus @ 2014-04-17 8:22 UTC (permalink / raw) On 17/04/14 09:26, Dmitry A. Kazakov wrote: > BTW, it is not just re-dispatch. I would argue that when you call a > parent's implementation from the body you also potentially violate the > contract: > > procedure F (X : in out S) is > begin > ... > F (T (X)); -- Parent's implementation > ... > end F; > > Of course here potential harm is much lesser than in the case of > re-dispatch. > > In short, we know that type coercion is bad, don't we? From this knowledge follows a principle of design by contract: Inside the module, it is its programmer's responsibility to make sure that F's body is left such that the module is in a state that fulfills the contract (of outer F, and its module). In now obsolescent SPARK terms, there is a --# hide after "begin". ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-17 7:26 ` Redispatching Dmitry A. Kazakov 2014-04-17 8:22 ` Redispatching Georg Bauhaus @ 2014-04-18 20:08 ` Niklas Holsti 2014-04-18 20:51 ` Redispatching Dmitry A. Kazakov 1 sibling, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-18 20:08 UTC (permalink / raw) On 14-04-17 10:26 , Dmitry A. Kazakov wrote: > On Wed, 16 Apr 2014 22:53:28 +0300, Niklas Holsti wrote: > >> On 14-04-16 12:30 , J-P. Rosen wrote: >>> As far as redispatching is concerned: since a method is linked to a >>> single class, there should be no redispatching. >> >> (I think you meant to write "linked to a single type", not "class".) >> >> Then you must also be of the opionion that there should be no >> inheritance of methods, because inheritance makes the same method become >> linked to different types. Is that your view? > > It is confused. A primitive operation (method) is defined on (linked to) > the whole class T'Class. Its specific body is defined on a specific type > S<:T. As you see it, yes. However, in Ada the parameters of type T are really views of objects which may be of type T or of a type derived from T. This must be kept in mind when coding the body, and then redispatching is merely view conversion, not type coercion. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-18 20:08 ` Redispatching Niklas Holsti @ 2014-04-18 20:51 ` Dmitry A. Kazakov 2014-04-19 9:17 ` Redispatching Georg Bauhaus 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-18 20:51 UTC (permalink / raw) On Fri, 18 Apr 2014 23:08:25 +0300, Niklas Holsti wrote: > On 14-04-17 10:26 , Dmitry A. Kazakov wrote: >> On Wed, 16 Apr 2014 22:53:28 +0300, Niklas Holsti wrote: >> >>> On 14-04-16 12:30 , J-P. Rosen wrote: >>>> As far as redispatching is concerned: since a method is linked to a >>>> single class, there should be no redispatching. >>> >>> (I think you meant to write "linked to a single type", not "class".) >>> >>> Then you must also be of the opionion that there should be no >>> inheritance of methods, because inheritance makes the same method become >>> linked to different types. Is that your view? >> >> It is confused. A primitive operation (method) is defined on (linked to) >> the whole class T'Class. Its specific body is defined on a specific type >> S<:T. > > As you see it, yes. However, in Ada the parameters of type T are really > views of objects which may be of type T or of a type derived from T. Wrong. Consider this set of declarations: type T is ...; procedure Bar (X : T); type S is new T ...; procedure Foo (X : S); Now the following is illegal: procedure Bar (X : T) is begin X.Foo; -- Compile error end Bar; X in Bar is of the type T and of no other type. You can convert X using so-called "view-conversion" to an object of another type, e.g. S or T'Class. This conversion is a type conversion. Yes, it has certain properties when X is tagged (and thus by-reference), such as reusing the old object for the new one. These properties are irrelevant to the type semantics though. You get an object of a different type. If Ada supported classes of by-copy types, then conversion to S or T'Class would produce a new object. But the type semantics would remain same. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-18 20:51 ` Redispatching Dmitry A. Kazakov @ 2014-04-19 9:17 ` Georg Bauhaus 2014-04-19 10:58 ` Redispatching Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Georg Bauhaus @ 2014-04-19 9:17 UTC (permalink / raw) On 18/04/14 22:51, Dmitry A. Kazakov wrote: > Consider this set of declarations: > > type T is ...; > procedure Bar (X : T); > > type S is new T ...; > procedure Foo (X : S); > > Now the following is illegal: > > procedure Bar (X : T) is > begin > X.Foo; -- Compile error > end Bar; > > X in Bar is of the type T and of no other type. > > You can convert X using so-called "view-conversion" to an object of another > type, e.g. S or T'Class. This conversion is a type conversion. Yes, it has > certain properties when X is tagged (and thus by-reference), such as > reusing the old object for the new one. These properties are irrelevant to > the type semantics though. You get an object of a different type. Actually, in Ada, you will predictably get the object that is passed for X, which "is" of its type. (As usual, the discussion hinges on the meaning of "is".) This provides the programmer with more semantic possibilities: procedure Bar (X : T) is begin S(T'Class(X)).Foo; -- No compile error end Bar; This type conversion (downwards) is legal, and it permits deferring any type checking to run-time, should programmers have reason to do so. If you think this is improper design, why not outline an algorithm that transfers any such program into one that demonstrably dispenses with downward conversions. > If Ada supported classes of by-copy types, then conversion to S or T'Class > would produce a new object. But the type semantics would remain same. In view of the above example, absent an isomorphic program transformation as requested, by-copy types will require changing the semantics of Ada. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-19 9:17 ` Redispatching Georg Bauhaus @ 2014-04-19 10:58 ` Dmitry A. Kazakov 2014-04-19 11:21 ` Redispatching Georg Bauhaus 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-19 10:58 UTC (permalink / raw) On Sat, 19 Apr 2014 11:17:22 +0200, Georg Bauhaus wrote: > On 18/04/14 22:51, Dmitry A. Kazakov wrote: > >> Consider this set of declarations: >> >> type T is ...; >> procedure Bar (X : T); >> >> type S is new T ...; >> procedure Foo (X : S); >> >> Now the following is illegal: >> >> procedure Bar (X : T) is >> begin >> X.Foo; -- Compile error >> end Bar; >> >> X in Bar is of the type T and of no other type. >> >> You can convert X using so-called "view-conversion" to an object of another >> type, e.g. S or T'Class. This conversion is a type conversion. Yes, it has >> certain properties when X is tagged (and thus by-reference), such as >> reusing the old object for the new one. These properties are irrelevant to >> the type semantics though. You get an object of a different type. > > Actually, in Ada, you will predictably get the object that is passed > for X, which "is" of its type. (As usual, the discussion hinges on > the meaning of "is".) This provides the programmer with more semantic > possibilities: > > procedure Bar (X : T) is > begin > S(T'Class(X)).Foo; -- No compile error > end Bar; > > This type conversion (downwards) is legal, So would an instantiation of Unchecked_Conversion. > If you think this is improper design, Yes I do. You should abstain design of this kind as much as you would ones using Unchecked_Conversion. > why not outline an algorithm that transfers any > such program into one that demonstrably dispenses with downward conversions. Easily. The algorithm is. Type: $ rm -f bar.adb then take a cup of coffee and review your design. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-19 10:58 ` Redispatching Dmitry A. Kazakov @ 2014-04-19 11:21 ` Georg Bauhaus 0 siblings, 0 replies; 240+ messages in thread From: Georg Bauhaus @ 2014-04-19 11:21 UTC (permalink / raw) On 19/04/14 12:58, Dmitry A. Kazakov wrote: > The algorithm is. Type: > > $ rm -f bar.adb > > then take a cup of coffee and review your design. Programmers usually won't be allowed any more coffee after deleting working solutions. More cleverness is needed. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Redispatching 2014-04-16 19:53 ` Redispatching Niklas Holsti 2014-04-17 7:26 ` Redispatching Dmitry A. Kazakov @ 2014-04-17 8:53 ` J-P. Rosen 1 sibling, 0 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-17 8:53 UTC (permalink / raw) Le 16/04/2014 21:53, Niklas Holsti a écrit : > On 14-04-16 12:30 , J-P. Rosen wrote: >> Actually, it's a different use case. Not much discussed in the >> litterature, because only Ada has a clear distinction between methods >> (primitive operations) and class-wide operations. >> >> A method is for the case where each type has its own way (method!) of >> doing things: you don't paint a button like you paint a text. >> >> A class-wide operation is usually a combination of (dispatching) calls >> to methods, to build higher level services; it's for the case where you >> want to make sure that all objects use the same algorithm; > > I understand this difference (as should have been evident from my > previous posts). But you are presenting it as a black-or-white, > two-valued choice; in my perception, there are also operations which > share features of both extremes. Shades of grey. In a well organized program, I tend to avoid grey, and match my needs either to one or the other. It is constraining sometimes, but makes understanding and maintenance a lot easier. >> for example, >> when you move a widget, you want to guarantee that it is erased from its >> current position and repainted somewhere else, and that nobody will >> redefine move to do something else! It also ensures that should the >> algorithm change, the change needs to be done in only one place. > > But then I derive a widget type which is implemented by a sprite, and > this widget can be moved just by changing its (x,y) registers, without > "erasing" and "redrawing". The "universal" move operation is not really > applicable to this widget, and can be overridden by a special and faster > operation. (I know that sprites are no longer used in display HW, but I > did not want to invent a more up-to-date example.) Interesting example... If you consider that various widgets have different "methods" of moving, then you have to make it a method and not a class-wide operation. Those that are not sprite would inherit the method from the root widget, i.e. the default erase-and-redraw. >> As far as redispatching is concerned: since a method is linked to a >> single class, there should be no redispatching. > > (I think you meant to write "linked to a single type", not "class".) I use "class" because I'm talking about the general concept, not specifically Ada. #define class "A package declaring a single tagged type and associated primitive operations" ;-) > Then you must also be of the opionion that there should be no > inheritance of methods, because inheritance makes the same method become > linked to different types. Is that your view? > Not at all. I view inheritance of methods as providing a default value for the operation. If you like it, take it, if not, redefine it. However there is still one method per class, whether redefined or inherited. >> Feeling a need for >> redispatching in a method is often a symptom that a class-wide operation >> is a better fit. > > Except in these intermediate cases where there is an operation which is > an almost general, default algorithm, which could be class-wide except > that it needs to be overridden for some types in the class. See above. The choice is a design decision, and often not an easy one. But there is value in deciding "this is a property of each specific type" or "this is a property of the whole class (in the sense class-wide)". [...] > I'm not advocating redispatching in general, but I don't hesitate to use > it when it is necessary to give me the behaviour I want. To me, it raises an alarm that something might be wrong. A possibility is that the functionality could be kept class-wide by adding another method. Admitedly, that's MY way of working: define a few (sometimes constraining) patterns and stick to them. Similar to my preference for standard components (even if I have to adjust my design), rather than reinventing the wheel if the standard components do not match 100%. YMMV. > And I refuse to feel ashamed just because C++ or Java users also use > redispatching. > Nothing to be ashamed of, it is a matter of philosophy of software design. What I'm saying is just that Ada has a richer toolset than these languages, therefore the fact that other languages use a certain solution does not imply that the same should be used for Ada. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 0:08 ` Randy Brukardt 2014-04-15 7:21 ` Natasha Kerensikova @ 2014-04-16 21:44 ` Niklas Holsti 2014-04-16 22:27 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-16 21:44 UTC (permalink / raw) On 14-04-15 03:08 , Randy Brukardt wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:br07nkFnvrbU1@mid.individual.net... > ... >> (This is why I don't understand your and Randy's abhorrence of >> re-dispatching -- to me, there is no basic difference between >> dispatching calls in class-wide operations, and re-dispatching calls in >> primitive operations.) > > I don't think it is a good idea to assume that Dmitry and I have the same > opinion on anything, even if the result appears to be the same. :-) I think I knew that... apologies if I implied differently (I see the smiley, thanks for the forbearance). > I view dispatching operations as the low-level primitives of a type, while > class-wide operations (which actually involve dispatching) as higher-level > operations of the type. In this you and Dmitry agree, it seems. In an earlier reply to Dmitry, I also agreed that class-wide operations are higher-level than primitive ops, but having thought a bit more, I want to modify that statement. Some of my class-wide operations are, rather, so fundamental for the class that I make them class-wide because I see no need to ever override them in any derived type of the class. But I'm not sure if we can equate "fundamental" with "low-level", architectural analogues notwithstanding ;-) > As such, a re-dispatching call means that there is > some sort of abstraction inversion going on, and that's usually (but not > always) bad. As I replied to Dmitry, my primitive operations tend to be layered, and redispatching usually goes from a higher-level to a lower-level operation. So I don't see this as abstraction inversion. > Dispatching operations necessarily have weaker contracts than statically > bound calls, and that is especially important for "contracts" that can't be > described in Ada and thus can't be checked (either statically or > dynamically). Hm, I'm not convinced of that. To me, the informal contract for a dispatching operation Foo is "implements the Foo operation as specified for the class and as appropriate for the actual type". Of course these specifications are given in comments. I don't see the "necessarily ... weaker" for the more formal contracts either. Yes, for a dispatching call there are more possible callee operations (implementations) to check against the contract, but the general contract (as experienced by the caller) can be the same for all. > After all, most extensions are created by someone other than > the originator of the original class, Not (sadly) the case for my applications. But sometimes years go by between the definition of the class and the addition of a derived type, so memory can play tricks, and I have had a few hiccups in that area. But not many, perhaps thanks to my obsessive commenting. > so violations of those implicit > contracts are bound to happen. (Errors happen any time humans are involved!) > Thus, you have much more confidence in operations that don't involve > re-dispatching -- as a practical matter, it is a lot easier to debug > statically bound calls rather than dispatching ones. I try to make my contracts explicit in comments. All I can say is that my experience does not agree with what you say. But the volume of my programming is not so large as to make a good empirical study. > Finally (really a restating of the last point), I find that it's fairly easy > to ensure that all of the primitive operations of a particular type have the > same world-view. That's not as true when some of the operations are assuming > the object is of type T, and some are re-dispatching to some TT derived from > T -- I've found many instances where some predicate of TT gets a different > answer than the same predicate of the same object viewed as a T. That sort > of things leads to all kinds of bugs, because not all of those predicates > are explicit in the code (even as statically bound calls). I'm not disputing your experience, but I haven't experienced the same. Perhaps there is some difference in our application areas that modulates the risks and benefits of redispatching. > This last issue doesn't arise for a class-wide operation, where every call > is going to look at an object of TT as type TT. Except if TT inherits some operation from T, because then that operation looks at the object as type T. (I know that from the language-semantics point of view the inherited operation acts on TT, but the programmer wrote its code with T in mind.) If redispatching is suspect because it breaks the assocation of an operation with a unique type, then inheritance of operations must also be suspect, for the same reason. I suppose one could forbid both inheritance and redispatching. That would be a major departure from traditional object/class-oriented programming. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-16 21:44 ` Your wish list for Ada 202X Niklas Holsti @ 2014-04-16 22:27 ` Randy Brukardt 2014-04-18 19:59 ` Niklas Holsti 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-16 22:27 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:br8bu5Fg3keU1@mid.individual.net... > On 14-04-15 03:08 , Randy Brukardt wrote: ... >> Dispatching operations necessarily have weaker contracts than statically >> bound calls, and that is especially important for "contracts" that can't >> be >> described in Ada and thus can't be checked (either statically or >> dynamically). > > Hm, I'm not convinced of that. To me, the informal contract for a > dispatching operation Foo is "implements the Foo operation as specified > for the class and as appropriate for the actual type". Of course these > specifications are given in comments. A lot of our discussion has become subjective, and I don't know if there is a lot to be learned comparing somewhat different world-views. So I'm only going to respond to a couple of points here... Anyway, there is two problems with "specifications given in comments": (A) they can't be checked in any automatic or formal way. When humans are involved, mistakes *will* occur, and if they're not checked, the results could be disasterous. After all, we just got a lesson in that from OpenSSH. Had OpenSSH had a formal contract, the problem could not have ever leaked any information. (If the contract was enforced only at runtime, like Pre in Ada, OpenSSH might have had at worst a denial-of-service problem, but that would have been quickly fixed and most of us would have never heard anything about it.) (B) English (or other natural language) is ambiguous, and such comments often only make sense to the author (and recently at that). I often spend as much time decoding old comments (even ones I wrote years ago) than actually fixing anything in Janus/Ada these days. There's a decent percentage that only make sense if one adds a lot of context to them (and of course a few that defy ever making sense). > I don't see the "necessarily ... weaker" for the more formal contracts > either. Yes, for a dispatching call there are more possible callee > operations (implementations) to check against the contract, but the > general contract (as experienced by the caller) can be the same for all. LSP says that preconditions have to combine weaker in order for dispatching calls to make sense. Whether LSP is really the last word on OOP is an open question, but if you mean to follow it, at least part of the contract *has* to be weaker in a dispatching call. There's also the point that a dispatching call always has to be assumed to be to some body not even written yet, so it's nearly impossible to say anything definitive about it's contract. (Pre'Class and the like are supposed to solve this latter problem, but they have a bug involving (guess what) redispatching so they might not. At least until the ARG considers the bug, which I really need to write up one of these days.) >> After all, most extensions are created by someone other than >> the originator of the original class, > > Not (sadly) the case for my applications. But sometimes years go by > between the definition of the class and the addition of a derived type, > so memory can play tricks, and I have had a few hiccups in that area. > But not many, perhaps thanks to my obsessive commenting. Commenting is good, but formal contracts are better, simply because they require you to write the contract in terms that mean the same thing when you come back to them in 5 years. And then the additional value provided by checking is gravy to people that truly do comment everything. ... ... >> This last issue doesn't arise for a class-wide operation, where every >> call >> is going to look at an object of TT as type TT. > > Except if TT inherits some operation from T, because then that operation > looks at the object as type T. (I know that from the language-semantics > point of view the inherited operation acts on TT, but the programmer > wrote its code with T in mind.) > > If redispatching is suspect because it breaks the assocation of an > operation with a unique type, then inheritance of operations must also > be suspect, for the same reason. I understand your point, but I think the language-semantics view is actually the correct one. One only allows inheritance of operations when the implementation for T and for TT is thought to be identical. One hopes that the author of TT considered that carefully! It's true that maintenance of the T operation might in fact break the TT operation (meaning that they should have different implementations), so there is some additional danger in inheritance. There is also danger in inheritance that the author of TT didn't know about. (I think it would be much better if all inheritance was explicit; but to be practical that would require a rather different syntax than Ada uses, and thus such a thing would not make sense in an Ada perspective. For Claw, we had to write a tool to figure out what operations exist for each concrete type, as there are so many primitive operations and so many inheritance trees that it was completely impossible to keep them straight by hand. I've never been a fan of the way inheritance is handled in Ada.) > I suppose one could forbid both inheritance and redispatching. That > would be a major departure from traditional object/class-oriented > programming. Not forbid so much as "require declaration of". Ada already does that for redispatching; my opinion is that it should be used rarely, but as with all such tools (e.g. goto), rarely is certainly not never. Twisting a design around to avoid redispatching is not likely to improve anything. Similarly, inheritance can cause issues, but a lot of the time it also saves implementing the same thing five times in a row. (The fact that I couldn't make inheritance work for implementing parts of the Claw Builder is a significant part of why it became close to unmaintainable.) My mantra tends to be that programming languages are better when everything is explicit - because when programmers and compilers are assuming stuff, it's not unlikely that the assumptions end up different. And that's when trouble happens. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-16 22:27 ` Randy Brukardt @ 2014-04-18 19:59 ` Niklas Holsti 2014-04-18 21:28 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-18 19:59 UTC (permalink / raw) On 14-04-17 01:27 , Randy Brukardt wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:br8bu5Fg3keU1@mid.individual.net... >> On 14-04-15 03:08 , Randy Brukardt wrote: > ... >>> Dispatching operations necessarily have weaker contracts than statically >>> bound calls, and that is especially important for "contracts" that can't >>> be >>> described in Ada and thus can't be checked (either statically or >>> dynamically). >> >> Hm, I'm not convinced of that. To me, the informal contract for a >> dispatching operation Foo is "implements the Foo operation as specified >> for the class and as appropriate for the actual type". Of course these >> specifications are given in comments. > > A lot of our discussion has become subjective, and I don't know if there is > a lot to be learned comparing somewhat different world-views. So I'm only > going to respond to a couple of points here... > > Anyway, there is two problems with "specifications given in comments": Sorry, I think you misunderstood: I was replying to the case which you described as "contracts that can't be described in Ada". I fully agree that formal contracts are preferable to informal ones, no argument. I don't (yet) use formal contracts, however, except for those that Ada provides implicitly. >> I don't see the "necessarily ... weaker" for the more formal contracts >> either. Yes, for a dispatching call there are more possible callee >> operations (implementations) to check against the contract, but the >> general contract (as experienced by the caller) can be the same for all. > > LSP says that preconditions have to combine weaker in order for dispatching > calls to make sense. Weaker *or equal*, I think. > Whether LSP is really the last word on OOP is an open > question, but if you mean to follow it, at least part of the contract *has* > to be weaker in a dispatching call. Why can't it be equal, again from the point of view of the caller? The full contract for the operation on a derived type is indeed stronger in the sense that it says something specific about the derived type, for example about changes in the components added in the derivation. But those details are not important to the caller's point of view; only the contract's effects on the higher level (caller's type) are relevant. For example, if we have a class of "file" types, with different derived types implementing files on different kinds of storage devices, and a dispatching call of Open, the changes in the device-specific components of the file object are not relevant to the caller of Open; it is only relevant that the file's class-level status changes from "closed" to "open". > There's also the point that a > dispatching call always has to be assumed to be to some body not even > written yet, so it's nearly impossible to say anything definitive about it's > contract. But the operation has been *specified*, even if no bodies exist, therefore the contract *from the caller's point of view* should have been defined. Otherwise there is not much point in using a class at all, or indeed in separating operation declarations and bodies. > ... >>> This last issue doesn't arise for a class-wide operation, where every >>> call is going to look at an object of TT as type TT. >> >> Except if TT inherits some operation from T, because then that operation >> looks at the object as type T. (I know that from the language-semantics >> point of view the inherited operation acts on TT, but the programmer >> wrote its code with T in mind.) >> >> If redispatching is suspect because it breaks the assocation of an >> operation with a unique type, then inheritance of operations must also >> be suspect, for the same reason. > > I understand your point, but I think the language-semantics view is actually > the correct one. One only allows inheritance of operations when the > implementation for T and for TT is thought to be identical. One hopes that > the author of TT considered that carefully! Well, I use redispatching only when I think that the operation being called is well specified and is or will be carefully implemented for each type in the class, as appropriate for that type. Same difference :-) > It's true that maintenance of the T operation might in fact break the TT > operation (meaning that they should have different implementations), so > there is some additional danger in inheritance. Yes. In general, the more a program is "factored" into parts that are combined and invoked in many contexts, the harder it becomes to maintain proper behaviour in all contexts. Subprograms, inheritance, dispatching, redispatching all tend in this direction. > There is also danger in > inheritance that the author of TT didn't know about. (I think it would be > much better if all inheritance was explicit; but to be practical that would > require a rather different syntax than Ada uses, and thus such a thing would > not make sense in an Ada perspective. To make inheritance explicit, it seems to me that each inherited operation must be declared for the derived type, with its full profile, perhaps as inherited procedure Foo (X: in T; ....); This would require just one new reserved word, "inherited", and does not feel like a "rather different syntax". Did you have something else in mind? > > I suppose one could forbid both inheritance and redispatching. That >> would be a major departure from traditional object/class-oriented >> programming. > > Not forbid so much as "require declaration of". Ada already does that for > redispatching; my opinion is that it should be used rarely, but as with all > such tools (e.g. goto), rarely is certainly not never. Thanks for explaining your view. I think I understand it now. > Twisting a design around to avoid redispatching is not likely to > improve anything. Agreed. As I said in my last reply to Dmitry, reaching this point was my reason for commenting on redispatching. I'm content to end here. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-18 19:59 ` Niklas Holsti @ 2014-04-18 21:28 ` Randy Brukardt 2014-04-19 8:14 ` Niklas Holsti 2014-04-19 10:02 ` Georg Bauhaus 0 siblings, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-18 21:28 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:brdegqFi62jU1@mid.individual.net... > On 14-04-17 01:27 , Randy Brukardt wrote: >> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message >> news:br8bu5Fg3keU1@mid.individual.net... >>> On 14-04-15 03:08 , Randy Brukardt wrote: ... >> There's also the point that a >> dispatching call always has to be assumed to be to some body not even >> written yet, so it's nearly impossible to say anything definitive about >> it's >> contract. > > But the operation has been *specified*, even if no bodies exist, > therefore the contract *from the caller's point of view* should have > been defined. Otherwise there is not much point in using a class at all, > or indeed in separating operation declarations and bodies. Right, but here I'm a practicalist, rather than theortician. Humans write programs, and they tend to ignore anything not convinient. That certainly goes for whatever part of the contract is not formally specified and checked. So there is a lot more risk from re-dispatching than static binding, simply because there is more likelihood of error (unintentional or malicious). >> ... >>>> This last issue doesn't arise for a class-wide operation, where every >>>> call is going to look at an object of TT as type TT. >>> >>> Except if TT inherits some operation from T, because then that operation >>> looks at the object as type T. (I know that from the language-semantics >>> point of view the inherited operation acts on TT, but the programmer >>> wrote its code with T in mind.) >>> >>> If redispatching is suspect because it breaks the assocation of an >>> operation with a unique type, then inheritance of operations must also >>> be suspect, for the same reason. >> >> I understand your point, but I think the language-semantics view is >> actually >> the correct one. One only allows inheritance of operations when the >> implementation for T and for TT is thought to be identical. One hopes >> that >> the author of TT considered that carefully! > > Well, I use redispatching only when I think that the operation being > called is well specified and is or will be carefully implemented for > each type in the class, as appropriate for that type. Same difference :-) If you truly believe that you can "well specify" and "carefully implement" everything in your system, well, you're a better man than me. :-) I don't believe that about my code even when I write the entire thing at one time - much less when other people are involved or years pass between work. One of the things that attracted me to Ada in the first place is that it forces me to specify enough that it prevents many of my worst impulses. (Instantiating Unchecked_Conversion is painful enough to prevent most reuse of objects, for one example.) I doubt I'd ever get a lengthy C program to work! >> It's true that maintenance of the T operation might in fact break the TT >> operation (meaning that they should have different implementations), so >> there is some additional danger in inheritance. > > Yes. In general, the more a program is "factored" into parts that are > combined and invoked in many contexts, the harder it becomes to maintain > proper behaviour in all contexts. Subprograms, inheritance, dispatching, > redispatching all tend in this direction. Right. >> There is also danger in >> inheritance that the author of TT didn't know about. (I think it would be >> much better if all inheritance was explicit; but to be practical that >> would >> require a rather different syntax than Ada uses, and thus such a thing >> would >> not make sense in an Ada perspective. > > To make inheritance explicit, it seems to me that each inherited > operation must be declared for the derived type, with its full profile, > perhaps as > > inherited procedure Foo (X: in T; ....); > > This would require just one new reserved word, "inherited", and does not > feel like a "rather different syntax". Did you have something else in > mind? The problem with this sort of syntax is that it's really wordy and tends to obscure the important issues (which is not the exact profile, as least unless you have a resolution problem). Remember all of the people that used renames to avoid using use clauses for Ada 83? (Maybe not, that was a long time ago.) They often had bugs like: function "+" (Left, Right : P.Big_Int) return P.Big_Int renames P."-"; where the profile is obscuring the critical differences. I'd prefer a much simpler declaration of inheritance, something like: type Child is new Parent with ... with inherits => Foo, Bar, Blech; where names not listed are hidden from all visibility unless overridden. (The Ada dispatching model insists that the routines exist, so for Ada all one could do would be to hide any uninherited operations from direct calls. One could imagine have uninherited operations raise Program_Error in dispatching as an alternative, but that's not ideal either because it makes a tripping hazard as Bob calls it. Thirdly, one could require all operations to be either inherited or overridden, but that just makes a new kind of pain for deriving types, especially for those of us who prefer incremental implementation of things). Whether that's enough or if some alternative with optional profiles is necessary, I don't know. Most operations aren't overloaded, after all, so the profile is just noise. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-18 21:28 ` Randy Brukardt @ 2014-04-19 8:14 ` Niklas Holsti 2014-04-21 23:09 ` Randy Brukardt 2014-04-19 10:02 ` Georg Bauhaus 1 sibling, 1 reply; 240+ messages in thread From: Niklas Holsti @ 2014-04-19 8:14 UTC (permalink / raw) On 14-04-19 00:28 , Randy Brukardt wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:brdegqFi62jU1@mid.individual.net... >> ... >> Well, I use redispatching only when I think that the operation being >> called is well specified and is or will be carefully implemented for >> each type in the class, as appropriate for that type. Same difference :-) > > If you truly believe that you can "well specify" and "carefully implement" > everything in your system, well, you're a better man than me. :-) No, no... I should have made it explicit in the quoted text that what "I think" is not always correct, and of course I make errors (maybe I should have written "when I hope" instead of "when I think"). But the errors don't seem more likely to occur in redispatching calls than in other calls. This may be because tagged types are not yet the core of my applications, so my dispatching and redispatching operations are usually not very complex. > One of > the things that attracted me to Ada in the first place is that it forces me > to specify enough that it prevents many of my worst impulses. I learned programming with Algol and did not encounter C until I had experienced various forms of BASIC, COBOL, and Fortran (plus a few assembly languages). This shielded me, I think, from being tempted to use C-style short-cuts. So, perhaps unusually, I don't feel at all constrained by Ada's requirements on explicitness, careful specification, and strong typing. > I doubt I'd ever get a lengthy C program to work! I feel a lot more confident in my Ada code than in my C code. >>> ... (I think it would be >>> much better if all inheritance was explicit; but to be practical that >>> would >>> require a rather different syntax than Ada uses, and thus such a thing >>> would >>> not make sense in an Ada perspective. >> >> To make inheritance explicit, it seems to me that each inherited >> operation must be declared for the derived type, with its full profile, >> perhaps as >> >> inherited procedure Foo (X: in T; ....); >> >> This would require just one new reserved word, "inherited", and does not >> feel like a "rather different syntax". Did you have something else in >> mind? > > The problem with this sort of syntax is that it's really wordy Yes indeed. > and tends to > obscure the important issues (which is not the exact profile, as least > unless you have a resolution problem). Remember all of the people that used > renames to avoid using use clauses for Ada 83? (Maybe not, that was a long > time ago.) They often had bugs like: > function "+" (Left, Right : P.Big_Int) return P.Big_Int renames P."-"; > where the profile is obscuring the critical differences. Been there, done that (bugs too), with TLD Ada for a MIL-STD-1750B. (The bugs usually arose through copy-paste mistakes, where one needed to rename both "+" and "-" but forgot to change both occurrences of "+" to "-" in the pasted copy of the renaming for "+") > I'd prefer a much simpler declaration of inheritance, something like: > type Child is new Parent with ... > with inherits => Foo, Bar, Blech; > > where names not listed are hidden from all visibility unless overridden. This form would probably strongly discourage overloaded operation names. > Whether that's enough or if some alternative with optional profiles is > necessary, I don't know. Most operations aren't overloaded, after all, so > the profile is just noise. I have quite a few overloaded primitive operations, perhaps because I tend to use named association in all calls so that the parameter names extend and clarify the brief operation name. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-19 8:14 ` Niklas Holsti @ 2014-04-21 23:09 ` Randy Brukardt 2014-04-22 6:08 ` Niklas Holsti 2014-04-22 8:02 ` Dmitry A. Kazakov 0 siblings, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-21 23:09 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:brepivFq9kcU1@mid.individual.net... > On 14-04-19 00:28 , Randy Brukardt wrote: >> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message >> news:brdegqFi62jU1@mid.individual.net... ... >> One of >> the things that attracted me to Ada in the first place is that it forces >> me >> to specify enough that it prevents many of my worst impulses. > > I learned programming with Algol and did not encounter C until I had > experienced various forms of BASIC, COBOL, and Fortran (plus a few > assembly languages). This shielded me, I think, from being tempted to > use C-style short-cuts. So, perhaps unusually, I don't feel at all > constrained by Ada's requirements on explicitness, careful > specification, and strong typing. Well, I started with various programmable calculator "languages" (really a machine language), then Fortran, then various Basics, then Z80 assembler, then a language survey class, then a class with C language assignments. The only school assignment that I didn't get to work by the due date was in C. I spent several hours after presenting it to the professor trying to figure out why one of the guns wouldn't fire (it was supposed to a game on a vector display, which we had to demonstrate -- I chose something vaguely like Space Invaders, which was new at the time). It proved to be an access beyond the end of an array that corrupted the firing table. I think I've written 7 or 8 lines of C since. :-) [C is now pretty much a read-only language for me, sort of like French.] But for me, I don't the languages used would make that much difference. My Dad is a tinkerer who would rather try for 4 hours to start a malfunctioning chain saw than to just take it to a repair shop and do something else. (That's the story from this past weekend, so some things change little!) I certainly learned that from him, and I *know* I'd dream up insane ways to get the job done if the language didn't impose some sanity. Maybe a little less so than in years past, but probably not enough to actually accomplish anything. ... >> I'd prefer a much simpler declaration of inheritance, something like: >> type Child is new Parent with ... >> with inherits => Foo, Bar, Blech; >> >> where names not listed are hidden from all visibility unless overridden. > > This form would probably strongly discourage overloaded operation names. Possible, although in many instances, all of the overloaded routines do essentially the same thing and thus either all need overriding or none do. (After all, if you have overloaded routines doing *different* things, something is wrong!) >> Whether that's enough or if some alternative with optional profiles is >> necessary, I don't know. Most operations aren't overloaded, after all, so >> the profile is just noise. > > I have quite a few overloaded primitive operations, perhaps because I > tend to use named association in all calls so that the parameter names > extend and clarify the brief operation name. Yes, that works. But still, you probably don't have too many Open operations that close objects. :-) As I said, I've found that it's common that you need to override all of the Open operations (because they all need to set a new component, for instance, or call a different Open routine that does that), or the original versions are all good enough. Perhaps that's different if multiple inheritance gets involved, but it certainly seems true for single inheritance. But I don't claim to know the best way to do this, and it's pretty irrelevant for Ada anyway (it would be way too incompatible to require for derivations unless a new kind of derivation was involved - and it would take some imagination to figure a reason for needed a new kind of derivation). Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-21 23:09 ` Randy Brukardt @ 2014-04-22 6:08 ` Niklas Holsti 2014-04-22 8:02 ` Dmitry A. Kazakov 1 sibling, 0 replies; 240+ messages in thread From: Niklas Holsti @ 2014-04-22 6:08 UTC (permalink / raw) On 14-04-22 02:09 , Randy Brukardt wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:brepivFq9kcU1@mid.individual.net... >> On 14-04-19 00:28 , Randy Brukardt wrote: >>> ... >>> I'd prefer a much simpler declaration of inheritance, something like: >>> type Child is new Parent with ... >>> with inherits => Foo, Bar, Blech; >>> >>> where names not listed are hidden from all visibility unless overridden. >> >> This form would probably strongly discourage overloaded operation names. > > Possible, although in many instances, all of the overloaded routines do > essentially the same thing and thus either all need overriding or none do. So saying "inherits => Foo" would inherit all operations named Foo. That would work, but is a bit weak if the goal is to specify inheritance explicitly. > (After all, if you have overloaded routines doing *different* things, > something is wrong!) Yes. So if the goal of "with inherits" is to specify explicitly the "nature" of the inherited operations, for example all "read" operations but no "write" operations, it is ok to let one name stand for all operations with that name. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-21 23:09 ` Randy Brukardt 2014-04-22 6:08 ` Niklas Holsti @ 2014-04-22 8:02 ` Dmitry A. Kazakov 2014-04-22 8:30 ` Shark8 1 sibling, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-22 8:02 UTC (permalink / raw) On Mon, 21 Apr 2014 18:09:46 -0500, Randy Brukardt wrote: > Yes, that works. But still, you probably don't have too many Open operations > that close objects. :-) As I said, I've found that it's common that you need > to override all of the Open operations (because they all need to set a new > component, for instance, or call a different Open routine that does that), > or the original versions are all good enough. Perhaps that's different if > multiple inheritance gets involved, but it certainly seems true for single > inheritance. But there should be no Open operation at all. The object must be functional in each its state. Open is not an operation it is a part of the object's constructor. This is another language problem that Ada forces you to introduce Open, which adds unusable object states (not yet opened object), must be overridden (but there is no way to spell that requirement), must call to the parent's Open (but. again, no way to ensure that). Not every instance of bad design is due to the programmer's malice. P.S. With MD Open will dispatch on File and on Path (path must be MI from character set and a path|plain name|volume and absolute|relative hierarchies) and, possibly, on additional parameter types. All variants must be overridden!.. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-22 8:02 ` Dmitry A. Kazakov @ 2014-04-22 8:30 ` Shark8 2014-04-22 9:14 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-22 8:30 UTC (permalink / raw) On 22-Apr-14 02:02, Dmitry A. Kazakov wrote: > But there should be no Open operation at all. Why not? It seems to me that Open could be ideal for some object, like say an object representing flood-gates, or an internally used operation for an "e-mail reader", or dozens of other things (perhaps file processing [e.g. Get_File_List, Filter, Open as basic 'operations' of the processor]). > The object must be functional in each its state. Open is not an > operation it is a part of the object's constructor. Again, see the above. -- I realize you're talking about _files_, but there's many more things that could need an 'open' than just files. {Moreover, 'open' might even be hidden in the implementation.} > This is another language problem that Ada forces you to introduce Open, > which adds unusable object states (not yet opened object), must be > overridden (but there is no way to spell that requirement), must call > to the parent's Open (but. again, no way to ensure that). Not entirely true; with pre/post conditions, and perhaps type-invariants you can prohibit such states from being entered (which will result in an exception). ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-22 8:30 ` Shark8 @ 2014-04-22 9:14 ` Dmitry A. Kazakov 2014-04-22 23:23 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-22 9:14 UTC (permalink / raw) On Tue, 22 Apr 2014 02:30:17 -0600, Shark8 wrote: > On 22-Apr-14 02:02, Dmitry A. Kazakov wrote: >> But there should be no Open operation at all. > > Why not? > It seems to me that Open could be ideal for some object, like say an > object representing flood-gates, or an internally used operation for an > "e-mail reader", or dozens of other things (perhaps file processing > [e.g. Get_File_List, Filter, Open as basic 'operations' of the processor]). This is a completely irrelevant case. I talked (and I believe Randy did too) about Open like file open and hence the problem that it cannot be inherited with consequent maintenance problems for clients. >> This is another language problem that Ada forces you to introduce Open, >> which adds unusable object states (not yet opened object), must be >> overridden (but there is no way to spell that requirement), must call >> to the parent's Open (but. again, no way to ensure that). > > Not entirely true; with pre/post conditions, and perhaps type-invariants > you can prohibit such states from being entered (which will result in an > exception). Which is exactly the problem - this introduces erroneous states, where there should be none. From the SW design POV there shall be no way to create a closed file, an uninitialized widget, a float with the FPU turned off etc. The elementary principle of SW design is that the program must be functional in each of its states., in other words be a correct program. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-22 9:14 ` Dmitry A. Kazakov @ 2014-04-22 23:23 ` Randy Brukardt 2014-04-23 7:45 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-22 23:23 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:10o6qo98dwzjs$.rdpzvq7w1lep.dlg@40tude.net... ... > Which is exactly the problem - this introduces erroneous states, where > there should be none. From the SW design POV there shall be no way to > create a closed file, an uninitialized widget, a float with the FPU turned > off etc. I suspect that in the case of files, that would be too limiting to be of much use. One could not have a container (or array) of files, for instance, because there would be no way to provide the file names to each element before it existed. You would have resort to using dynamic allocation for almost all uses, and that would be a giant step backwards for an Ada-like language. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-22 23:23 ` Randy Brukardt @ 2014-04-23 7:45 ` Dmitry A. Kazakov 2014-04-23 19:43 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 7:45 UTC (permalink / raw) On Tue, 22 Apr 2014 18:23:19 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:10o6qo98dwzjs$.rdpzvq7w1lep.dlg@40tude.net... > ... >> Which is exactly the problem - this introduces erroneous states, where >> there should be none. From the SW design POV there shall be no way to >> create a closed file, an uninitialized widget, a float with the FPU turned >> off etc. > > I suspect that in the case of files, that would be too limiting to be of > much use. One could not have a container (or array) of files, for instance, > because there would be no way to provide the file names to each element > before it existed. Firstly, this is another language problem, e.g. lack of user-defined aggregates and user-defined array constructors. Secondly, there is a pattern for this. I am using a stock object to initialize such things. Another example where this is needed is a handle wrapping a non null pointer: type Safe_Handle (<>) is new Ada.Finalization.Controlled with private; ... private type Safe_Handle is new Ada.Finalization.Controlled with Object : non null access Object_Type'Class := Stock_Object'Access; end record; In the case of files there already is such stick object: /dev/null. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 7:45 ` Dmitry A. Kazakov @ 2014-04-23 19:43 ` Shark8 2014-04-23 20:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-23 19:43 UTC (permalink / raw) On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: > In the case of files there already is such stick object: /dev/null. I think there's a problem with that assertion > C:\Programming\Projects\SiennaSCL\src>cd /dev/null > The system cannot find the path specified. See? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 19:43 ` Shark8 @ 2014-04-23 20:00 ` Dmitry A. Kazakov 2014-04-23 21:28 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 20:00 UTC (permalink / raw) On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: > On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >> In the case of files there already is such stick object: /dev/null. > > I think there's a problem with that assertion >> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >> The system cannot find the path specified. > > See? Path /= File -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 20:00 ` Dmitry A. Kazakov @ 2014-04-23 21:28 ` Shark8 2014-04-24 7:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-23 21:28 UTC (permalink / raw) On 23-Apr-14 14:00, Dmitry A. Kazakov wrote: > On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: > >> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >>> In the case of files there already is such stick object: /dev/null. >> >> I think there's a problem with that assertion >>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >>> The system cannot find the path specified. >> >> See? > > Path /= File Not much different: C:\Programming\Projects\SiennaSCL\src>type /dev/null The syntax of the command is incorrect. Besides, as there is no '/dev/' there can be no children [files or subdirs] thereof. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 21:28 ` Shark8 @ 2014-04-24 7:30 ` Dmitry A. Kazakov 2014-04-24 15:20 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-24 7:30 UTC (permalink / raw) On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote: > On 23-Apr-14 14:00, Dmitry A. Kazakov wrote: >> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: >> >>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >>>> In the case of files there already is such stick object: /dev/null. >>> >>> I think there's a problem with that assertion >>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >>>> The system cannot find the path specified. >>> >>> See? >> >> Path /= File > > Not much different: Decisively different. It would be trivial to implement Null_File_Type, provided there were Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage. If you don't mind being GNAT-locked, you can implement GNAT-specific Null_File of File_Type on top of GNAT implementation. For stream I/O everything is here. Root_Stream_Type is tagged. type Null_Stream_Type is new Root_Stream_Type with null record; overriding procedure Read ... overriding procedure Write ... Null_Stream : Null_Stream_Type; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 7:30 ` Dmitry A. Kazakov @ 2014-04-24 15:20 ` Shark8 2014-04-24 16:19 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-24 15:20 UTC (permalink / raw) On 24-Apr-14 01:30, Dmitry A. Kazakov wrote: > On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote: > >> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote: >>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: >>> >>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >>>>> In the case of files there already is such stick object: /dev/null. >>>> >>>> I think there's a problem with that assertion >>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >>>>> The system cannot find the path specified. >>>> >>>> See? >>> >>> Path /= File >> >> Not much different: > > Decisively different. > > It would be trivial to implement Null_File_Type, provided there were > Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage. > > If you don't mind being GNAT-locked, you can implement GNAT-specific > Null_File of File_Type on top of GNAT implementation. > > For stream I/O everything is here. Root_Stream_Type is tagged. > > type Null_Stream_Type is new Root_Stream_Type with null record; > overriding procedure Read ... > overriding procedure Write ... > > Null_Stream : Null_Stream_Type; > You're completely missing the point -- it wasn't about a null-file, it was about assuming all computers are *nix. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 15:20 ` Shark8 @ 2014-04-24 16:19 ` Dmitry A. Kazakov 2014-04-24 16:50 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-24 16:19 UTC (permalink / raw) On Thu, 24 Apr 2014 09:20:52 -0600, Shark8 wrote: > On 24-Apr-14 01:30, Dmitry A. Kazakov wrote: >> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote: >> >>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote: >>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: >>>> >>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >>>>>> In the case of files there already is such stick object: /dev/null. >>>>> >>>>> I think there's a problem with that assertion >>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >>>>>> The system cannot find the path specified. >>>>> >>>>> See? >>>> >>>> Path /= File >>> >>> Not much different: >> >> Decisively different. >> >> It would be trivial to implement Null_File_Type, provided there were >> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage. >> >> If you don't mind being GNAT-locked, you can implement GNAT-specific >> Null_File of File_Type on top of GNAT implementation. >> >> For stream I/O everything is here. Root_Stream_Type is tagged. >> >> type Null_Stream_Type is new Root_Stream_Type with null record; >> overriding procedure Read ... >> overriding procedure Write ... >> >> Null_Stream : Null_Stream_Type; > > You're completely missing the point -- it wasn't about a null-file, it > was about assuming all computers are *nix. Where was this assumed? /dev/null was an example of a file which could serve the purpose. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 16:19 ` Dmitry A. Kazakov @ 2014-04-24 16:50 ` Shark8 2014-04-24 16:57 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-24 16:50 UTC (permalink / raw) On 24-Apr-14 10:19, Dmitry A. Kazakov wrote: > On Thu, 24 Apr 2014 09:20:52 -0600, Shark8 wrote: > >> On 24-Apr-14 01:30, Dmitry A. Kazakov wrote: >>> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote: >>> >>>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote: >>>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: >>>>> >>>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >>>>>>> In the case of files there already is such stick object: /dev/null. >>>>>> >>>>>> I think there's a problem with that assertion >>>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >>>>>>> The system cannot find the path specified. >>>>>> >>>>>> See? >>>>> >>>>> Path /= File >>>> >>>> Not much different: >>> >>> Decisively different. >>> >>> It would be trivial to implement Null_File_Type, provided there were >>> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage. >>> >>> If you don't mind being GNAT-locked, you can implement GNAT-specific >>> Null_File of File_Type on top of GNAT implementation. >>> >>> For stream I/O everything is here. Root_Stream_Type is tagged. >>> >>> type Null_Stream_Type is new Root_Stream_Type with null record; >>> overriding procedure Read ... >>> overriding procedure Write ... >>> >>> Null_Stream : Null_Stream_Type; >> >> You're completely missing the point -- it wasn't about a null-file, it >> was about assuming all computers are *nix. > > Where was this assumed? /dev/null was an example of a file which could > serve the purpose. > The assumption is implicit in your example: __/dev/null__, see? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 16:50 ` Shark8 @ 2014-04-24 16:57 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-24 16:57 UTC (permalink / raw) On Thu, 24 Apr 2014 10:50:49 -0600, Shark8 wrote: > On 24-Apr-14 10:19, Dmitry A. Kazakov wrote: >> On Thu, 24 Apr 2014 09:20:52 -0600, Shark8 wrote: >> >>> On 24-Apr-14 01:30, Dmitry A. Kazakov wrote: >>>> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote: >>>> >>>>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote: >>>>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote: >>>>>> >>>>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote: >>>>>>>> In the case of files there already is such stick object: /dev/null. >>>>>>> >>>>>>> I think there's a problem with that assertion >>>>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null >>>>>>>> The system cannot find the path specified. >>>>>>> >>>>>>> See? >>>>>> >>>>>> Path /= File >>>>> >>>>> Not much different: >>>> >>>> Decisively different. >>>> >>>> It would be trivial to implement Null_File_Type, provided there were >>>> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage. >>>> >>>> If you don't mind being GNAT-locked, you can implement GNAT-specific >>>> Null_File of File_Type on top of GNAT implementation. >>>> >>>> For stream I/O everything is here. Root_Stream_Type is tagged. >>>> >>>> type Null_Stream_Type is new Root_Stream_Type with null record; >>>> overriding procedure Read ... >>>> overriding procedure Write ... >>>> >>>> Null_Stream : Null_Stream_Type; >>> >>> You're completely missing the point -- it wasn't about a null-file, it >>> was about assuming all computers are *nix. >> >> Where was this assumed? /dev/null was an example of a file which could >> serve the purpose. > > The assumption is implicit in your example: > __/dev/null__, see? Nope. " ex·am·ple (ĭg-zăm′pəl) n. 1. One that is representative of a group as a whole: the squirrel, an example of a rodent; introduced each new word with examples of its use." Here is no assumption that all rodents live on trees, though some squirrels do. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-18 21:28 ` Randy Brukardt 2014-04-19 8:14 ` Niklas Holsti @ 2014-04-19 10:02 ` Georg Bauhaus 1 sibling, 0 replies; 240+ messages in thread From: Georg Bauhaus @ 2014-04-19 10:02 UTC (permalink / raw) On 18/04/14 23:28, Randy Brukardt wrote: > I'd prefer a much simpler declaration of inheritance, something like: > type Child is new Parent with ... > with inherits => Foo, Bar, Blech; > > where names not listed are hidden from all visibility unless overridden. FTR, Eiffel has something like this, it's called Feature Adaptation. Specifically, Eiffel allows renaming primitive operations on this occasion. class Child inherit Parent redefine Foo, Bar end rename Blech as Sheet_Metal end is ... Feature_adaptation ::= [Undefine] [Redefine] [Rename] [New_exports] [Select] ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 9:20 ` Shark8 2014-03-27 21:50 ` Randy Brukardt @ 2014-03-27 22:06 ` Randy Brukardt 2014-03-28 5:23 ` Shark8 1 sibling, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-03-27 22:06 UTC (permalink / raw) "Shark8" <OneWingedShark@gmail.com> wrote in message news:x9RYu.3020$XJ3.767@fx09.iad... I seem to have lost the rest of this, here's the reply to the rest: ... >> I think the problem is mainly going to be political rather than >> technical. >> The solution requires defining a large set of new packages that echo >> functionality already in the language, and that would not be used by the >> sorts of safety-critical applications that the paying customers use. >> (They're not using Text_IO or Unbounded_Strings or Directories or ...). >> That's going to make changes in this area a tough sell, I fear. Hope I'm >> wrong. > > That's rather sad; I'd hope for Ada to be a technically superior > language -- IMO, it already is in several respects... but that's no reason > to slack off and not strive for higher quality. Keep in mind that Standards of all sorts are as much political as technical. If there is no political will (as with ASIS), the technical part doesn't matter. Most vendors have not had much demand for Wide_Character etc., so the interest in it is lukewarm at best. One example: I've never been able to convince anyone to write any ACATS tests on internationalization in identifiers -- so there are none. (As such, I wouldn't depend on it working the same in different compilers.) > ------------ > Any comment on idea #2 or #3? #2 looks like lipstick on a pig to me - as you know my thinking on interfaces. If we really were going to extend multiple inheritance (something I'd personally be against), I'd suggest just allowing it everywhere -- in which case abstract types do everything you want and interfaces per-se become unnecessary. There are nasty semantic problems with that, and it would probably cause serious incompatibilities -- but I see little point in duplicating the functionality. #3 I don't understand. If you want the index/cursor, use that form. If you don't need it, then use the object form. I can't see any sensible way of using the index/cursor without knowing the type/number of indexes/cursors -- and if you need to know that, you already know enough to use the index/cursor form. We already have attributes and functions so you don't need to mention the actual bounds, so I don't see any gain here. i.e. for E of Arr_Obj loop E := Arr_Obj(E'Index + 1) + E; end loop; is already assuming a lot about the type and form of the index. Why hide that then? for I in Arr_Obj'range loop Arr_Obj(I) := Arr_Obj(I+1) + Arr_Obj(I); end loop; is a lot clearer as to what's going on. Even better if we adopted the in-place add attribute: for I in Arr_Obj'range loop Arr_Obj(I)'Add (Arr_Obj(I+1)); end loop; Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 22:06 ` Randy Brukardt @ 2014-03-28 5:23 ` Shark8 0 siblings, 0 replies; 240+ messages in thread From: Shark8 @ 2014-03-28 5:23 UTC (permalink / raw) On 27-Mar-14 15:06, Randy Brukardt wrote: > #2 looks like lipstick on a pig to me - as you know my thinking on > interfaces. Why couldn't it all be done in such a manner as to avoid MI issues? Something like what we might use signature-packages for ensuring interfaces [functions/procedures] exist for some given type. EX: generic Type Element; Type Implementation; Function Pop (Object : in out Implementation) return Element; Procedure Push (Object : in out Implementation; Item : Element); -- ... package STACK is --.... end STACK; being essentially the same as abstract interface Implementation is private; Function Pop (Object : in out Implementation) return Element; Procedure Push (Object : in out Implementation; Item : Element); -- ... Though perhaps having a parameter of such an abstract-interface would make it prohibitive... ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik 2014-03-25 22:14 ` Simon Wright 2014-03-26 6:25 ` Shark8 @ 2014-03-26 8:17 ` Dmitry A. Kazakov 2014-03-26 9:02 ` J Kimball ` (2 more replies) 2014-03-30 12:28 ` francois_fabien ` (7 subsequent siblings) 10 siblings, 3 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-26 8:17 UTC (permalink / raw) On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: > I think that even a casual user of Ada should be able to influence somehow > the new version of Ada. I wonder what is high on your list of wishes for > Ada 202X? No. Casual users have casual ideas. Ada already suffered too much from casual additions. > I suspect many of the proposals could be tested in GNAT before being > introduced (or rejected) in the new version. One could add a switch to > GNAT indicating that we want to use some of the experimental features. Yes, an experimental sandbox is a good idea. However, better would be a compiler from a generalized and simpler language with Ada type system implemented as a library. Most of Ada complexity is due to irregularities and weaknesses of its type system. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 8:17 ` Dmitry A. Kazakov @ 2014-03-26 9:02 ` J Kimball 2014-03-26 9:27 ` Dmitry A. Kazakov ` (2 more replies) 2014-03-26 16:01 ` Anh Vo 2014-03-26 16:17 ` Stoik 2 siblings, 3 replies; 240+ messages in thread From: J Kimball @ 2014-03-26 9:02 UTC (permalink / raw) On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote: > On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: > >> I think that even a casual user of Ada should be able to influence somehow >> the new version of Ada. I wonder what is high on your list of wishes for >> Ada 202X? > > No. Casual users have casual ideas. Ada already suffered too much from > casual additions. Casual users may also not be content with the status quo and may be spending their non-casual time keeping up with advances in programming language design that could benefit the language where a non-casual user may not have any additional time—of no fault of his own, of course. > >> I suspect many of the proposals could be tested in GNAT before being >> introduced (or rejected) in the new version. One could add a switch to >> GNAT indicating that we want to use some of the experimental features. > > Yes, an experimental sandbox is a good idea. However, better would be a > compiler from a generalized and simpler language with Ada type system > implemented as a library. Most of Ada complexity is due to irregularities > and weaknesses of its type system. > A casual user may avoid Ada, never becoming a non-casual user when he encounters these irregularities becoming disenchanted. The wishlist should include ameliorating these irregularities, strengthen the type system and maybe introduce some of the fancy types that academics are using to enforce correctness. I have recognized your very conservative approach to changes in Ada over time. Do you just want a language that suits Dmitry only or something that may grow interest in the language? Of all the sugar that was added in 2012, not much of it is going to convince anyone to pick up Ada. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 9:02 ` J Kimball @ 2014-03-26 9:27 ` Dmitry A. Kazakov 2014-03-26 10:30 ` Marius Amado-Alves 2014-03-26 21:55 ` Simon Clubley 2014-03-26 15:03 ` G.B. 2014-03-26 22:00 ` Simon Clubley 2 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-26 9:27 UTC (permalink / raw) On Wed, 26 Mar 2014 04:02:07 -0500, J Kimball wrote: > On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote: >> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: >> >>> I think that even a casual user of Ada should be able to influence somehow >>> the new version of Ada. I wonder what is high on your list of wishes for >>> Ada 202X? >> >> No. Casual users have casual ideas. Ada already suffered too much from >> casual additions. > > Casual users may also not be content with the status quo and may be > spending their non-casual time keeping up with advances in programming > language design that could benefit the language where a non-casual user > may not have any additional time—of no fault of his own, of course. Casual language/compiler designers? I don't believe such exist. >>> I suspect many of the proposals could be tested in GNAT before being >>> introduced (or rejected) in the new version. One could add a switch to >>> GNAT indicating that we want to use some of the experimental features. >> >> Yes, an experimental sandbox is a good idea. However, better would be a >> compiler from a generalized and simpler language with Ada type system >> implemented as a library. Most of Ada complexity is due to irregularities >> and weaknesses of its type system. > > A casual user may avoid Ada, never becoming a non-casual user when he > encounters these irregularities becoming disenchanted. Language preferences is a mystery. I don't think people choose languages very rationally, even those who chose Ada. > The wishlist should > include ameliorating these irregularities, strengthen the type system and > maybe introduce some of the fancy types that academics are using to > enforce correctness. Yes, that is on the top of my personal list. However people understand different things under correctness. For example to me dynamic checks are opposite to correctness. How do you reconcile wishes to expand dynamic checks with wishes removing those altogether, in one list? > I have recognized your very conservative approach to changes in Ada over > time. I thought I was considered a rabid radical here. My approach would be to rework language foundations keeping the facade intact. Is that conservative? > Do you just want a language that suits Dmitry only or something that > may grow interest in the language? I am software designer, I am interested in a language that helps me with my work. Popularity is another thing. If you believe that Ada could gain popularity by making the language worse. Well, it is true that only a very bad language could become very popular. But poor quality alone does not guaranty the result. For example, Ada 2012 became definitely worse but barely more popular. It was not ingeniously bad. > Of all the sugar that was added in > 2012, not much of it is going to convince anyone to pick up Ada. Yep, nobody is satisfied. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 9:27 ` Dmitry A. Kazakov @ 2014-03-26 10:30 ` Marius Amado-Alves 2014-03-26 15:11 ` G.B. 2014-03-26 21:55 ` Simon Clubley 1 sibling, 1 reply; 240+ messages in thread From: Marius Amado-Alves @ 2014-03-26 10:30 UTC (permalink / raw) "only a very bad language could become very popular" (Kasakov) You gotta love Kasakov's truisms! FWIW I disagree that Ada 2012 is worse, I find a few 2012 things useful. But I agree that Ada "development" should stop. So my whish for Ada 202X is: no Ada 202X, please. It's time for a new, good, unpopular language. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 10:30 ` Marius Amado-Alves @ 2014-03-26 15:11 ` G.B. 0 siblings, 0 replies; 240+ messages in thread From: G.B. @ 2014-03-26 15:11 UTC (permalink / raw) On 26.03.14 11:30, Marius Amado-Alves wrote: > So my whish for Ada 202X is: no Ada 202X, please. > It's time for a new, good, unpopular language. Parallel loops are on the way, I guess, so something is to come. Other than these, language profiles can help, too! Some examples: - no public "access" (subp-pointers excluded?) - no anonymous types, - tasking restrictions less severe that RavenSPARK, ... ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 9:27 ` Dmitry A. Kazakov 2014-03-26 10:30 ` Marius Amado-Alves @ 2014-03-26 21:55 ` Simon Clubley 1 sibling, 0 replies; 240+ messages in thread From: Simon Clubley @ 2014-03-26 21:55 UTC (permalink / raw) On 2014-03-26, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > On Wed, 26 Mar 2014 04:02:07 -0500, J Kimball wrote: > >> On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote: >>> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: >>> >>>> I think that even a casual user of Ada should be able to influence somehow >>>> the new version of Ada. I wonder what is high on your list of wishes for >>>> Ada 202X? >>> >>> No. Casual users have casual ideas. Ada already suffered too much from >>> casual additions. >> >> Casual users may also not be content with the status quo and may be >> spending their non-casual time keeping up with advances in programming >> language design that could benefit the language where a non-casual user >> may not have any additional time¡Xof no fault of his own, of course. > > Casual language/compiler designers? I don't believe such exist. > And once again Dmitry, you are projecting _your_ experiences onto others. :-) I for once have designed and implemented compilers and interpreters in the past and the only reason I did it was for fun. (Hand crafted LL(1) recursive descent parsers/grammars if you are interested.) >> I have recognized your very conservative approach to changes in Ada over >> time. > > I thought I was considered a rabid radical here. My approach would be to > rework language foundations keeping the facade intact. Is that > conservative? > I think it's more the case that you come across as thinking that the world as experienced by Dmitry is the only world that exists. :-) I'll give you a example: _every_ time someone talks about getting data into a embedded board, you immediately assume they are going to use a ADC interface to accomplish the task (and start to criticise them or offer opinions based on that), even though you are told that many times people simply use a binary (low/high) purely digital interface to read data. You clearly use ADC interfaces a lot, but that doesn't mean it's the only possible way to read data into a embedded board. You also tend to be dismissive of approaches outside of your experience. For example, you seem to be very dismissive of the low cost ARM embedded boards as being toys (or similar wording) and cannot seem to see their value in some situations because you use big heavy duty mains operated equipment in your job. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 9:02 ` J Kimball 2014-03-26 9:27 ` Dmitry A. Kazakov @ 2014-03-26 15:03 ` G.B. 2014-03-26 22:00 ` Simon Clubley 2 siblings, 0 replies; 240+ messages in thread From: G.B. @ 2014-03-26 15:03 UTC (permalink / raw) On 26.03.14 10:02, J Kimball wrote: > On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote: >> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: >> >>> I think that even a casual user of Ada should be able to influence >>> somehow >>> the new version of Ada. I wonder what is high on your list of wishes for >>> Ada 202X? >> >> No. Casual users have casual ideas. Ada already suffered too much from >> casual additions. > > Casual users may also not be content with the status quo and may be > spending their non-casual time keeping up with advances in programming > language design that could benefit the language where a non-casual user > may not have any additional time—of no fault of his own, of course. Slight problem with Ada users who would be triggering language design. Consider these as premises: 1 - Industries depending on Ada consist of competitors. 2 - Language design requires co-operation of those in need of a common language. 3 - Commercial Ada support is considered good; they do take care of customers (while also steering language design...) 4 - Time and money is usually spent on projects and support. Conclusion: Industry, insofar as it depends on Ada, is a lame duck: If programmers (1) want a language feature, and they get past controlling (4), they first talk to (3), and (3), I imagine, will then have almost full control of the language situation. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 9:02 ` J Kimball 2014-03-26 9:27 ` Dmitry A. Kazakov 2014-03-26 15:03 ` G.B. @ 2014-03-26 22:00 ` Simon Clubley 2 siblings, 0 replies; 240+ messages in thread From: Simon Clubley @ 2014-03-26 22:00 UTC (permalink / raw) On 2014-03-26, J Kimball <spam@example.com> wrote: > > A casual user may avoid Ada, never becoming a non-casual user when he > encounters these irregularities becoming disenchanted. The wishlist should > include ameliorating these irregularities, strengthen the type system and > maybe introduce some of the fancy types that academics are using to enforce > correctness. > Do you know of any online research papers covering the academic research on these new kinds of types ? It's something I would like to do a bit of reading about to see if there's anything of practical interest coming out of this academic research. Thanks, Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 8:17 ` Dmitry A. Kazakov 2014-03-26 9:02 ` J Kimball @ 2014-03-26 16:01 ` Anh Vo 2014-03-26 17:04 ` Dmitry A. Kazakov 2014-03-26 16:17 ` Stoik 2 siblings, 1 reply; 240+ messages in thread From: Anh Vo @ 2014-03-26 16:01 UTC (permalink / raw) On Wednesday, March 26, 2014 1:17:39 AM UTC-7, Dmitry A. Kazakov wrote: > On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: > > > I suspect many of the proposals could be tested in GNAT before being > > introduced (or rejected) in the new version. One could add a switch to > > GNAT indicating that we want to use some of the experimental features. > > Yes, an experimental sandbox is a good idea. However, better would be a > compiler from a generalized and simpler language with Ada type system > implemented as a library. Most of Ada complexity is due to irregularities > and weaknesses of its type system. You sound like most Ada type systems are week. It is obviously not true. After all, one of strength of Ada is its types/subtypes. Indeed, I would not choose Ada 25 years ago if it is not the case. A. Vo ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 16:01 ` Anh Vo @ 2014-03-26 17:04 ` Dmitry A. Kazakov 2014-03-27 15:03 ` Dan'l Miller 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-26 17:04 UTC (permalink / raw) On Wed, 26 Mar 2014 09:01:56 -0700 (PDT), Anh Vo wrote: > On Wednesday, March 26, 2014 1:17:39 AM UTC-7, Dmitry A. Kazakov wrote: >> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: >> >>> I suspect many of the proposals could be tested in GNAT before being >>> introduced (or rejected) in the new version. One could add a switch to >>> GNAT indicating that we want to use some of the experimental features. >> >> Yes, an experimental sandbox is a good idea. However, better would be a >> compiler from a generalized and simpler language with Ada type system >> implemented as a library. Most of Ada complexity is due to irregularities >> and weaknesses of its type system. > > You sound like most Ada type systems are week. It is obviously not true. I didn't mean weakly typing, though Ada's type system has some problems with that as well. Main weakness of Ada type system is lack of abstraction mechanisms which leads to multiplying special cases increasing language complexity incredibly. > After all, one of strength of Ada is its types/subtypes. Indeed, I would > not choose Ada 25 years ago if it is not the case. Now is 2014 and there is still no ad-hoc subtypes and supertypes. Subtypes are still tightly coupled to the type representation. There is still no procedural [sub/super]types. Initialization/finalization is still a mess. Renaming to a subtype is still broken and so on and so forth. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 17:04 ` Dmitry A. Kazakov @ 2014-03-27 15:03 ` Dan'l Miller 2014-03-27 16:02 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Dan'l Miller @ 2014-03-27 15:03 UTC (permalink / raw) On Wednesday, March 26, 2014 12:04:44 PM UTC-5, Dmitry A. Kazakov wrote: > > Now is 2014 and there is still no ad-hoc subtypes and supertypes. Subtypes > are still tightly coupled to the type representation. There is still no > procedural [sub/super]types. Initialization/finalization is still a mess. > Renaming to a subtype is still broken and so on and so forth. Dmitry, for each of these 4 negatively-bashing topics above, please provide positively-enlightening details (e.g., revealing examples with lucid explanation) of precisely what is wrong with the following as well as the desired state that is impossible in Ada 2012 as defined: 1) how subtypes could be less-tightly coupled to the type [without damaging the rest of Ada]; 2) how procedural sub-/supertypes would differ from today's runtime polymorphism of subroutines in subtypes overriding same-named subroutines in supertypes [without damaging the rest of Ada]; 3) precisely in what ways could initialization & finalization be changed to dismantle the mess [without damaging the rest of Ada]; 4) how renaming to a subtype a subtype could be fixed [without damaging the rest of Ada] (or equivalently: what are your refutations to the ARG's current inhibition of renaming to a subtype, i.e., where did the ARG go excessively restrictive in their thinking regarding renaming to a subtype). ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 15:03 ` Dan'l Miller @ 2014-03-27 16:02 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-27 16:02 UTC (permalink / raw) On Thu, 27 Mar 2014 08:03:54 -0700 (PDT), Dan'l Miller wrote: > On Wednesday, March 26, 2014 12:04:44 PM UTC-5, Dmitry A. Kazakov wrote: >> >> Now is 2014 and there is still no ad-hoc subtypes and supertypes. Subtypes >> are still tightly coupled to the type representation. There is still no >> procedural [sub/super]types. Initialization/finalization is still a mess. >> Renaming to a subtype is still broken and so on and so forth. > > Dmitry, for each of these 4 negatively-bashing topics above, please > provide positively-enlightening details (e.g., revealing examples with > lucid explanation) of precisely what is wrong with the following as well > as the desired state that is impossible in Ada 2012 as defined: I am not a member of ARG. Even if I were, it would be pointless to make any language proposals in c.l.a. > 1) how subtypes could be less-tightly coupled to the type [without > damaging the rest of Ada]; Every aspect of a subtype must be formalized as an interface open to user implementation. Existing constructs must be treated as shortcuts providing predefined implementations of these interfaces. > 2) how procedural sub-/supertypes would differ from today's runtime > polymorphism of subroutines in subtypes overriding same-named subroutines > in supertypes [without damaging the rest of Ada]; They will not be access types. Which would eliminate need of accessibility checks in downward closures. Relation to dynamic polymorphism is not direct. One could consider classes of subprograms as polymorphic bodies with some argument type varying across the class. I didn't think much about it. > 3) precisely in what ways could initialization & finalization be changed > to dismantle the mess [without damaging the rest of Ada]; 1. Every type must support user-defined initialization (with arguments) and finalization; 2. This includes class-wide types; 3. User-defined initialization/finalization must be enforced; 4. Initialization roll-back (on exception) must be supported. > 4) how renaming to a subtype a subtype could be fixed [without damaging > the rest of Ada] (or equivalently: what are your refutations to the ARG's > current inhibition of renaming to a subtype, i.e., where did the ARG go > excessively restrictive in their thinking regarding renaming to a > subtype). Renaming must either respect declared constraints and bounds [including bounds shifts] or else reject them. It is intolerable that these are simply ignored. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 8:17 ` Dmitry A. Kazakov 2014-03-26 9:02 ` J Kimball 2014-03-26 16:01 ` Anh Vo @ 2014-03-26 16:17 ` Stoik 2014-03-26 17:15 ` Dmitry A. Kazakov ` (2 more replies) 2 siblings, 3 replies; 240+ messages in thread From: Stoik @ 2014-03-26 16:17 UTC (permalink / raw) W dniu środa, 26 marca 2014 09:17:39 UTC+1 użytkownik Dmitry A. Kazakov napisał: > On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: > > > > > I think that even a casual user of Ada should be able to influence somehow > > > the new version of Ada. I wonder what is high on your list of wishes for > > > Ada 202X? > > > > No. Casual users have casual ideas. Ada already suffered too much from > > casual additions. > I strongly disagree with the view. The casual additions to Ada were not from causal users, but from language designers. The casual ideas of casual users are very easy to reject or just disregard. On the other hand, the bunch of people that now influence the development of Ada is quite small, and if something is proposed, the discussion is mainly on problems that such an addition can cause. Ada, as a language, is now half-dead. There is just one compiler on the market, and the fact that some small company wants to use the language is already big news. It is still used as the first programming language at some universities, but it is more and more difficult to substantiate its use. The situation will not improve if the language is frozen. Although Ada has a lot of nice features and is still better constructed than some of the more popular languages, there is a lot that causes frustration for the users. I will comment on it more later on. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 16:17 ` Stoik @ 2014-03-26 17:15 ` Dmitry A. Kazakov 2014-03-26 18:04 ` G.B. 2014-03-26 21:06 ` Randy Brukardt 2 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-26 17:15 UTC (permalink / raw) On Wed, 26 Mar 2014 09:17:04 -0700 (PDT), Stoik wrote: > W dniu środa, 26 marca 2014 09:17:39 UTC+1 użytkownik Dmitry A. Kazakov napisał: >> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote: >> >>> I think that even a casual user of Ada should be able to influence somehow >>> the new version of Ada. I wonder what is high on your list of wishes for >>> Ada 202X? >> >> No. Casual users have casual ideas. Ada already suffered too much from >> casual additions. > > I strongly disagree with the view. The casual additions to Ada were not > from causal users, but from language designers. The casual ideas of casual > users are very easy to reject or just disregard. On the other hand, the > bunch of people that now influence the development of Ada is quite small, > and if something is proposed, the discussion is mainly on problems that > such an addition can cause. And the idea is to make it even more casual? > Ada, as a language, is now half-dead. There is just one compiler on the > market, and the fact that some small company wants to use the language is > already big news. It is still used as the first programming language at > some universities, > but it is more and more difficult to substantiate its use. The situation > will not improve if the language is frozen. It will not. But that does not imply that erratic changes would. IMO, Ada 2005 and 2012 tried exactly this - casual changes, borrowing [false] concepts from other [poorly designed] languages. > Although Ada has a lot of nice > features and is still better constructed than some of the more popular > languages, there is a lot that causes frustration for the users. Yes. But people disagree on *what* need to be done and *how* to get there. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 16:17 ` Stoik 2014-03-26 17:15 ` Dmitry A. Kazakov @ 2014-03-26 18:04 ` G.B. 2014-03-26 18:47 ` Simon Wright 2014-03-27 14:43 ` Jacob Sparre Andersen 2014-03-26 21:06 ` Randy Brukardt 2 siblings, 2 replies; 240+ messages in thread From: G.B. @ 2014-03-26 18:04 UTC (permalink / raw) On 26.03.14 17:17, Stoik wrote: > There is just one compiler on the market Do you have some numbers? I understand that besides GNAT, both ICC and Rational Apex (Atego) support Ada 2005 and there are some supported compilers for Ada 95+, from others. And, of course, what does the number 1 mean? There aren't that many different C compilers in use in the embedded market AFAICT. There is just one C# compiler AFAIK. In comparison, then, having just a few Ada compilers seems quite enough. IIRC, programs for VxWorks don't even need an Ada runtime to provide tasking support. Systems like these provide an opportunity for another profile, one that should make upgrading compilers easier. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 18:04 ` G.B. @ 2014-03-26 18:47 ` Simon Wright 2014-03-26 19:51 ` Georg Bauhaus 2014-03-27 14:43 ` Jacob Sparre Andersen 1 sibling, 1 reply; 240+ messages in thread From: Simon Wright @ 2014-03-26 18:47 UTC (permalink / raw) "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes: > IIRC, programs for VxWorks don't even need an Ada runtime to provide > tasking support. Systems like these provide an opportunity for another > profile, one that should make upgrading compilers easier. But they do need one for Ada tasking support! Tasking on VxWorks using Ada bindings of the VxWorks tasking primitives would have little if any benefit over the C version. No protected types for a start! No rendezvous! ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 18:47 ` Simon Wright @ 2014-03-26 19:51 ` Georg Bauhaus 0 siblings, 0 replies; 240+ messages in thread From: Georg Bauhaus @ 2014-03-26 19:51 UTC (permalink / raw) On 26/03/14 19:47, Simon Wright wrote: > "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes: > >> IIRC, programs for VxWorks don't even need an Ada runtime to provide >> tasking support. Systems like these provide an opportunity for another >> profile, one that should make upgrading compilers easier. > > But they do need one for Ada tasking support! > > Tasking on VxWorks using Ada bindings of the VxWorks tasking primitives > would have little if any benefit over the C version. No protected types > for a start! No rendezvous! You are right, I was actually thinking of “no_task_types”. What I remembered was a talk by someone whose team did a VxWorks project for a British railroad something, explaining how they would wrap a process in a "VxWorks procedure", written in Ada. So, there would be protected types, I guess. Nevertheless, there is much that makes Ada different solely because of its fundamental type system: The most recent MS-Word/Outlook bug is another instance of errors that keep being caused by, as the CVE entry explains, a language that has no bounds checking for indexing arrays. Side note: SPARK rests on top of things expressed and expressible in Ada in its (almost) unique ways, in the small, and without pointers. An Ada profile for even sequential programs only is worth money. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 18:04 ` G.B. 2014-03-26 18:47 ` Simon Wright @ 2014-03-27 14:43 ` Jacob Sparre Andersen 2014-03-27 22:50 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Jacob Sparre Andersen @ 2014-03-27 14:43 UTC (permalink / raw) G.B. <rm-dash-bau-haus@dash.futureapps.de> writes: > On 26.03.14 17:17, Stoik wrote: >> There is just one compiler on the market > > Do you have some numbers? I understand that besides GNAT, both ICC and > Rational Apex (Atego) support Ada 2005 and there are some supported > compilers for Ada 95+, from others. Stoik exaggerates the number of Ada compilers slightly... At the moment there are no Ada (2012) compilers available on the market. GNAT is marketed as an Ada 2012 compiler, but they haven't managed to get their handling of synchronized interfaces (from Ada 2005) working yet, so I think calling it an Ada compiler is cheating. Calling it an Ada 95 compiler is fair though. As there is no ACATS for Ada (2012) or Ada 2005, it is difficult for us customers to be sure of the state of the compilers we have to choose between. My three big wishes for Ada are that: 1) ACATS is updated to match the current Ada standard. 2) Any new standard is published _with_ a matching edition of ACATS. 3) The ARG establishes a process for expanding ACATS with user-provided examples. Greetings, Jacob -- Black Hole: Where the universe made a Divide by Zero. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 14:43 ` Jacob Sparre Andersen @ 2014-03-27 22:50 ` Randy Brukardt 2014-03-28 5:22 ` J-P. Rosen 2014-03-28 7:54 ` Jacob Sparre Andersen 0 siblings, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-03-27 22:50 UTC (permalink / raw) "Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message news:87bnwrn1m9.fsf@adaheads.sparre-andersen.dk... ... > As there is no ACATS for Ada (2012) or Ada 2005, it is difficult for us > customers to be sure of the state of the compilers we have to choose > between. Huh? ACATS 3.0 for Ada 2005 has been available since 2008. An updated version 3.1 was issued in January, for use aftter April 1st. It's not as complete as one might like, but it surely exists and tests all of the really important new features of Ada 2005. > My three big wishes for Ada are that: > > 1) ACATS is updated to match the current Ada standard. ACATS 4.0 is under active development and should be released in the next few months. I just released the first snapshot last week, see http://www.ada-auth.org/acats.html. > 2) Any new standard is published _with_ a matching edition of ACATS. That's of course impractical as the same person (that is, me) is responsible for both. Finishing up a standard is a full time job. Doing the ACATS afterwards works well because it provides me something to do in between major Standards work. Else I'd have to get a real job and would most likely be unavailable for future work of any kind. The ARG has a discussion item on the agenda for the next meeting as to whether we should require ACATS tests from ARG members, which would certainly decrease the time lag. But it also has the possibility of preventing a lot of work on the standard, by making it many times more difficult for simpler issues. Several ARG members have indicated that they have no interest in writing ACATS tests, so we would stand to lose participation. (And we need more, not less participation!) > 3) The ARG establishes a process for expanding ACATS with user-provided > examples. The ACATS has *always* taken user-submitted tests. There are examples in the ACATS going back as far as 1990. You can find out about submitting test on the user-submitted test page: http://www.ada-auth.org/submit.html. Most the tests that I'm using to create ACATS 4.0 are user-submitted. As far as putting arbitrary user-provided stuff into the ACATS, that's a bad idea because it misinterprets the point of the ACATS. The ACATS is intended to support FORMAL conformity assessment testing for Ada. It's NOT about finding bugs in compilers (although it certainly does do that). ACATS tests have to be portable to all reasonable implementations of Ada (or documented as to what they don't apply to), they have to include appropriate pass/fail information (and be self-checking if executable), and so on. ACATS tests get formal maintenance, with a defined dispute procedure and defined change mechanism. This could be overwhelmed if lower-quality tests flooded the test suite. That said, it would be great if someone created a lightly-managed repository of user-provided examples for Ada. I tried to create such a reposistory back in the Ada 9x days, but no one other than me wanted to contribute to it. Perhaps some other organization would have better luck. Randy Brukardt, ACAA Technical Agent. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 22:50 ` Randy Brukardt @ 2014-03-28 5:22 ` J-P. Rosen 2014-03-28 7:54 ` Jacob Sparre Andersen 1 sibling, 0 replies; 240+ messages in thread From: J-P. Rosen @ 2014-03-28 5:22 UTC (permalink / raw) Le 27/03/2014 23:50, Randy Brukardt a écrit : > The ACATS has *always* taken user-submitted tests. There are examples in the > ACATS going back as far as 1990. Even before, I remember submitting tasking tests in 1984... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 22:50 ` Randy Brukardt 2014-03-28 5:22 ` J-P. Rosen @ 2014-03-28 7:54 ` Jacob Sparre Andersen 2014-03-28 21:22 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Jacob Sparre Andersen @ 2014-03-28 7:54 UTC (permalink / raw) Randy Brukardt <randy@rrsoftware.com> wrote: > "Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message > news:87bnwrn1m9.fsf@adaheads.sparre-andersen.dk... > ... >> As there is no ACATS for Ada (2012) or Ada 2005, it is difficult for us >> customers to be sure of the state of the compilers we have to choose >> between. > > Huh? ACATS 3.0 for Ada 2005 has been available since 2008. Thanks for letting me know. I don't know how I have managed to miss it. I apologise for spreading incorrect information. :-( > An updated version 3.1 was issued in January, for use aftter April > 1st. It's not as complete as one might like, but it surely exists and > tests all of the really important new features of Ada 2005. Good to know. >> My three big wishes for Ada are that: >> >> 1) ACATS is updated to match the current Ada standard. > > ACATS 4.0 is under active development and should be released in the > next few months. I just released the first snapshot last week, see > http://www.ada-auth.org/acats.html. I'll take a look. >> 2) Any new standard is published _with_ a matching edition of ACATS. > > That's of course impractical as the same person (that is, me) is > responsible for both. Finishing up a standard is a full time > job. Doing the ACATS afterwards works well because it provides me > something to do in between major Standards work. Else I'd have to get > a real job and would most likely be unavailable for future work of any > kind. Good point. I appreciate your work on editing the standard. > The ARG has a discussion item on the agenda for the next meeting as to > whether we should require ACATS tests from ARG members, which would > certainly decrease the time lag. But it also has the possibility of > preventing a lot of work on the standard, by making it many times more > difficult for simpler issues. Several ARG members have indicated that > they have no interest in writing ACATS tests, so we would stand to > lose participation. (And we need more, not less participation!) Another good point. >> 3) The ARG establishes a process for expanding ACATS with >> user-provided examples. > > The ACATS has *always* taken user-submitted tests. There are examples > in the ACATS going back as far as 1990. You can find out about > submitting test on the user-submitted test page: > http://www.ada-auth.org/submit.html. Most the tests that I'm using to > create ACATS 4.0 are user-submitted. Ahh... Another bit of "secret" ACAA documentation. It looks like I should keep quiet about ACATS until I've expanded my study of the ada-auth.org web site. > As far as putting arbitrary user-provided stuff into the ACATS, that's > a bad idea because it misinterprets the point of the ACATS. I agree completely with you on that point. But even if the example the user starts out with isn't necessarily an ideal candidate for a formal conformity test, it might be possible to guide the author in that direction, such that the example can be transformed into a (number of) formal conformity test(s). > That said, it would be great if someone created a lightly-managed > repository of user-provided examples for Ada. I tried to create such a > reposistory back in the Ada 9x days, but no one other than me wanted > to contribute to it. Perhaps some other organization would have > better luck. Does that repository still exist? I think I know a number of Ada users, who would be happy to provide examples for such a repository. Greetings, Jacob (just another Ada user) -- »What fun is it being "cool" if you can't wear a sombrero?« ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-28 7:54 ` Jacob Sparre Andersen @ 2014-03-28 21:22 ` Randy Brukardt 0 siblings, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-03-28 21:22 UTC (permalink / raw) "Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message news:877g7en4gy.fsf@adaheads.sparre-andersen.dk... > Randy Brukardt <randy@rrsoftware.com> wrote: ... >> That said, it would be great if someone created a lightly-managed >> repository of user-provided examples for Ada. I tried to create such a >> reposistory back in the Ada 9x days, but no one other than me wanted >> to contribute to it. Perhaps some other organization would have >> better luck. > > Does that repository still exist? I think I know a number of Ada users, > who would be happy to provide examples for such a repository. It never really got off the ground, so it never had an on-line version. If it had, it would have been updated manually, which needs a volunteer to manage. There are certainly better solutions available now, but it will take someone to manage it. A lot of the tests I had then are now covered by the ACATS in some fashion, so there isn't quite the need to have them available that there was in the early 1990s. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 16:17 ` Stoik 2014-03-26 17:15 ` Dmitry A. Kazakov 2014-03-26 18:04 ` G.B. @ 2014-03-26 21:06 ` Randy Brukardt 2014-03-26 23:15 ` J Kimball ` (2 more replies) 2 siblings, 3 replies; 240+ messages in thread From: Randy Brukardt @ 2014-03-26 21:06 UTC (permalink / raw) "Stoik" <staszek.goldstein@gmail.com> wrote in message news:ea073fca-c607-476c-8c0b-81e2da1686b1@googlegroups.com... ... > Although Ada has a lot of nice features and is still better constructed > than > some of the more popular languages, there is a lot that causes frustration > for the users. I will comment on it more later on. Commenting here is precisely the problem. Most of the user contacts that the ARG has is third-hand at best. (Combating that is one of the reasons I hang out here.) We really don't have the clear of an idea of what other Ada users want. I know I draw on my own experience far more than probably is healthy. Moreover, we've been asking for years for users to show us the problems that they cannot solve with Ada (now Ada 2012), so that we can look at possible solutions. That's one of the major purposes of the Ada-Comment mailing list. A few people do that, but it's not many. You don't have to be a language designer to do that; indeed, we'd rather you didn't try to invent language features to solve the problem, since those ideas often obscure the actual problem. Of course, we might determine that Ada 2012 already can solve the problem sensibly - or that we don't consider it important enough - but problems that we don't hear about have a near 100% chance of not being addressed. This is probably a good time to remind everyone that the Ada-Comment mailing list is open to everyone. It's for comments and discussion on the Ada language and it's Standard, not particular implementations of Ada. (Leave your gripes about AdaCore here, please. :-) You can find instructions about joining the list at http://www.adaic.org/resources/add_content/standards/articles/comment.html. Of course, that is not to say that discussion here isn't useful when one wants to know if they are alone with a concern or the like. But please don't assume that just because something is said here it is going to get back to the ARG and have an impact on future language standards. (Occassionally, someone has taken a discussion here back to Ada-Comment, but no one ought to assume that will happen. If you really care, do it yourself!) Randy Brukardt, ARG Editor. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 21:06 ` Randy Brukardt @ 2014-03-26 23:15 ` J Kimball 2014-03-27 8:26 ` Dmitry A. Kazakov 2014-04-29 14:26 ` Tero Koskinen 2 siblings, 0 replies; 240+ messages in thread From: J Kimball @ 2014-03-26 23:15 UTC (permalink / raw) On 03/26/2014 04:06 PM, Randy Brukardt wrote: > "Stoik" <staszek.goldstein@gmail.com> wrote in message > news:ea073fca-c607-476c-8c0b-81e2da1686b1@googlegroups.com... > .... >> Although Ada has a lot of nice features and is still better constructed >> than >> some of the more popular languages, there is a lot that causes frustration >> for the users. I will comment on it more later on. > > Commenting here is precisely the problem. Most of the user contacts that the > ARG has is third-hand at best. (Combating that is one of the reasons I hang > out here.) We really don't have the clear of an idea of what other Ada users > want. I know I draw on my own experience far more than probably is healthy. > > Moreover, we've been asking for years for users to show us the problems that > they cannot solve with Ada (now Ada 2012), so that we can look at possible > solutions. That's one of the major purposes of the Ada-Comment mailing list. > A few people do that, but it's not many. You don't have to be a language > designer to do that; indeed, we'd rather you didn't try to invent language > features to solve the problem, since those ideas often obscure the actual > problem. Of course, we might determine that Ada 2012 already can solve the > problem sensibly - or that we don't consider it important enough - but > problems that we don't hear about have a near 100% chance of not being > addressed. > > This is probably a good time to remind everyone that the Ada-Comment mailing > list is open to everyone. It's for comments and discussion on the Ada > language and it's Standard, not particular implementations of Ada. (Leave > your gripes about AdaCore here, please. :-) You can find instructions about > joining the list at > http://www.adaic.org/resources/add_content/standards/articles/comment.html. > > Of course, that is not to say that discussion here isn't useful when one > wants to know if they are alone with a concern or the like. But please don't > assume that just because something is said here it is going to get back to > the ARG and have an impact on future language standards. (Occassionally, > someone has taken a discussion here back to Ada-Comment, but no one ought to > assume that will happen. If you really care, do it yourself!) > > Randy Brukardt, ARG Editor. > > That's great. I know there are a lot of ideas out there, but the nebulous task of communicating it to ARG has prohibited moving on them. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 21:06 ` Randy Brukardt 2014-03-26 23:15 ` J Kimball @ 2014-03-27 8:26 ` Dmitry A. Kazakov 2014-03-27 10:54 ` Georg Bauhaus 2014-03-27 21:35 ` Randy Brukardt 2014-04-29 14:26 ` Tero Koskinen 2 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-27 8:26 UTC (permalink / raw) On Wed, 26 Mar 2014 16:06:18 -0500, Randy Brukardt wrote: > Commenting here is precisely the problem. But people don't post/read AI and Ada-Comment preferring c.l.a because Usenet group is more comfortable and easier to use for discussions and informal exchange. If you want to make Ada-Comment more vital move it to Usenet, Web group etc. Though, isn't it so that Ada-Comment and AI are meant to be unwelcoming in order to filter traffic? Shouldn't there be forums to discuss technical issues separately from fundamental language concepts, ignoring distracting technicalities? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 8:26 ` Dmitry A. Kazakov @ 2014-03-27 10:54 ` Georg Bauhaus 2014-03-27 15:42 ` Dmitry A. Kazakov 2014-03-27 21:35 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Georg Bauhaus @ 2014-03-27 10:54 UTC (permalink / raw) On 27/03/14 09:26, Dmitry A. Kazakov wrote: > Though, isn't it so that Ada-Comment and AI are meant to be > unwelcoming in order to filter traffic? comp.lang.ada could act as a filter and also as a place to get feedback first, before suggesting something on Ada-Comment. Since the Ada situation is such that one Ada vendor _is_ working on integrating Ada and Parasail, I imagine that not every suggestion WRT Ada is scrutinized with the help of the backwards compatibility sledgehammer only. Let me try one example that is about object construction: (a)compilers diagnose when a variable is used before initialization; (b) limited (derived) types do not have certain constructors that work up the derivation hierarchy; (c) construction then requires C-style discipline lest it be forgotten, possibly leading to erroneous execution. Then, ignoring the foreseeable backwards compatibility sledgehammer for the moment; also ignoring the C-style questionimg about how this is a real, pressing need of competent programmers blah-blah, I'll ask: Can there be a language rule that requires detection of initialization of all parts of said object before use? Is it worth it? Is it simple? Is it elegant? Is it explicit enough? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 10:54 ` Georg Bauhaus @ 2014-03-27 15:42 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-27 15:42 UTC (permalink / raw) On Thu, 27 Mar 2014 11:54:24 +0100, Georg Bauhaus wrote: > Can there be a language rule that requires detection of > initialization of all parts of said object before use? Yes > Is it worth it? Yes > Is it simple? Yes, because it would be a part of universal construction model. You place no-default-initialization in the root type, that is all. Compare it to (<>). > Is it elegant? Yes > Is it explicit enough? It is to late to make not initialized object syntactically more visible than they are. P.S. Most problems are intractable if you try to solve them by means of inference of the programmer's intent. Don't do that. Let the programmer manifest his will, like with initialization. This is why explicit interfaces are really important for making the language simpler. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-27 8:26 ` Dmitry A. Kazakov 2014-03-27 10:54 ` Georg Bauhaus @ 2014-03-27 21:35 ` Randy Brukardt 1 sibling, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-03-27 21:35 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:o55d8h8hmzjb.591frxr75ryx$.dlg@40tude.net... > On Wed, 26 Mar 2014 16:06:18 -0500, Randy Brukardt wrote: > >> Commenting here is precisely the problem. > > But people don't post/read AI and Ada-Comment preferring c.l.a because > Usenet group is more comfortable and easier to use for discussions and > informal exchange. > > If you want to make Ada-Comment more vital move it to Usenet, Web group > etc. Though, isn't it so that Ada-Comment and AI are meant to be > unwelcoming in order to filter traffic? I wouldn't characterize it as "meant to be unwelcoming"; after all, it was pretty much state-of-art when it originally was defined (in the early 1990s, for Ada 9x). It just hasn't changed much since then (last major change was in 1998, when I took over hosting it). The AI mechanism is even older; it's pretty similar to the mechanism used during Ada 83, so it dates back to at least the mid-1980s. The only major change there is the online formatted access to them (I added that a few years back), and as that is done by automatically adding formatting to plain text documents, it's not perfect. But it is true that we don't want lots of chit-chat on Ada-Comment. Everything said there goes into the permanent record somewhere, so off-topic stuff would become a problem. (That's the major reason that I still file these messages by hand; it's hard to imagine an automated system that could do as good a job of putting messages where they belong. We also do a level of triage on the comments, putting queries that are adequately answered on-line into ACs where they don't clutter the ARG's agenda. [Originally, everything posted to Ada-Comment had to be handled as an AI, which meant there was always a bunch of junk AIs on the agenda -- a lousy use of limited resources.) > Shouldn't there be forums to discuss technical issues separately from > fundamental language concepts, ignoring distracting technicalities? I'm not sure how one could "discuss technical issues" without considering "distracting technicalities". That's kind of the point, after all -- not everything that makes sense in the abstract makes sense for Ada because it has to fit into the existing type system somehow -- even ignoring absolute compatibility. For instance, a lot ideas don't make sense for by-copy types, or by-reference types, or discriminated types -- and those things are surely going to exist in a future Ada. We've occassionally talked about using other sorts of forums, but that tends to conflict with the mandate for a permanent record that's not tied to a particular technology [as technologies disappear over time -- but we still go back into the archives to understand old issues from time-to-time (it's too bad to we don't have the Ada 83 discussions on line, although apparently they're in a series of boxes in John Goodenough's office -- on printouts -- they're kinda hard to search).] For instance, a wiki might make sense for some tasks, but it doesn't appear that there would be any sensible way to extract the history from them for long-term use. You can do it using the platform, but when it goes away (and all of these things will go away someday, especially cloud platforms where you're dependent on others to keep it functioning) all of that is lost. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-26 21:06 ` Randy Brukardt 2014-03-26 23:15 ` J Kimball 2014-03-27 8:26 ` Dmitry A. Kazakov @ 2014-04-29 14:26 ` Tero Koskinen 2014-04-29 15:39 ` Dan'l Miller 2014-04-29 17:10 ` Simon Clubley 2 siblings, 2 replies; 240+ messages in thread From: Tero Koskinen @ 2014-04-29 14:26 UTC (permalink / raw) 26.3.2014 23:06, Randy Brukardt wrote: > Commenting here is precisely the problem. Most of the user contacts > that the ARG has is third-hand at best. (Combating that is one of > the reasons I hang out here.) We really don't have the clear of an > idea of what other Ada users want. I know I draw on my own experience > far more than probably is healthy. > > Moreover, we've been asking for years for users to show us the > problems that they cannot solve with Ada (now Ada 2012), so that we > can look at possible solutions. Not sure have it been proposed anywhere, but a common ABI (application binary interface) for the most popular platforms (32-bit ARM Linux, 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 Windows) would be nice. This way I could use binary libraries generated by one Ada compiler (version) with another Ada compiler (version) without providing full sources (or recompilation). Another thing is the lack of "modern" general purpose libraries for net/www stuff, embedded devices, various algorithms/data structures, etc. Those libraries won't necessarily need to be part of the standard. It is enough if they are just somehow freely available without extra cost. > Randy Brukardt, ARG Editor. Yours, Tero ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-29 14:26 ` Tero Koskinen @ 2014-04-29 15:39 ` Dan'l Miller 2014-04-29 17:10 ` Simon Clubley 1 sibling, 0 replies; 240+ messages in thread From: Dan'l Miller @ 2014-04-29 15:39 UTC (permalink / raw) 2014/04/29 09:26 Tero Koskinen: > 26.3.2014 23:06, Randy Brukardt wrote: > > Commenting here is precisely the problem. Most of the user contacts > > that the ARG has is third-hand at best. (Combating that is one of > > the reasons I hang out here.) We really don't have the clear of an > > idea of what other Ada users want. I know I draw on my own experience > > far more than probably is healthy. > > > > Moreover, we've been asking for years for users to show us the > > problems that they cannot solve with Ada (now Ada 2012), so that we > > can look at possible solutions. > Not sure have it been proposed anywhere, but a common ABI (application > binary interface) for the most popular platforms (32-bit ARM Linux, > 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 > Windows) would be nice. This way I could use binary libraries generated > by one Ada compiler (version) with another Ada compiler (version) > without providing full sources (or recompilation). This problemspace that Tero Koskinen mentions needs either a common ABI or better (i.e., portable beyond GNAT) compile-time code generation. C and GNAT rely on conditional compilation to select at compile-time alternative (run-time) source-code. C++ has been relying on poor-man's functional programming via meta template programming. Both of these are kludges for how the compile-time code-generation problemspace should be solved. Non-gnatprep Ada has been recommending alternative selection of entire child packages as a partial solution to this problemspace. What I envision as a robust complete solution to this problemspace is a revival of something like a.app from the 1980s/1990s Ada combined with multi-stage programming from MetaOCaml, where a Turing-complete imperative (not functional programming) Ada interpreter runs at compile time generating/selecting the next stage of(, say, run-time) source code (in 2-stage programming), which is then compiled by the Ada compiler. And okay, if not a full-fledged compile-time Ada interpreter within the Ada compiler, then drastic expansion somehow of Ada's (currently coarse-grained) selection of (whole) child packages on a per-architecture (or per-underlying-infrastructure, e.g., GUI library, GPU library, OS API) basis. C++'s concept-maps for the currently-postponed concepts might or might not be applicable here to map common upper-layer identifiers to a diversity of lower-layer identifiers that fan out to multiple underlying infrastructures (i.e., various software infrastructures and/or various hardware architectures). Or a Turing-complete a.app-successor might be the better full solution than C++'s concept maps for such adaptation of single portable upper layers of Ada source code to a diversity of unruly infrastructures underneath. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-29 14:26 ` Tero Koskinen 2014-04-29 15:39 ` Dan'l Miller @ 2014-04-29 17:10 ` Simon Clubley 2014-04-29 17:13 ` Tero Koskinen 1 sibling, 1 reply; 240+ messages in thread From: Simon Clubley @ 2014-04-29 17:10 UTC (permalink / raw) On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote: > > Not sure have it been proposed anywhere, but a common ABI (application > binary interface) for the most popular platforms (32-bit ARM Linux, > 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 > Windows) would be nice. This way I could use binary libraries generated > by one Ada compiler (version) with another Ada compiler (version) > without providing full sources (or recompilation). > That is simply not possible. Your list above includes different architectures (ARM and x86) with totally different instruction sets. The only way to support both architectures in the way you want would be fat object modules or fat libraries which contain both versions of a object module and that doesn't even address the issues below. However, even if you restrict yourself to x86/x86_64 then how do you handle the 32 bit versus 64 bit pointer size issue ? Do you only generate code for 32 bit x86 ? However, even if you restrict yourself to 32 bit x86 then those object modules will still have operating system specific components to them. How do you handle architecture/operating system specific issues such as exceptions ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-29 17:10 ` Simon Clubley @ 2014-04-29 17:13 ` Tero Koskinen 2014-04-29 19:42 ` Simon Clubley 0 siblings, 1 reply; 240+ messages in thread From: Tero Koskinen @ 2014-04-29 17:13 UTC (permalink / raw) 29.4.2014 20:10, Simon Clubley wrote: > On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote: >> >> Not sure have it been proposed anywhere, but a common ABI (application >> binary interface) for the most popular platforms (32-bit ARM Linux, >> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 >> Windows) would be nice. This way I could use binary libraries generated >> by one Ada compiler (version) with another Ada compiler (version) >> without providing full sources (or recompilation). >> > > That is simply not possible. > > Your list above includes different architectures (ARM and x86) with > totally different instruction sets. I meant a separate ABI for each platform. But for example, all Ada compilers targeting 32-bit ARM Linux should implement same ABI. In theory it should be relatively easy to say "all must use same ABI as gnat 4.9 currently uses". > > Simon. > Yours, Tero ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-29 17:13 ` Tero Koskinen @ 2014-04-29 19:42 ` Simon Clubley 0 siblings, 0 replies; 240+ messages in thread From: Simon Clubley @ 2014-04-29 19:42 UTC (permalink / raw) On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote: > 29.4.2014 20:10, Simon Clubley wrote: >> On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote: >>> >>> Not sure have it been proposed anywhere, but a common ABI (application >>> binary interface) for the most popular platforms (32-bit ARM Linux, >>> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 >>> Windows) would be nice. This way I could use binary libraries generated >>> by one Ada compiler (version) with another Ada compiler (version) >>> without providing full sources (or recompilation). >>> >> >> That is simply not possible. >> >> Your list above includes different architectures (ARM and x86) with >> totally different instruction sets. > > I meant a separate ABI for each platform. But for example, all > Ada compilers targeting 32-bit ARM Linux should implement same ABI. > Yes, that makes more sense. Sorry. :-) > In theory it should be relatively easy to say "all must use same ABI > as gnat 4.9 currently uses". > There's nothing easy about that unfortunately. There are multiple ABI levels here. Not only do you have the low level OS specific ABI, you also have a higher level Ada specific ABI (for tasking, exceptions, etc) with calls into the GNAT run time library. All of this would need to be formally documented in great detail so that, say, exceptions from code compiled using compiler A could pass a Ada exception up to a caller compiled using compiler B. Similar comments apply for other things, like tasking, which need runtime library support. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (2 preceding siblings ...) 2014-03-26 8:17 ` Dmitry A. Kazakov @ 2014-03-30 12:28 ` francois_fabien 2014-03-30 13:40 ` Luke A. Guest ` (2 more replies) 2014-04-02 16:21 ` Britt ` (6 subsequent siblings) 10 siblings, 3 replies; 240+ messages in thread From: francois_fabien @ 2014-03-30 12:28 UTC (permalink / raw) One wish to ease Input/output : To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 12:28 ` francois_fabien @ 2014-03-30 13:40 ` Luke A. Guest 2014-03-30 14:24 ` Simon Clubley ` (2 more replies) 2014-03-30 13:46 ` Simon Clubley 2014-03-30 19:02 ` Pascal Obry 2 siblings, 3 replies; 240+ messages in thread From: Luke A. Guest @ 2014-03-30 13:40 UTC (permalink / raw) <francois_fabien@hotmail.com> wrote: > One wish to ease Input/output : > To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", God no. This requires parsing the string in every call, the Ada does it no is superior. Plus it requires parameter passing from the right rather than the left. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 13:40 ` Luke A. Guest @ 2014-03-30 14:24 ` Simon Clubley 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 14:28 ` Simon Clubley 2014-03-31 15:39 ` Adam Beneschan 2 siblings, 1 reply; 240+ messages in thread From: Simon Clubley @ 2014-03-30 14:24 UTC (permalink / raw) On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: ><francois_fabien@hotmail.com> wrote: >> One wish to ease Input/output : >> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", > > God no. This requires parsing the string in every call, the Ada does it no > is superior. Plus it requires parameter passing from the right rather than > the left. The Ada way is ok for simple I/O. What about when you want to produce a formatted report ? Regardless of whether you keep the current I/O method only or add something printf style, it's far more logical and cleaner for the actual internal to external conversion to be conceptually a part of the data type rather than yet _another_ package within Text_IO. (Basically, you need a seriously enhanced version of 'Image with Text_IO providing the basic non datatype specific I/O framework and the data type itself doing the formatting/conversion to the requested output length, editing and precision when applicable.) This stuff belongs with the data type, not with some Text_IO package. The same types of comments apply to input as well. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 14:24 ` Simon Clubley @ 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 19:22 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Luke A. Guest @ 2014-03-30 18:48 UTC (permalink / raw) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: > On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: >> <francois_fabien@hotmail.com> wrote: >>> One wish to ease Input/output : >>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", >> >> God no. This requires parsing the string in every call, the Ada does it no >> is superior. Plus it requires parameter passing from the right rather than >> the left. > > The Ada way is ok for simple I/O. > > What about when you want to produce a formatted report ? Then you use the sub program conversions with field widths, ideally 'image should take field width and padding information as optional parameters. I see no problem. Luke ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 18:48 ` Luke A. Guest @ 2014-03-30 19:22 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-30 19:22 UTC (permalink / raw) On Sun, 30 Mar 2014 18:48:13 +0000 (UTC), Luke A. Guest wrote: > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >> On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: >>> <francois_fabien@hotmail.com> wrote: >>>> One wish to ease Input/output : >>>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", >>> >>> God no. This requires parsing the string in every call, the Ada does it no >>> is superior. Plus it requires parameter passing from the right rather than >>> the left. >> >> The Ada way is ok for simple I/O. >> >> What about when you want to produce a formatted report ? > > Then you use the sub program conversions with field widths, ideally 'image > should take field width and padding information as optional parameters. What for? Image produces a string, formatted output is done into a string. It makes little sense first to generate a string and then put it into another one. The could be done in just one step, e.g. http://www.dmitry-kazakov.de/ada/strings_edit.htm#Float_Edit -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 13:40 ` Luke A. Guest 2014-03-30 14:24 ` Simon Clubley @ 2014-03-30 14:28 ` Simon Clubley 2014-03-30 15:14 ` Peter Chapin 2014-03-30 18:48 ` Luke A. Guest 2014-03-31 15:39 ` Adam Beneschan 2 siblings, 2 replies; 240+ messages in thread From: Simon Clubley @ 2014-03-30 14:28 UTC (permalink / raw) On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: ><francois_fabien@hotmail.com> wrote: >> One wish to ease Input/output : >> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", > > God no. This requires parsing the string in every call, the Ada does it no > is superior. Plus it requires parameter passing from the right rather than > the left. Also, I'm not quite sure what you mean by the latter. As far as I can see, the parameter passing would be left to right, just as it is in C. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 14:28 ` Simon Clubley @ 2014-03-30 15:14 ` Peter Chapin 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 18:48 ` Luke A. Guest 1 sibling, 1 reply; 240+ messages in thread From: Peter Chapin @ 2014-03-30 15:14 UTC (permalink / raw) On 2014-03-30 10:28, Simon Clubley wrote: > Also, I'm not quite sure what you mean by the latter. As far as I can see, > the parameter passing would be left to right, just as it is in C. Typical C compilers push arguments onto the stack from right to left. This is done to support variable length parameter lists such as what printf() has. For example printf("%d\n", some_integer); The printf function expects to find a pointer to the format string on the top of the stack. It reads that string to find out what other arguments to expect and then it indexes down the stack to get them. If the compiler pushed arguments from left to right the critical pointer to the format string would be beneath an unknown number of other arguments. Standard C requires that functions with variable length parameter lists be prototyped (this is a break from pre-standard C). This gives compiler writers the option of using a different calling convention by default and something special for functions with variable length parameters, since the compiler can be sure such functions will be prototyped and thus known to the compiler. Some compilers do take advantage of this and will incorrectly compile calls to printf() if one does not #include <stdio.h> or otherwise provide a prototype for printf(). Peter ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 15:14 ` Peter Chapin @ 2014-03-30 18:48 ` Luke A. Guest 0 siblings, 0 replies; 240+ messages in thread From: Luke A. Guest @ 2014-03-30 18:48 UTC (permalink / raw) Peter Chapin <PChapin@vtc.vsc.edu> wrote: Thanks for that, I couldn't remember the details ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 14:28 ` Simon Clubley 2014-03-30 15:14 ` Peter Chapin @ 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 23:41 ` Simon Clubley 1 sibling, 1 reply; 240+ messages in thread From: Luke A. Guest @ 2014-03-30 18:48 UTC (permalink / raw) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: > On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: >> <francois_fabien@hotmail.com> wrote: >>> One wish to ease Input/output : >>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", >> >> God no. This requires parsing the string in every call, the Ada does it no >> is superior. Plus it requires parameter passing from the right rather than >> the left. > > Also, I'm not quite sure what you mean by the latter. As far as I can see, > the parameter passing would be left to right, just as it is in C. > > Simon. C uses vararga which are passed right to left as the varargs functions use thus right-ness to determine the number of parameters. Luke ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 18:48 ` Luke A. Guest @ 2014-03-30 23:41 ` Simon Clubley 0 siblings, 0 replies; 240+ messages in thread From: Simon Clubley @ 2014-03-30 23:41 UTC (permalink / raw) On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >> On 2014-03-30, Luke A Guest <laguest@archeia.com> wrote: >>> <francois_fabien@hotmail.com> wrote: >>>> One wish to ease Input/output : >>>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", >>> >>> God no. This requires parsing the string in every call, the Ada does it no >>> is superior. Plus it requires parameter passing from the right rather than >>> the left. >> >> Also, I'm not quite sure what you mean by the latter. As far as I can see, >> the parameter passing would be left to right, just as it is in C. >> >> Simon. > > > C uses vararga which are passed right to left as the varargs functions use > thus right-ness to determine the number of parameters. > Sorry, I understand what you are saying now. I thought you were talking about the way it was written in the source code, not the way the compiler generated the parameter passing code. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 13:40 ` Luke A. Guest 2014-03-30 14:24 ` Simon Clubley 2014-03-30 14:28 ` Simon Clubley @ 2014-03-31 15:39 ` Adam Beneschan 2 siblings, 0 replies; 240+ messages in thread From: Adam Beneschan @ 2014-03-31 15:39 UTC (permalink / raw) On Sunday, March 30, 2014 6:40:24 AM UTC-7, Luke A. Guest wrote: > > > One wish to ease Input/output : > > > To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", > > God no. This requires parsing the string in every call, the Ada does it no > is superior. I can't tell what you're trying to say here--it's not grammatical. If you're trying to say something along the lines of "the Ada way to write this", I'm not sure just what that is. I'm sure there are several opinions about what "the Ada way" is for this. > Plus it requires parameter passing from the right rather than > the left. No, it wouldn't require parameter passing like that at all. Some different mechanism would no doubt have to be invented, though. The original C didn't have function prototypes at all. Most of the time, you simply used the function, and the compiler would assume it existed. If the return type were something other than "int", you might have to write an "extern" declaration to tell the compiler the function existed and its return type, but you still didn't tell it anything about the parameters. The compiler assumed you knew the parameter types and got them right, and if you didn't, then you got to have fun debugging your error. But functions with variable numbers of argument like printf() could be made to work because the compiler would push the arguments on the stack right-to-left, and the printf() function would read them from the stack like that. But, certainly, if one were to design a mechanism to allow such parameter passing, one wouldn't be constrained to use the same mechanism adopted by an extremely low-level 1960s programming language like C. There are many other possibilities, such as pushing the number of parameters and the number of bytes in each passed value as hidden parameters on the stack. The assumption here would be that the printf function would be *declared* to take a variable-argument-list, and therefore the compiler would know, on *both* sides (when compiling the subprogram body, and when compiling the call), that the special mechanism for passing variable-argument lists would need to be in effect. This assumption was *not* true for the original C, which is why the right-to-left thing was necessary. In Java, for instance, methods with variable-length argument lists are just treated as arrays. So when you say System.out.printf("Count=%d value=%8.2f\n", someInteger, someFloat); printf will see two parameters: a String, and an array of two Objects, where the first element is an Integer and the second is a Float. (All "objects" in Java are descended from Object, and non-objects like "int" will be automatically converted to Integer objects in some contexts.) printf can then just traverse the array; it can also check to make sure the variable argument list has the correct number of parameters and parameter types. I'm not saying that Ada needs a feature like this, or that it should be implemented the way Java did it. I'm just saying that it clearly is *not* necessary to use right-to-left parameter passing in order to add a feature like this to the language. -- Adam ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 12:28 ` francois_fabien 2014-03-30 13:40 ` Luke A. Guest @ 2014-03-30 13:46 ` Simon Clubley 2014-03-30 19:02 ` Pascal Obry 2 siblings, 0 replies; 240+ messages in thread From: Simon Clubley @ 2014-03-30 13:46 UTC (permalink / raw) On 2014-03-30, francois_fabien@hotmail.com <francois_fabien@hotmail.com> wrote: > > One wish to ease Input/output : > To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", > We have just had that discussion a couple of weeks or so ago. :-) I also would like to see something like that in Ada, but I believe the actual formatting is a attribute of the data type and is not something which should be implemented within a I/O package as such. My general idea is that when you define a data type, you also add support for External_To_Internal and Internal_To_External conversions to the data type. At runtime, the Ada version of printf would call the Internal_To_External support code within the data type along with the fragment of the format for the entity in question (and which could include a optional display length and precision). Either a exception would be raised (if the requested conversion was invalid) or the formatted output would be returned to the Ada version of printf ready for direct inclusion in the output buffer. As was pointed out the last time I suggested this, if the format string was a literal, you could even check this at compile time, just as gcc does for a C program. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 12:28 ` francois_fabien 2014-03-30 13:40 ` Luke A. Guest 2014-03-30 13:46 ` Simon Clubley @ 2014-03-30 19:02 ` Pascal Obry 2014-03-30 19:33 ` Dmitry A. Kazakov 2 siblings, 1 reply; 240+ messages in thread From: Pascal Obry @ 2014-03-30 19:02 UTC (permalink / raw) Le dimanche 30 mars 2014 à 05:28 -0700, francois_fabien@hotmail.com a écrit : > One wish to ease Input/output : > To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", Well, this is possible in Ada with some coding of a package, one could write something like (maybe already implemented by someone, I remember a simple_io package or something like that): Formatted_Print ("%c %c %c %c %c \n %c %c %c %c %c \n" & Var1 & Var2 & Var3 & Var4 & Var5 & Var6 & Var7 & Var8); You just have to code the Formatted_Print routine once for all. No big deal: type Formatted_String is private; Format_Error : exception; function "&" (F : Formatted_String; V : Character) return Formatted_String; function "&" (F : Formatted_String; V : Integer) return Formatted_String; function "&" (F : Formatted_String; V : Float) return Formatted_String; ... procedure Formatted_Print (F : Formatted_String); procedure Formatted_Print (File : Text_IO.File_Type; F : Formatted_String); ... -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 19:02 ` Pascal Obry @ 2014-03-30 19:33 ` Dmitry A. Kazakov 2014-03-30 19:59 ` Pascal Obry 2014-04-05 8:28 ` Pascal Obry 0 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-30 19:33 UTC (permalink / raw) On Sun, 30 Mar 2014 21:02:00 +0200, Pascal Obry wrote: > Le dimanche 30 mars 2014 à 05:28 -0700, francois_fabien@hotmail.com a > écrit : >> One wish to ease Input/output : >> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", > > Well, this is possible in Ada with some coding of a package, one could > write something like (maybe already implemented by someone, I remember a > simple_io package or something like that): > > Formatted_Print > ("%c %c %c %c %c \n %c %c %c %c %c \n" > & Var1 & Var2 & Var3 & Var4 & Var5 & Var6 & Var7 & Var8); > > You just have to code the Formatted_Print routine once for all. No big > deal: > > type Formatted_String is private; > > Format_Error : exception; > > function "&" > (F : Formatted_String; V : Character) return Formatted_String; > function "&" > (F : Formatted_String; V : Integer) return Formatted_String; > function "&" > (F : Formatted_String; V : Float) return Formatted_String; > ... > > procedure Formatted_Print (F : Formatted_String); > > procedure Formatted_Print > (File : Text_IO.File_Type; > F : Formatted_String); I did such things, it is not so simple. You need a set of "seed" functions to produce initial Formatted_String, e.g. function "&" (L, R : Character) return Formatted_String; function "&" (L : Character; R : Integer) return Formatted_String; ... Or you have to use Empty_Formatted_String constant in each expression. Another consideration is efficiency, as it would keep on copying the string upon each concatenation. One method to deal with that is to use reference counting in Formatted_String. When the argument F has the reference count 1 it is updated in place and the result is returned. Otherwise F is cloned, the copy is updated and then returned. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 19:33 ` Dmitry A. Kazakov @ 2014-03-30 19:59 ` Pascal Obry 2014-03-31 15:13 ` Stoik 2014-04-05 8:28 ` Pascal Obry 1 sibling, 1 reply; 240+ messages in thread From: Pascal Obry @ 2014-03-30 19:59 UTC (permalink / raw) Le dimanche 30 mars 2014 à 21:33 +0200, Dmitry A. Kazakov a écrit : I did such things, it is not so simple. > Sure! You need a set of "seed" functions to produce initial Formatted_String, > e.g. > > function "&" (L, R : Character) return Formatted_String; > function "&" (L : Character; R : Integer) return Formatted_String; > ... > No since you always start with the Formatted_String (not derived from string). We need at least a function to create the formatted_string from a string: function "+" (Format : in String) return Formatted_String; Then: +"%c" & var Or you have to use Empty_Formatted_String constant in each expression. > > Another consideration is efficiency, as it would keep on copying the string > upon each concatenation. > Copies should be avoided by using a reference semantic. Note that I have declared Formatted_String as: type Formatted_String is private; Maybe it should be a tagged type. This type is a record with the format. The result (Unbounded_String?) and an index to the current format. That's what I'm thinking. Let's say we have: type Formatted_String is record Format : Unbounded_String; Index : Positive; Result : Unbounded_String; end record; Then +"%c %c" Set such record to ("%c %c", 1, "") Then with : & Var If Var is not a character => raise exception Let's say Var := 'x' If a char then the record becomes : ("%c %c", 3, "x") That's how I would do such implementation. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 19:59 ` Pascal Obry @ 2014-03-31 15:13 ` Stoik 2014-03-31 16:22 ` Pascal Obry ` (2 more replies) 0 siblings, 3 replies; 240+ messages in thread From: Stoik @ 2014-03-31 15:13 UTC (permalink / raw) W dniu niedziela, 30 marca 2014 21:59:26 UTC+2 użytkownik Pascal Obry napisał: > Le dimanche 30 mars 2014 à 21:33 +0200, Dmitry A. Kazakov a écrit : > > I did such things, it is not so simple. > > > > > Sure! > > > > You need a set of "seed" functions to produce initial Formatted_String, > > > e.g. > > > > > > function "&" (L, R : Character) return Formatted_String; > > > function "&" (L : Character; R : Integer) return Formatted_String; > > > ... > > > > > No since you always start with the Formatted_String (not derived from > > string). We need at least a function to create the formatted_string from > > a string: > > > > function "+" (Format : in String) return Formatted_String; > > > > Then: > > > > +"%c" & var > > > > Or you have to use Empty_Formatted_String constant in each expression. > > > > > > Another consideration is efficiency, as it would keep on copying the > > string > > > upon each concatenation. > > > > > Copies should be avoided by using a reference semantic. Note that I have > > declared Formatted_String as: > > > > type Formatted_String is private; > > > > Maybe it should be a tagged type. > > > > This type is a record with the format. The result (Unbounded_String?) > > and an index to the current format. That's what I'm thinking. > > > > Let's say we have: > > > > type Formatted_String is record > > Format : Unbounded_String; > > Index : Positive; > > Result : Unbounded_String; > > end record; > > > > Then > > > > +"%c %c" > > > > Set such record to ("%c %c", 1, "") > > > > Then with : & Var > > > > If Var is not a character => raise exception > > > > Let's say Var := 'x' > > > > If a char then the record becomes : ("%c %c", 3, "x") > > > > That's how I would do such implementation. > > > > > > -- > > Pascal Obry / Magny Les Hameaux (78) > > > > The best way to travel is by means of imagination > > > > http://v2p.fr.eu.org > > http://www.obry.net > > > > gpg --keyserver keys.gnupg.net --recv-key F949BD3B A clever use of & and + makes it possible to output complicated mixtures of elements of various types, so it seems that nothing needs to be added to the language (unless we have an elegant way of adding an "input" and "output" aspect to the type). On the other hand, there is clearly a need for one or more subprograms for the input of strings. Just now, we have three fairly convenient ways of inputing a line: procedure get_line (with the inconvenience of an additional parameter and the necessity of guessing the maximal length of the string), function get_line returning string (one usually needs to add a block to use it) or get_line returning unbounded_string (very convenient, may be not so efficient). What is needed are subprograms for entering a word (get_word) delimited by default by spaces. This is what cin from C++ does. All methods I know of (not requiring me to write the subprograms) is to enter the whole line and then to chop it, using either subprograms from GNAT library, or things like find_token, slice and delete. Getting a word from the input is so ubiquitous, that one should be able to do it very easily. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-31 15:13 ` Stoik @ 2014-03-31 16:22 ` Pascal Obry 2014-03-31 16:47 ` Pascal Obry 2014-03-31 18:59 ` Dmitry A. Kazakov 2 siblings, 0 replies; 240+ messages in thread From: Pascal Obry @ 2014-03-31 16:22 UTC (permalink / raw) Le lundi 31 mars 2014 à 08:13 -0700, Stoik a écrit : > A clever use of & and + makes it possible to output complicated mixtures of > elements of various types, so it seems that nothing needs to be added to the language Expect that it is quite difficult to handle the padding, the leading zeros, the alignment... All this can be specified in a C/C++ format string. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-31 15:13 ` Stoik 2014-03-31 16:22 ` Pascal Obry @ 2014-03-31 16:47 ` Pascal Obry 2014-03-31 18:59 ` Dmitry A. Kazakov 2 siblings, 0 replies; 240+ messages in thread From: Pascal Obry @ 2014-03-31 16:47 UTC (permalink / raw) Le lundi 31 mars 2014 à 08:13 -0700, Stoik a écrit : > A clever use of & and + makes it possible to output complicated mixtures.. Forgot about my previous message it seems I have miss-read your comment :) -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-31 15:13 ` Stoik 2014-03-31 16:22 ` Pascal Obry 2014-03-31 16:47 ` Pascal Obry @ 2014-03-31 18:59 ` Dmitry A. Kazakov 2 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-03-31 18:59 UTC (permalink / raw) On Mon, 31 Mar 2014 08:13:33 -0700 (PDT), Stoik wrote: > What is needed are subprograms for entering a word (get_word) delimited by > default by spaces. It seems that you are thinking in the paradigm of tokenizing. There are more efficient and easier means of parsing. When writing a compiler you indeed need something like getting an identifier from the source. But, an identifier is not a word and source is not a string, though string could be a source. Other stuff like matching the source against a table of keywords does not need word input either. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-30 19:33 ` Dmitry A. Kazakov 2014-03-30 19:59 ` Pascal Obry @ 2014-04-05 8:28 ` Pascal Obry 2014-04-05 11:06 ` Georg Bauhaus 1 sibling, 1 reply; 240+ messages in thread From: Pascal Obry @ 2014-04-05 8:28 UTC (permalink / raw) Le dimanche 30 mars 2014 à 21:33 +0200, Dmitry A. Kazakov a écrit : > On Sun, 30 Mar 2014 21:02:00 +0200, Pascal Obry wrote: > > > Le dimanche 30 mars 2014 à 05:28 -0700, francois_fabien@hotmail.com a > > écrit : > >> One wish to ease Input/output : > >> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n", > > > > Well, this is possible in Ada with some coding of a package, one could > > write something like (maybe already implemented by someone, I remember a > > simple_io package or something like that): > > > > Formatted_Print > > ("%c %c %c %c %c \n %c %c %c %c %c \n" > > & Var1 & Var2 & Var3 & Var4 & Var5 & Var6 & Var7 & Var8); > > > > You just have to code the Formatted_Print routine once for all. No big > > deal: > > > > type Formatted_String is private; > > > > Format_Error : exception; > > > > function "&" > > (F : Formatted_String; V : Character) return Formatted_String; > > function "&" > > (F : Formatted_String; V : Integer) return Formatted_String; > > function "&" > > (F : Formatted_String; V : Float) return Formatted_String; > > ... > > > > procedure Formatted_Print (F : Formatted_String); > > > > procedure Formatted_Print > > (File : Text_IO.File_Type; > > F : Formatted_String); > > I did such things, it is not so simple. > GNAT has now support for formatted string. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-05 8:28 ` Pascal Obry @ 2014-04-05 11:06 ` Georg Bauhaus 2014-04-05 11:20 ` Pascal Obry 0 siblings, 1 reply; 240+ messages in thread From: Georg Bauhaus @ 2014-04-05 11:06 UTC (permalink / raw) On 05/04/14 10:28, Pascal Obry wrote: >>> procedure Formatted_Print >>> > > (File : Text_IO.File_Type; >>> > > F : Formatted_String); >> > >> >I did such things, it is not so simple. >> > > GNAT has now support for formatted string. Where would I find this support? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-05 11:06 ` Georg Bauhaus @ 2014-04-05 11:20 ` Pascal Obry 0 siblings, 0 replies; 240+ messages in thread From: Pascal Obry @ 2014-04-05 11:20 UTC (permalink / raw) Le samedi 05 avril 2014 à 13:06 +0200, Georg Bauhaus a écrit : > On 05/04/14 10:28, Pascal Obry wrote: > >>> procedure Formatted_Print > >>> > > (File : Text_IO.File_Type; > >>> > > F : Formatted_String); > >> > > >> >I did such things, it is not so simple. > >> > > > GNAT has now support for formatted string. > > Where would I find this support? When it will be merged in FSF GNAT or in GNAT GPL 2015 I suppose. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (3 preceding siblings ...) 2014-03-30 12:28 ` francois_fabien @ 2014-04-02 16:21 ` Britt 2014-04-02 22:53 ` Randy Brukardt 2014-04-03 15:15 ` Robert A Duff 2014-04-04 18:31 ` Dan'l Miller ` (5 subsequent siblings) 10 siblings, 2 replies; 240+ messages in thread From: Britt @ 2014-04-02 16:21 UTC (permalink / raw) On Tuesday, March 25, 2014 5:41:16 PM UTC-4, Stoik wrote: > I wonder what is high on your list of wishes for Ada 202X? require basic support for 64-bit integer types: Standard.Long_Long_Integer (I'm currently missing this in ObjectAda) Interfaces.Integer_64 Interfaces.Unsigned_64 and corresponding support for C99's "long long", "int64_t" and "uint64_t" in Interfaces.C ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-02 16:21 ` Britt @ 2014-04-02 22:53 ` Randy Brukardt 2014-04-03 0:01 ` Jeffrey Carter 2014-04-03 0:06 ` Britt 2014-04-03 15:15 ` Robert A Duff 1 sibling, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-02 22:53 UTC (permalink / raw) Even on 8-bit and 16-bit processors?? Randy. (Note that no one should be depending on implementation-defined Standard types like Long_Long_Integer. These are considered implementation-defined by the profile No_Implementation_Extensions; they should be avoided in portable Ada code. Also see 3.5.4(28). I have more sympathy for requiring System.Max_Int to be at least 2**63-1 on appropriate machines (and the appropriate Interfaces types as well)) -- but what's an appropriate machine? Janus/Ada has never supported 64-bit integers, mainly because of the nasty effect on shared generics for formal integer and discrete types [it would force those to use all 64-bit math, which would get pretty expensive for Text_IO.Integer_IO and similar generics]. We only support 32-bit machines, but of course modern Intel processors all have 64-bit "integers" via the floating point instruction set. I've never considered that real 64-bit support and ignored it, because of expense and precision concerns [along with complications supporting indexing and for loops] -- not worth the headache. A 64-bit target would be a different beast, of course.) "Britt" <britt.snodgrass@gmail.com> wrote in message news:2d62368c-9f64-49f3-98a8-5121d0c0fa23@googlegroups.com... > On Tuesday, March 25, 2014 5:41:16 PM UTC-4, Stoik wrote: >> I wonder what is high on your list of wishes for Ada 202X? > > require basic support for 64-bit integer types: > Standard.Long_Long_Integer (I'm currently missing this in ObjectAda) > Interfaces.Integer_64 > Interfaces.Unsigned_64 > and corresponding support for C99's "long long", "int64_t" and > "uint64_t" in Interfaces.C ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-02 22:53 ` Randy Brukardt @ 2014-04-03 0:01 ` Jeffrey Carter 2014-04-03 5:51 ` Pascal Obry 2014-04-03 0:06 ` Britt 1 sibling, 1 reply; 240+ messages in thread From: Jeffrey Carter @ 2014-04-03 0:01 UTC (permalink / raw) On 04/02/2014 03:53 PM, Randy Brukardt wrote: > Even on 8-bit and 16-bit processors?? I'd like the language to support any integer type declaration a user is willing to write, regardless of "efficiency". For some such declarations, the compiler can chain together multiple machine "words" as we used to do in the Good Old Days® to get 16-bit integers on 8-bit machines like the 6502. At some the point the compiler should be allowed to use the same representation as Unbounded_Integer, which would implement the unlimited-precision integer package the compiler writer has had to use to write the compiler (or a similar package for the target for cross compilers). Not going to happen, I know, but ... I'd also like a mode in which objects that don't fit on the stack would be automatically put on the heap. -- Jeff Carter "I feel as though somebody stepped on my tongue with muddy feet." Never Give a Sucker an Even Break 112 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 0:01 ` Jeffrey Carter @ 2014-04-03 5:51 ` Pascal Obry 2014-04-03 6:27 ` Jeffrey Carter 2014-04-03 6:30 ` Georg Bauhaus 0 siblings, 2 replies; 240+ messages in thread From: Pascal Obry @ 2014-04-03 5:51 UTC (permalink / raw) Le mercredi 02 avril 2014 à 17:01 -0700, Jeffrey Carter a écrit : > On 04/02/2014 03:53 PM, Randy Brukardt wrote: > > Even on 8-bit and 16-bit processors?? > > I'd like the language to support any integer type declaration a user is willing > to write, regardless of "efficiency". For some such declarations, the compiler > can chain together multiple machine "words" as we used to do in the Good Old > Days® to get 16-bit integers on 8-bit machines like the 6502. At some the point > the compiler should be allowed to use the same representation as > Unbounded_Integer, which would implement the unlimited-precision integer package > the compiler writer has had to use to write the compiler (or a similar package > for the target for cross compilers). But again this is doable today in Ada (even 1983) with a library and proper overriding of the operators. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 5:51 ` Pascal Obry @ 2014-04-03 6:27 ` Jeffrey Carter 2014-04-03 17:18 ` Pascal Obry 2014-04-03 6:30 ` Georg Bauhaus 1 sibling, 1 reply; 240+ messages in thread From: Jeffrey Carter @ 2014-04-03 6:27 UTC (permalink / raw) On 04/02/2014 10:51 PM, Pascal Obry wrote: > > But again this is doable today in Ada (even 1983) with a library and > proper overriding of the operators. Well, no. Unbounded_Integer would work like any other integer type. You wouldn't have to convert literals or named numbers: I : Unbounded_Integer := 1E1000; -- Jeff Carter "I feel as though somebody stepped on my tongue with muddy feet." Never Give a Sucker an Even Break 112 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 6:27 ` Jeffrey Carter @ 2014-04-03 17:18 ` Pascal Obry 2014-04-03 19:11 ` Dan'l Miller ` (2 more replies) 0 siblings, 3 replies; 240+ messages in thread From: Pascal Obry @ 2014-04-03 17:18 UTC (permalink / raw) Le mercredi 02 avril 2014 à 23:27 -0700, Jeffrey Carter a écrit : > On 04/02/2014 10:51 PM, Pascal Obry wrote: > > > > But again this is doable today in Ada (even 1983) with a library and > > proper overriding of the operators. > > Well, no. Unbounded_Integer would work like any other integer type. You wouldn't > have to convert literals or named numbers: > > I : Unbounded_Integer := 1E1000; Ok, some little annoyance indeed. In the same vein, something that is annoying is to have to create record for returning multiple values from a function. I would rather like to have support for tuple. A, B : Integer; function MyName return (Integer, Integer); And then be able to write: (A, B) := (9, 12); or (A, B) := MyName; Today you need to create a record just for that. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 17:18 ` Pascal Obry @ 2014-04-03 19:11 ` Dan'l Miller 2014-04-03 19:18 ` Dan'l Miller 2014-04-03 21:17 ` Randy Brukardt 2 siblings, 0 replies; 240+ messages in thread From: Dan'l Miller @ 2014-04-03 19:11 UTC (permalink / raw) On Thursday, April 3, 2014 12:18:37 PM UTC-5, Pascal Obry wrote: > Le mercredi 02 avril 2014 à 23:27 -0700, Jeffrey Carter a écrit : > > > On 04/02/2014 10:51 PM, Pascal Obry wrote: > > > > > > > > But again this is doable today in Ada (even 1983) with a library and > > > > proper overriding of the operators. > > > > > > Well, no. Unbounded_Integer would work like any other integer type. You wouldn't > > > have to convert literals or named numbers: > > > > > > I : Unbounded_Integer := 1E1000; > > > > Ok, some little annoyance indeed. > > > > In the same vein, something that is annoying is to have to create record > > for returning multiple values from a function. I would rather like to > > have support for tuple. > > > > A, B : Integer; > > > > function MyName return (Integer, Integer); > > > > And then be able to write: > > > > (A, B) := (9, 12); > > > > or > > (A, B) := MyName; > > > > Today you need to create a record just for that. > > > > -- > > Pascal Obry / Magny Les Hameaux (78) > > > > The best way to travel is by means of imagination > > > > http://v2p.fr.eu.org > > http://www.obry.net > > > > gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 17:18 ` Pascal Obry 2014-04-03 19:11 ` Dan'l Miller @ 2014-04-03 19:18 ` Dan'l Miller 2014-04-03 21:17 ` Randy Brukardt 2 siblings, 0 replies; 240+ messages in thread From: Dan'l Miller @ 2014-04-03 19:18 UTC (permalink / raw) On Thursday, April 3, 2014 12:18:37 PM UTC-5, Pascal Obry wrote: > function MyName return (Integer, Integer); > > And then be able to write: > > (A, B) := (9, 12); > or > (A, B) := MyName; > > Today you need to create a record just for that. Although I agree that such syntax is preferable to the verbosity that we have today, to fulfill what goal should this be added to Ada202X? Is Ada202X's purpose to reduce verbosity with clever (or full-fledged mathematical a la Fortress) simplified syntax? Is the reason to add this to Ada202X the fact that C++2011 has some support for tuples (mainly through its Boost-inspired standard libraries with some back-infusion into the language itself) and that Ada202X's purpose is to address all of the C++ envies? Is the reason to add this to support some sort of library or code-generator that is awkward or impractical or impossible given today's record-based solution, and hence Ada202X's purpose is driven by what drove the Boost-inspired portions of C++2011: assisting writers of clever-under-the-hood libraries? Some of these are scarier than others. The final one on my list of questions above was the road to perdition in C++2011: contort C++ & its libraries to be a poor-man's kludge for a functional language. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 17:18 ` Pascal Obry 2014-04-03 19:11 ` Dan'l Miller 2014-04-03 19:18 ` Dan'l Miller @ 2014-04-03 21:17 ` Randy Brukardt 2014-04-04 0:29 ` Jeffrey Carter 2 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-03 21:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1233 bytes --] "Pascal Obry" <pascal@obry.net> wrote in message news:1396545517.12456.30.camel@pascal.home.net... >Le mercredi 02 avril 2014 à 23:27 -0700, Jeffrey Carter a écrit : >> On 04/02/2014 10:51 PM, Pascal Obry wrote: >> > >> > But again this is doable today in Ada (even 1983) with a library and >> > proper overriding of the operators. >> >> Well, no. Unbounded_Integer would work like any other integer type. You >> wouldn't >> have to convert literals or named numbers: >> >> I : Unbounded_Integer := 1E1000; > >Ok, some little annoyance indeed. Very little, with proper operator definitions I : Unbounded_Integer := +1E1000; works today. And it would be pretty simple to provide an aspect for allowing literals for a private type. But there is no advantage to supporting it as a built-in type - and it would have a significant cost, the elimination of practical generic sharing. (If built-in integers could use an "unbounded" type, then all integer math in a shared generic body would have to use that math. In which case, performance would be dismal. Even supporting 64-bit integers on a 32-bit machine would have a version of that effect, but of course no where near as severe.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 21:17 ` Randy Brukardt @ 2014-04-04 0:29 ` Jeffrey Carter 2014-04-04 8:20 ` Stefan.Lucks 2014-04-04 20:53 ` Randy Brukardt 0 siblings, 2 replies; 240+ messages in thread From: Jeffrey Carter @ 2014-04-04 0:29 UTC (permalink / raw) On 04/03/2014 02:17 PM, Randy Brukardt wrote: > > I : Unbounded_Integer := +1E1000; > > works today. I would like to see the definition of "+". -- Jeff Carter "If I could find a sheriff who so offends the citizens of Rock Ridge that his very appearance would drive them out of town ... but where would I find such a man? Why am I asking you?" Blazing Saddles 37 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 0:29 ` Jeffrey Carter @ 2014-04-04 8:20 ` Stefan.Lucks 2014-04-04 19:52 ` J Kimball 2014-04-04 20:53 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Stefan.Lucks @ 2014-04-04 8:20 UTC (permalink / raw) [-- Attachment #1: Type: TEXT/PLAIN, Size: 669 bytes --] On Thu, 3 Apr 2014, Jeffrey Carter wrote: > On 04/03/2014 02:17 PM, Randy Brukardt wrote: >> >> I : Unbounded_Integer := +1E1000; >> >> works today. > > I would like to see the definition of "+". Second! My understanding is that 1E1000 is of the pseudo-type Universal Integer, (or maybe Universal Float). But the "+" function cannot have an in-parameter of that type, so that *should* not work. Randy, please enlighten us! ------ I love the taste of Cryptanalysis in the morning! ------ <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html> --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany-- ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 8:20 ` Stefan.Lucks @ 2014-04-04 19:52 ` J Kimball 2014-04-04 20:43 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: J Kimball @ 2014-04-04 19:52 UTC (permalink / raw) On 04/04/2014 03:20 AM, Stefan.Lucks@uni-weimar.de wrote: > On Thu, 3 Apr 2014, Jeffrey Carter wrote: > >> On 04/03/2014 02:17 PM, Randy Brukardt wrote: >>> >>> I : Unbounded_Integer := +1E1000; >>> >>> works today. >> >> I would like to see the definition of "+". > > Second! > > My understanding is that 1E1000 is of the pseudo-type Universal Integer, (or maybe Universal Float). But the "+" function cannot have an in-parameter of that type, so that *should* not work. > > Randy, please enlighten us! > > ------ I love the taste of Cryptanalysis in the morning! ------ > <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html> > --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany-- On the other hand, using "+" operators in these ways obscures it's real meaning to people and often the compiler. In using a system that combines renames of language-defined and Templates Parser-defined conversion functions things can get rather hairy. Object names usually indicate what's being described, but rarely what type it is. A rich use of the type system makes using "+" boorish. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 19:52 ` J Kimball @ 2014-04-04 20:43 ` Randy Brukardt 2014-04-04 20:54 ` Shark8 2014-04-04 21:47 ` Luke A. Guest 0 siblings, 2 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-04 20:43 UTC (permalink / raw) "J Kimball" <spam@example.com> wrote in message news:lhn2ht$v5e$1@loke.gir.dk... > On 04/04/2014 03:20 AM, Stefan.Lucks@uni-weimar.de wrote: >> On Thu, 3 Apr 2014, Jeffrey Carter wrote: >> >>> On 04/03/2014 02:17 PM, Randy Brukardt wrote: >>>> >>>> I : Unbounded_Integer := +1E1000; >>>> >>>> works today. >>> >>> I would like to see the definition of "+". >> >> Second! >> >> My understanding is that 1E1000 is of the pseudo-type Universal Integer, >> (or maybe Universal Float). But the "+" function cannot have an >> in-parameter of that type, so that *should* not work. >> >> Randy, please enlighten us! > > On the other hand, using "+" operators in these ways obscures it's real > meaning to people and > often the compiler. In using a system that combines renames of > language-defined and > Templates Parser-defined conversion functions things can get rather hairy. > Object names > usually indicate what's being described, but rarely what type it is. A > rich use of the type system > makes using "+" boorish. I find this attitude infurating. (And it's wrong, too; literals provide no useful type information and adding "+" to the front does not change that situation. Taken literally and to the extreme, your thinking implies that all overloading of operators is a bad thing because it obscures the types involved. But let's stick with the infurating part). Let me give you a bit of history: Very early in the design of Ada, there was a proposal to add a unary operator symbol specifically for the purpose converting between types. Ichbiah and his team rejected the proposal as "+" already exists and has no other useful purpose. They said that "+" should be used for this purpose. The idea to add a unary operator symbol resurfaces periodically, but it always gets shot down because "+" works for that purpose. OTOH, attempts to actually *use* "+" in that way in the language-defined libraries also have always gotten shot down because there is a group which cannot stomach using it for non-numeric purposes. For instance, we had proposed to add: function "+" (A : String) return Unbounded_String renames To_Unbounded_String; to the Unbounded_String package because the conversion here is way too wordy. (Most of my packages that use unbounded string start with this declaration. The real problem is getting too many such declarations colliding.) The net effect is that Ada has neither an explicit conversion operator nor the balls to use "+" as intended. Which makes using language-defined packages a wordy mess to the point that I try pretty hard to avoid them. That's not how that's supposed to work! Attitudes such as yours prevent using the language as it was (and is) intended. And similar attitudes (on the other side of the debate) prevent changing it to make that less controversial. It leaves most people thinking the language has no way to do things when in fact the solutions have been there ever since the beginning of Ada. As for the difficulty of figuring out errors in complex expressions -- remember two things: (1) quality of error handling is not something that the standard can changes; and (2) qualified expressions and prefix notation are your friend. Compilation is quick enough these days that there is no real problem sticking in some qualifications and/or prefix calls to narrow down problems in complicated expressions. (And why are you writing complicated expressions in the first place? Use some expression functions to break those up.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 20:43 ` Randy Brukardt @ 2014-04-04 20:54 ` Shark8 2014-04-04 21:47 ` Luke A. Guest 1 sibling, 0 replies; 240+ messages in thread From: Shark8 @ 2014-04-04 20:54 UTC (permalink / raw) On 04-Apr-14 14:43, Randy Brukardt wrote: > (2) qualified expressions and prefix notation are your friend. Yes! There should be little to no aversion to using Some_Type'( XXX + YYY ); or whatever. Yes it's wordy, but it ALSO makes your intent explicit, saying to your future self, other developers, maintainers, etc "This is working with *this* particular type." ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 20:43 ` Randy Brukardt 2014-04-04 20:54 ` Shark8 @ 2014-04-04 21:47 ` Luke A. Guest 2014-04-08 0:47 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Luke A. Guest @ 2014-04-04 21:47 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote: > Very early in the design of Ada, there was a proposal to add a unary > operator symbol specifically for the purpose converting between types. > Ichbiah and his team rejected the proposal as "+" already exists and has no > other useful purpose. They said that "+" should be used for this purpose. I don't get the idea of using plus as a conversion operator, I'd this so e mathematical notation I've not come across? Luke ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 21:47 ` Luke A. Guest @ 2014-04-08 0:47 ` Randy Brukardt 2014-04-08 4:43 ` J Kimball 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-08 0:47 UTC (permalink / raw) "Luke A. Guest" <laguest@archeia.com> wrote in message news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org... > "Randy Brukardt" <randy@rrsoftware.com> wrote: >> Very early in the design of Ada, there was a proposal to add a unary >> operator symbol specifically for the purpose converting between types. >> Ichbiah and his team rejected the proposal as "+" already exists and has >> no >> other useful purpose. They said that "+" should be used for this purpose. > > I don't get the idea of using plus as a conversion operator, I'd this so e > mathematical notation I've not come across? The second part above is so garbled that I can't guess how to respond to it. The first part is easy, one camp says unary "+" doesn't have a (useful) mathematical meaning, so let's ignore that meaning and use the operator for conversions. The other camp says that unary "+" has a (useless) mathematical meaning that should be left alone. Because of the dynamics of the Ada standards process, neither camp ever gets to lead and the net effect is that we never get *any* conversion operator. Which we've needed from day 1, IMHO. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 0:47 ` Randy Brukardt @ 2014-04-08 4:43 ` J Kimball 2014-04-08 5:25 ` Jeffrey Carter 2014-04-08 23:44 ` Randy Brukardt 0 siblings, 2 replies; 240+ messages in thread From: J Kimball @ 2014-04-08 4:43 UTC (permalink / raw) On 04/07/2014 07:47 PM, Randy Brukardt wrote: > "Luke A. Guest" <laguest@archeia.com> wrote in message > news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org... >> "Randy Brukardt" <randy@rrsoftware.com> wrote: >>> Very early in the design of Ada, there was a proposal to add a unary >>> operator symbol specifically for the purpose converting between types. >>> Ichbiah and his team rejected the proposal as "+" already exists and has >>> no >>> other useful purpose. They said that "+" should be used for this purpose. >> >> I don't get the idea of using plus as a conversion operator, I'd this so e >> mathematical notation I've not come across? > > The second part above is so garbled that I can't guess how to respond to it. > The first part is easy, one camp says unary "+" doesn't have a (useful) > mathematical meaning, so let's ignore that meaning and use the operator for > conversions. The other camp says that unary "+" has a (useless) mathematical > meaning that should be left alone. Because of the dynamics of the Ada > standards process, neither camp ever gets to lead and the net effect is that > we never get *any* conversion operator. Which we've needed from day 1, IMHO. > > Randy. > > Maybe they could agree on a new unused operator being added. Of course mathematics uses every known graphic in some area. We might be able to agree that an addition should be in the ASCII code points for Unicode which leaves a couple of things that stand out that aren't already in use in Ada. "~" seems like a good character with a derivative meaning "approximates" which often all a conversion can do. UBString := ~String; -- Would drive people from some linguisitic backgrounds crazy, though. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 4:43 ` J Kimball @ 2014-04-08 5:25 ` Jeffrey Carter 2014-04-08 23:44 ` Randy Brukardt 1 sibling, 0 replies; 240+ messages in thread From: Jeffrey Carter @ 2014-04-08 5:25 UTC (permalink / raw) On 04/07/2014 09:43 PM, J Kimball wrote: > > Maybe they could agree on a new unused operator being added. Of course > mathematics uses every known graphic in some area. We might be able to agree > that an addition should be in the ASCII code points for Unicode which leaves a > couple of things that stand out that aren't already in use in Ada. "~" seems > like a good character with a derivative meaning "approximates" which often all a > conversion can do. > > UBString := ~String; -- Would drive people from some linguisitic backgrounds > crazy, though. I've suggested "\" in the past, to drive C people crazy. -- Jeff Carter "Crucifixion's a doddle." Monty Python's Life of Brian 82 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-08 4:43 ` J Kimball 2014-04-08 5:25 ` Jeffrey Carter @ 2014-04-08 23:44 ` Randy Brukardt 1 sibling, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-08 23:44 UTC (permalink / raw) "J Kimball" <spam@example.com> wrote in message news:lhvuom$g1$1@loke.gir.dk... > On 04/07/2014 07:47 PM, Randy Brukardt wrote: >> "Luke A. Guest" <laguest@archeia.com> wrote in message >> news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org... >>> "Randy Brukardt" <randy@rrsoftware.com> wrote: >>>> Very early in the design of Ada, there was a proposal to add a unary >>>> operator symbol specifically for the purpose converting between types. >>>> Ichbiah and his team rejected the proposal as "+" already exists and >>>> has >>>> no >>>> other useful purpose. They said that "+" should be used for this >>>> purpose. >>> >>> I don't get the idea of using plus as a conversion operator, I'd this so >>> e >>> mathematical notation I've not come across? >> >> The second part above is so garbled that I can't guess how to respond to >> it. >> The first part is easy, one camp says unary "+" doesn't have a (useful) >> mathematical meaning, so let's ignore that meaning and use the operator >> for >> conversions. The other camp says that unary "+" has a (useless) >> mathematical >> meaning that should be left alone. Because of the dynamics of the Ada >> standards process, neither camp ever gets to lead and the net effect is >> that >> we never get *any* conversion operator. Which we've needed from day 1, >> IMHO. > > Maybe they could agree on a new unused operator being added. Did you read my original message? That's been suggested for many years. There is a camp that thinks "+" is good enough for that, and thus blocks any attempts to add another such operator. (There's a lot of people in that camp.) The other group hates the idea of using "+" for that purpose, and blocks any use of that as a conversion in the language. (There's a lot of people in this group, too -- some are in both groups.) The ARG operates by consensus. We have no consensus on either point, thus nothing gets done at all. (Luckily, this dynamic doesn't happen very often.) > Of course mathematics > uses every known graphic in some area. We might be able to agree that an > addition should be in the ASCII code points for Unicode which leaves a > couple of things that > stand out that aren't already in use in Ada. "~" seems like a good > character with a derivative meaning "approximates" which often all a > conversion can do. If it was up to me, '@' or '#' or '$' or '~' would have been used for this long ago. > UBString := ~String; -- Would drive people from some linguisitic > backgrounds crazy, though. Probably any choice will annoy someone. I think that's the primary argument of the "+" backers -- no other solution is really obviously better, so lets not clutter the language further. It's hard to argue with that. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 0:29 ` Jeffrey Carter 2014-04-04 8:20 ` Stefan.Lucks @ 2014-04-04 20:53 ` Randy Brukardt 2014-04-04 23:25 ` Jeffrey Carter 1 sibling, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-04 20:53 UTC (permalink / raw) "Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:lhkudj$28t$1@dont-email.me... > On 04/03/2014 02:17 PM, Randy Brukardt wrote: >> >> I : Unbounded_Integer := +1E1000; >> >> works today. > > I would like to see the definition of "+". I missed that someone wrote a literal that's insanely large. They should simply have written: I : Unbounded_Integer := (raise Storage_Error); because that's what will happen. I was thinking about more realistic cases: Thousand : Unbounded_Integer := +1000; But anyway, what works today for this *exact* literal (and not the more realistic cases I was thinking about): Really_Large : Unbounded_Integer := +10**1000; -- Or as a stickler +1*(+10**1000); alternatively: Really_Large : Unbounded_Integer := Value("1E1000"); [since you're going to have Image and Value routines anyway]. "+" looks like: type Largest_Int is range System.Min_Int .. System.Max_Int; function "+" (Right : Largest_Int) return Unbounded_String; I have an 64-bit math package for Janus/Ada that works exactly this way (need to it deal with some returns from OS operations), and it works well. Most of the literals that are needed are small (0, 1, 2, 10) and it's much preferable to write them using "+" rather than some unwieldy function name (To_Huge_Integer?). One could do something similar with Value if large literals were really common, but I doubt that they'll appear in expressions very often. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 20:53 ` Randy Brukardt @ 2014-04-04 23:25 ` Jeffrey Carter 0 siblings, 0 replies; 240+ messages in thread From: Jeffrey Carter @ 2014-04-04 23:25 UTC (permalink / raw) On 04/04/2014 01:53 PM, Randy Brukardt wrote: > > I missed that someone wrote a literal that's insanely large. They should > simply have written: > > I : Unbounded_Integer := (raise Storage_Error); > > because that's what will happen. I was thinking about more realistic cases: 1E1_000 is hardly insanely large for an Unbounded_Integer type. It should take less than 420 bytes to store that value. And being unbounded, they're probably on the heap. > Really_Large : Unbounded_Integer := +10**1000; -- Or as a stickler > +1*(+10**1000); > > alternatively: > > Really_Large : Unbounded_Integer := Value("1E1000"); Sure, because these are packages rather than language support for unbounded integers. Such support should allow all literals the compiler can handle. Every Ada compiler I've used could handle Really_Large : constant := 1E1_000; Almost_Large : constant := 1E999; X : Positive := 28 * Really_Large / Almost_Large; -- Jeff Carter "He didn't get that nose from playing ping-pong." Never Give a Sucker an Even Break 110 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 5:51 ` Pascal Obry 2014-04-03 6:27 ` Jeffrey Carter @ 2014-04-03 6:30 ` Georg Bauhaus 1 sibling, 0 replies; 240+ messages in thread From: Georg Bauhaus @ 2014-04-03 6:30 UTC (permalink / raw) On 03/04/14 07:51, Pascal Obry wrote: > But again this is doable today in Ada (even 1983) with a library and > proper overriding of the operators. If one library L1 has a first subtype with "range -2**63 .. 2**63-1", and your compiler only supports smaller ranges or private types from some integer library L2, then the programmer cannot make L1 and L2 compatible, since the compiler rejects L1. SQL bindings are one example of the kind L1. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-02 22:53 ` Randy Brukardt 2014-04-03 0:01 ` Jeffrey Carter @ 2014-04-03 0:06 ` Britt 1 sibling, 0 replies; 240+ messages in thread From: Britt @ 2014-04-03 0:06 UTC (permalink / raw) On Wednesday, April 2, 2014 6:53:25 PM UTC-4, Randy Brukardt wrote: > Even on 8-bit and 16-bit processors?? No, I had 32-bit and 64-bit ARM/PowerPC/x86 type processors in mind. The RM currently allows Standard.Long_Long_Integer as an implementation permission. I know how to use project defined subtypes (renames) of Standard types in a reasonably portable way. Its annoying that ObjectAda still doesn't provide 64-bit integer support on the same targets as GNAT. I don't have recent experience with other compilers but I currently use both of these. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-02 16:21 ` Britt 2014-04-02 22:53 ` Randy Brukardt @ 2014-04-03 15:15 ` Robert A Duff 2014-04-03 20:19 ` Qun-Ying 1 sibling, 1 reply; 240+ messages in thread From: Robert A Duff @ 2014-04-03 15:15 UTC (permalink / raw) Britt <britt.snodgrass@gmail.com> writes: > On Tuesday, March 25, 2014 5:41:16 PM UTC-4, Stoik wrote: >> I wonder what is high on your list of wishes for Ada 202X? > > require basic support for 64-bit integer types: > Standard.Long_Long_Integer (I'm currently missing this in ObjectAda) Don't make the mistake of thinking standards require anybody to do anything. They pretend to, being full of words like "shall" and "must" and "illegal". But standards compliance is voluntary. As far as I know, ObjectAda does not conform to Ada 2012, so adding a requirement to Ada 2022 (or 2025 or whatever) is unlikely to have any effect on ObjectAda. All it takes to change that is money. But I agree with you that Ada ought to require[*] 64-bit integers (and more, as Jeff Carter said). On the other hand, I have no use for Standard.Long_Long_Integer -- I just want to be able to say things like "range 1..2**123". [*]or at least pretend to... ;-) > Interfaces.Integer_64 > Interfaces.Unsigned_64 > and corresponding support for C99's "long long", "int64_t" and "uint64_t" in Interfaces.C Yes, all of those make sense. - Bob ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 15:15 ` Robert A Duff @ 2014-04-03 20:19 ` Qun-Ying 2014-04-03 22:56 ` Robert A Duff 0 siblings, 1 reply; 240+ messages in thread From: Qun-Ying @ 2014-04-03 20:19 UTC (permalink / raw) Robert A Duff wrote: > But I agree with you that Ada ought to require[*] 64-bit integers > (and more, as Jeff Carter said). On the other hand, I have > no use for Standard.Long_Long_Integer -- I just want to be > able to say things like "range 1..2**123". > - Bob > What prevents a compiler to implement that in the current standard? Couldn't the compiler use internal representation (like using the gmp lib) for such big range? ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-03 20:19 ` Qun-Ying @ 2014-04-03 22:56 ` Robert A Duff 0 siblings, 0 replies; 240+ messages in thread From: Robert A Duff @ 2014-04-03 22:56 UTC (permalink / raw) Qun-Ying <zhu.qunying@gmail.com> writes: > Robert A Duff wrote: >> But I agree with you that Ada ought to require[*] 64-bit integers >> (and more, as Jeff Carter said). On the other hand, I have >> no use for Standard.Long_Long_Integer -- I just want to be >> able to say things like "range 1..2**123". >> - Bob >> > What prevents a compiler to implement that in the current standard? Nothing prevents it. It would cost money, though. Also, users might be surprised that: type Biggest_Integer is range System.Min_Int .. System.Max_Int; is extremely inefficient. And as I said, standards don't require anybody to do (or not do) anything. Standards compliance is optional. So even if the Ada RM forbade that, a compiler could allow it anyway (probably in a special mode, so it could still honestly claim conformance). But the fact that a compiler can implement very large integers isn't much use to people who care about portability to all conforming implementations. > Couldn't the compiler use internal representation (like using the gmp > lib) for such big range? It could. In fact, recent versions of GNAT support arbitrary-range integers for intermediate results. See Appendix D, "Overflow Check Handling in GNAT" in the GNAT User's Guide. - Bob ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (4 preceding siblings ...) 2014-04-02 16:21 ` Britt @ 2014-04-04 18:31 ` Dan'l Miller 2014-04-04 21:08 ` Randy Brukardt 2014-04-05 3:39 ` Peter Chapin 2014-04-04 20:27 ` Shark8 ` (4 subsequent siblings) 10 siblings, 2 replies; 240+ messages in thread From: Dan'l Miller @ 2014-04-04 18:31 UTC (permalink / raw) On Tuesday, March 25, 2014 4:41:16 PM UTC-5, Stoik wrote: > I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X? High on my list of wishes for Ada 202X is for there to be a clear cattle-prod that is an over-arching guiding principle, instead of Ada 202X being merely a catch-all bag of rather-random miscellany. Green, Red, etc color languages & Ada 1983's de facto over-arching guiding principle: explore what ***programming-in-the-large*** needs to replace the plethora of DoD/NATO languages utilized in vehicular & munitions systems. (Ada & C++ as Ada's dissenting counter-culture successfully taught the world to think bigger, more-disciplined thoughts and aspire to more-sophisticated designs that they would naturally have accomplished in mere Pascal or mere C.) Ada 1995's de facto over-arching guiding principle: import into Green Ada 1983 some of the features ***of Red and of C++***, especially OO. If C++ utilized "Ada 1983 does right" as its mantra, then Ada 1995 effectively utilized "C++ done right" as its counter-mantra as rebuttal or rebuke of C++. Ada 2005's de facto over-arching guiding principle: ***course-correction*** of Ada 1995 where the OO community criticized. Although laudable in producing a splendid incremental evolution of Ada, this was a weak mission with merely incremental (i.e., defensive) feature-set. Ada 2012's de facto over-arching guiding principle: ***dot each i and cross each t*** of Ada 2005. Although again laudable in producing the best Ada yet, this an extraordinarily weak mission with the feeling that Ada is so mature that Ada will likely change very little from this point forward. a potential Ada 202X's overt over-arching guiding principle: A la OCaml & Fortress, rethink how much ***declarative statements*** can preclude imperative statements to make Ada more "math-like". 1) For example, Dmitry Kazahov's idea of setting the Ada 1983-to-2012's data declarations on a new infrastructural foundation of more-primitive declarations. Perhaps this could permit more of an OCaml-like set of features, regarding type-inference and various "comprehensions", e.g., list-comprehension. 2) For example, providing a wiser not-metatemplate-programming rebuttal/rebuke to C++2011's metatemplate poor-man-functional-programming via kludges in C++ templates, as Round Two of Ada 1995's over-arching guiding mission of "C++ done right". 3) For example, expand Ada's set of programming genres beyond OO/runtime-polymorphic programming, procedural programming, generic/compile-time-parametric-polymorphic programming, parallel programming, etc to include, say, aspect-oriented programming declarations, functional-programming declarations, compile-time reflection to an Ada-like source-code-generating language (e.g., a.app rethought & expanded). ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 18:31 ` Dan'l Miller @ 2014-04-04 21:08 ` Randy Brukardt 2014-04-05 3:39 ` Peter Chapin 1 sibling, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-04 21:08 UTC (permalink / raw) "Dan'l Miller" <optikos@verizon.net> wrote in message news:f17effcf-af74-4a1d-9393-4149fe5a666c@googlegroups.com... ... >Ada 2012's de facto over-arching guiding principle: >***dot each i and cross each t*** of Ada 2005. Although again laudable in > producing the best Ada yet, this an extraordinarily weak mission with the > feeling that Ada is so mature that Ada will likely change very little from > this > point forward. That's wrong. There really were two overarching principles for Ada 2012: (1) Bring contract-oriented programming to the Ada mainstream; (2) Embrace the shift to container-oriented programming by making the set of containers richer and easier to use. Almost everything that was done falls into one of these two categories. The real-time stuff does not, but that's mainly handled by a separate group from the main Ada development effort -- we just try to make their ideas fit into the Standard. For instance, all of the expanded expression features exist mainly to make it more practical to write contract expressions and to allow compilers and tools to analyze them. Aspect clauses come from the realization that pragmas just don't cut it for defining contracts (which drove the wider realization that they really don't cut it for anything entity-specific). The iterator features exist to make iterating over a container much more like iterating over a built-in data structure. Same for the indexing and generalized reference features. It's too early to say what the goal for the next version of Ada will be. Surely there will be some clean-up of existing features (there always is), but that's not a very good reason for a new language standard. (That's more the job of a Corrigendum, one of which is likely in the next year or so.) Most likely, I would expect a push for finer-grained parallelism, and possibly for additional contract features. But I really don't know. We're unlikely to turn around so quickly this time; while the feeling was that Ada 2005 wasn't quite finished [needed bounded containers, contract features, etc.], there is no such feeling for Ada 2012. I think we'll need to see clear needs from the user community before jumping in again (but I could be wrong). Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-04 18:31 ` Dan'l Miller 2014-04-04 21:08 ` Randy Brukardt @ 2014-04-05 3:39 ` Peter Chapin 1 sibling, 0 replies; 240+ messages in thread From: Peter Chapin @ 2014-04-05 3:39 UTC (permalink / raw) On 2014-04-04 14:31, Dan'l Miller wrote: > a potential Ada 202X's overt over-arching guiding principle: I don't think Ada should try to become a functional language. I doubt if it could do so in a reasonable way while still being compatible to itself and maintaining its coherence. If you need to program functionally, don't use Ada. I can live with that. Ada was originally designed for embedded systems development so it seems natural for Ada 202X to continue with that focus. In that line enhanced support for parallelism, as Randy mentioned, seems like a logical step. Abstract concepts from languages with a theoretical focus (such as higher kinded types, metaprogramming, declarative programming, etc) just don't seem to be what Ada is about. I realize this might scandalize some people here, but I honestly see Ada as a similar kind of language as C. It is a systems oriented language intended for "down and dirty" control of hardware, etc. It is, of course, much safer than C and much better at programming in the large. (It probably makes more sense to compare Ada to C++). However, in the grand scheme of programming languages I see Ada, C, and C++ all hanging out together and well away from the Pythons, the Lisps, the MLs, and the Prologs. Peter ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (5 preceding siblings ...) 2014-04-04 18:31 ` Dan'l Miller @ 2014-04-04 20:27 ` Shark8 2014-04-14 4:59 ` J Kimball ` (3 subsequent siblings) 10 siblings, 0 replies; 240+ messages in thread From: Shark8 @ 2014-04-04 20:27 UTC (permalink / raw) On 25-Mar-14 15:41, Stoik wrote: > I think that even a casual user of Ada should be able to influence somehow the new version > of Ada. I wonder what is high on your list of wishes for Ada 202X? A 'Type attribute would be nice -- there've been a few times where I wanted to have one (IIRC, the last time was in dealing w/ generics). A 'Cursor attribute for arrays might be a good addition, so that you could use the indices in calculations inside the new generalized for-loop. An 'Index attribute might be good for initialization of arrays based on a formula: A : Array(1..3, 1..3) of Positive:= ( others => (A'Index(2)-1)*A'Index(1) + A'Index(2) ); would be [conceptually] equivalent to: A : Array(1..3, 1..3) of Positive:= ( (1, 2, 3), (4, 5, 5), (7, 8, 9) ); Less restrictions (or some form of workaround) on incomplete types as formal parameters of generics; it was disappointing to find that they did not allow me to quickly, cleanly write out a small [test/experimental] implementation of monoids as described in the video "Brian Beckman: Don't fear the Monad" -- https://www.youtube.com/watch?v=ZhuHCtR3xq8 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (6 preceding siblings ...) 2014-04-04 20:27 ` Shark8 @ 2014-04-14 4:59 ` J Kimball 2014-04-14 6:54 ` Shark8 2014-04-15 0:18 ` Randy Brukardt 2014-04-14 22:36 ` Shark8 ` (2 subsequent siblings) 10 siblings, 2 replies; 240+ messages in thread From: J Kimball @ 2014-04-14 4:59 UTC (permalink / raw) On 03/25/2014 04:41 PM, Stoik wrote: > I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X? > I suspect many of the proposals could be tested in GNAT before being introduced (or rejected) in the new version. One could add a switch to GNAT indicating that we want to use some of the experimental features. > I found myself in a situation in which some syntactic sugar on Ada 2012 might be able to help with. type T is ...; A : T; case A is when X => null; when Y | Z => case A is when Y => null; when Z => null; when X => null; -- Bleh end case; end case; I wish there was someway I wouldn't have to cover X for the inner case like maybe the branches could be have variables with implicitly defined subtypes. case A is when X => null; when B : Y | Z => case B is when Y => null; when Z => null; end case; end case; A bit of exception choice syntax and an implicit subtype a la Ada 2012. B : Y | Z might translate to: subtype /anonymous/ is T with Static_Predicate => T in Y | Z; B : /anonymous/; -- Predicate syntax might be wrong. Is a minor thing, but would save me grumbling each time I do this. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-14 4:59 ` J Kimball @ 2014-04-14 6:54 ` Shark8 2014-04-15 0:22 ` Randy Brukardt 2014-04-15 0:18 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-14 6:54 UTC (permalink / raw) You can do that already, with explicitly defined subtypes -- consider: Input : Integer; -- ... Case Input of When Integer'First..-1 => -- Handle negative numbers When others => Case Natural'(Input) is When Natural'First => -- Handle 0. When Positive'Range => -- Handle positives. end case; end case; But I *do* see how a "implicit subrange" could be interesting/useful. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-14 6:54 ` Shark8 @ 2014-04-15 0:22 ` Randy Brukardt 0 siblings, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-15 0:22 UTC (permalink / raw) "Shark8" <OneWingedShark@gmail.com> wrote in message news:ICL2v.19008$8l4.966@fx29.iad... > You can do that already, with explicitly defined subtypes -- consider: > > Input : Integer; > > -- ... > > Case Input of > When Integer'First..-1 => -- Handle negative numbers > When others => > Case Natural'(Input) is > When Natural'First => -- Handle 0. > When Positive'Range => -- Handle positives. > end case; > end case; Right, but this isn't legal for a variant. So there is an issue for variants. The problem is adding an implicit subtype would be very incompatible, as it would mean that cases that currently *require* some branch would *forbid* them in new code. I suggesting making something like the above legal, but it got no traction whatsoever. The alternatives proposed are way too complex in my view - they would require a complete redo of the way case completeness is handled (both in implementations and to a lesser extent in the RM), and the problem just isn't worth that much effort. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-14 4:59 ` J Kimball 2014-04-14 6:54 ` Shark8 @ 2014-04-15 0:18 ` Randy Brukardt 2014-04-15 5:28 ` J Kimball 1 sibling, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-15 0:18 UTC (permalink / raw) We've (the ARG) already discussed this issue - see the e-mail of AI12-0086-1. Proper solutions are way too incompatible with existing code, and solutions that aren't incompatible are way too complex (involving allowing several possible ways to write the same thing, but still disallowing other cases so that we are still getting completeness checking). So this is only fixable with added syntax, but this problem is nowhere near important enough to add syntax (how common are nested variants?). Randy. "J Kimball" <spam@example.com> wrote in message news:lifq02$dap$1@loke.gir.dk... > On 03/25/2014 04:41 PM, Stoik wrote: >> I think that even a casual user of Ada should be able to influence >> somehow the new version of Ada. I wonder what is high on your list of >> wishes for Ada 202X? >> I suspect many of the proposals could be tested in GNAT before being >> introduced (or rejected) in the new version. One could add a switch to >> GNAT indicating that we want to use some of the experimental features. >> > > I found myself in a situation in which some syntactic sugar on Ada 2012 > might be able to help with. > > type T is ...; > > A : T; > > case A is > when X => null; > when Y | Z => > case A is > when Y => null; > when Z => null; > when X => null; -- Bleh > end case; > end case; > > I wish there was someway I wouldn't have to cover X for the inner case > like maybe the branches could be have variables with implicitly defined > subtypes. > > case A is > when X => null; > when B : Y | Z => > case B is > when Y => null; > when Z => null; > end case; > end case; > > A bit of exception choice syntax and an implicit subtype a la Ada 2012. > > B : Y | Z might translate to: subtype /anonymous/ is T with > Static_Predicate => T in Y | Z; B : /anonymous/; -- Predicate syntax might > be wrong. > > Is a minor thing, but would save me grumbling each time I do this. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-15 0:18 ` Randy Brukardt @ 2014-04-15 5:28 ` J Kimball 0 siblings, 0 replies; 240+ messages in thread From: J Kimball @ 2014-04-15 5:28 UTC (permalink / raw) More than you'd think I guess. Maybe I overuse them. I try as hard as I can to get anything with discrete values into a matching type. It'd be a lot more painful in a language with switch statements that use breaks. The coverage rules make me feel safer. On 04/14/2014 07:18 PM, Randy Brukardt wrote: > We've (the ARG) already discussed this issue - see the e-mail of > AI12-0086-1. Proper solutions are way too incompatible with existing code, > and solutions that aren't incompatible are way too complex (involving > allowing several possible ways to write the same thing, but still > disallowing other cases so that we are still getting completeness checking). > So this is only fixable with added syntax, but this problem is nowhere near > important enough to add syntax (how common are nested variants?). > > Randy. > > "J Kimball" <spam@example.com> wrote in message > news:lifq02$dap$1@loke.gir.dk... >> On 03/25/2014 04:41 PM, Stoik wrote: >>> I think that even a casual user of Ada should be able to influence >>> somehow the new version of Ada. I wonder what is high on your list of >>> wishes for Ada 202X? >>> I suspect many of the proposals could be tested in GNAT before being >>> introduced (or rejected) in the new version. One could add a switch to >>> GNAT indicating that we want to use some of the experimental features. >>> >> >> I found myself in a situation in which some syntactic sugar on Ada 2012 >> might be able to help with. >> >> type T is ...; >> >> A : T; >> >> case A is >> when X => null; >> when Y | Z => >> case A is >> when Y => null; >> when Z => null; >> when X => null; -- Bleh >> end case; >> end case; >> >> I wish there was someway I wouldn't have to cover X for the inner case >> like maybe the branches could be have variables with implicitly defined >> subtypes. >> >> case A is >> when X => null; >> when B : Y | Z => >> case B is >> when Y => null; >> when Z => null; >> end case; >> end case; >> >> A bit of exception choice syntax and an implicit subtype a la Ada 2012. >> >> B : Y | Z might translate to: subtype /anonymous/ is T with >> Static_Predicate => T in Y | Z; B : /anonymous/; -- Predicate syntax might >> be wrong. >> >> Is a minor thing, but would save me grumbling each time I do this. > > ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (7 preceding siblings ...) 2014-04-14 4:59 ` J Kimball @ 2014-04-14 22:36 ` Shark8 2014-04-15 8:41 ` J-P. Rosen 2014-04-18 0:55 ` Robert Love 2014-04-23 12:55 ` björn lundin 10 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-14 22:36 UTC (permalink / raw) On 25-Mar-14 15:41, Stoik wrote: > I think that even a casual user of Ada should be able to influence > somehow the new version of Ada. I wonder what is high on your list > of wishes for Ada 202X? > > I suspect many of the proposals could be tested in GNAT before > being introduced (or rejected) in the new version. One could add a > switch to GNAT indicating that we want to use some of the > experimental features. Perhaps a way to use a procedure as a function, now that functions can have in/in-out parameter modes. Maybe with syntax like: Procedure Y( Input : in In_type; State : in out State_Type; Output : out Out_Type ); Function X renames Y with return Output; -- Function X being roughly equivalent to the following: Function X ( Input : in In_type; State : in out State_Type) return Out_Type is begin Return Result : Out_Type do Y( Input => Input, State => State, Output => Result ); end return; end X; ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-14 22:36 ` Shark8 @ 2014-04-15 8:41 ` J-P. Rosen 0 siblings, 0 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-15 8:41 UTC (permalink / raw) Le 15/04/2014 00:36, Shark8 a écrit : > Perhaps a way to use a procedure as a function, now that functions can > have in/in-out parameter modes. Maybe with syntax like: > > Procedure Y( Input : in In_type; > State : in out State_Type; > Output : out Out_Type ); > Function X renames Y with return Output; > > -- Function X being roughly equivalent to the following: > Function X ( Input : in In_type; > State : in out State_Type) > return Out_Type is > begin > Return Result : Out_Type do > Y( Input => Input, State => State, Output => Result ); > end return; > end X; It is not equivalent. If, for example, Out_Type is an unconstrained array type, the procedure has access to (and must obey by) the constraint of the parameter, while a function can return an object of any size. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (8 preceding siblings ...) 2014-04-14 22:36 ` Shark8 @ 2014-04-18 0:55 ` Robert Love 2014-04-18 11:39 ` Simon Wright 2014-04-23 12:55 ` björn lundin 10 siblings, 1 reply; 240+ messages in thread From: Robert Love @ 2014-04-18 0:55 UTC (permalink / raw) On 2014-03-25 21:41:16 +0000, Stoik said: > I think that even a casual user of Ada should be able to influence > somehow the new version of Ada. I wonder what is high on your list of > wishes for Ada 202X? > I suspect many of the proposals could be tested in GNAT before being > introduced (or rejected) in the new version. One could add a switch to > GNAT indicating that we want to use some of the experimental features. How about that it comes to be in my lifetime. Make that my working lifetime. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-18 0:55 ` Robert Love @ 2014-04-18 11:39 ` Simon Wright 0 siblings, 0 replies; 240+ messages in thread From: Simon Wright @ 2014-04-18 11:39 UTC (permalink / raw) Robert Love <rblove@airmail.net> writes: > On 2014-03-25 21:41:16 +0000, Stoik said: > >> I think that even a casual user of Ada should be able to influence >> somehow the new version of Ada. I wonder what is high on your list >> of wishes for Ada 202X? >> I suspect many of the proposals could be tested in GNAT before being >> introduced (or rejected) in the new version. One could add a switch >> to GNAT indicating that we want to use some of the experimental >> features. > > How about that it comes to be in my lifetime. Make that my working > lifetime. There is such a switch : -gnatX, "language extensions permitted". I don't think that there are any such extensions to actually _be_ permitted at the moment, there certainly have been in the past. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-03-25 21:41 Your wish list for Ada 202X Stoik ` (9 preceding siblings ...) 2014-04-18 0:55 ` Robert Love @ 2014-04-23 12:55 ` björn lundin 2014-04-23 13:57 ` J-P. Rosen ` (3 more replies) 10 siblings, 4 replies; 240+ messages in thread From: björn lundin @ 2014-04-23 12:55 UTC (permalink / raw) Den tisdagen den 25:e mars 2014 kl. 22:41:16 UTC+1 skrev Stoik: > I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X? > I'd like V'Img to be standard ada like T'Image(V); As in the gnat implementation type T is some_discrete_type V : T; Put_Line(V'Img); Also, I'd like to be able to define the string function for a record type to be used for the 'image attribute. type T2 is record A : T; B : T; end record; function F_T2_Image(O : T2) return String is begin return O.A'Img & " " O.B'Img; end F_T2_Image; for T2'Image use F_T2_Image V2 : T2; .. Put_Line(V2'Img); /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 12:55 ` björn lundin @ 2014-04-23 13:57 ` J-P. Rosen 2014-04-23 14:32 ` björn lundin 2014-04-23 14:38 ` Dmitry A. Kazakov 2014-04-23 14:06 ` Dmitry A. Kazakov ` (2 subsequent siblings) 3 siblings, 2 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 13:57 UTC (permalink / raw) Le 23/04/2014 14:55, björn lundin a écrit : > I'd like V'Img to be standard ada like T'Image(V); As in the gnat > implementation > No big cost, no big benefit... > Also, I'd like to be able to define the string function for a record > type to be used for the 'image attribute. > > type T2 is record A : T; B : T; end record; > > function F_T2_Image(O : T2) return String is begin return O.A'Img & " > " O.B'Img; end F_T2_Image; > > for T2'Image use F_T2_Image > > V2 : T2; .. Put_Line(V2'Img); > And what is the benefit over writing: Put_Line (F_T2_Image (V2)); ? (of course, saving typing 9 characters does not count!) -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 13:57 ` J-P. Rosen @ 2014-04-23 14:32 ` björn lundin 2014-04-23 15:43 ` J-P. Rosen 2014-04-23 14:38 ` Dmitry A. Kazakov 1 sibling, 1 reply; 240+ messages in thread From: björn lundin @ 2014-04-23 14:32 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 15:57:03 UTC+2 skrev J-P. Rosen: > Le 23/04/2014 14:55, björn lundin a écrit : > > I'd like V'Img to be standard ada like T'Image(V); As in the gnat > > implementation > > > > > No big cost, no big benefit... > No big cost, but the benefit is when you are in someone else code, or you have a fairly big system, with type definitions in several files. You then need to include the whole type Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.T'Image(V) instead of V'img Not a great leap for mankind, but still improvement. I find myself often use 'img in gnat, because it is easy. Yes, I'm lazy, but many people are lazy. Also, If I'd like a logfile statement, which I often do I very much prefer V'img before Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.T'Image(V) > > > Also, I'd like to be able to define the string function for a record > > type to be used for the 'image attribute. > > type T2 is record A : T; B : T; end record; > > function F_T2_Image(O : T2) return String is begin return O.A'Img & " > > " O.B'Img; end F_T2_Image; > > > > for T2'Image use F_T2_Image > > > > V2 : T2; .. Put_Line(V2'Img); > > > > And what is the benefit over writing: > > Put_Line (F_T2_Image (V2)); not very much. But the usual case is that you have to write Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.F_T2_Image(V2) instead of V2'img /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 14:32 ` björn lundin @ 2014-04-23 15:43 ` J-P. Rosen 2014-04-23 16:31 ` björn lundin 2014-04-23 18:02 ` Jeffrey Carter 0 siblings, 2 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 15:43 UTC (permalink / raw) Le 23/04/2014 16:32, björn lundin a écrit : >> And what is the benefit over writing: >> > >> > Put_Line (F_T2_Image (V2)); > not very much. > But the usual case is that you have to write > > Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.F_T2_Image(V2) > > instead of V2'img Ah! Another case of "I don't want to use the use clause, give me something else that avoids writing these damn long names". Either you think that you need to precisely specify where each called function is located, and you are bound to long names, or you think that the abstract meaning is fine and you don't care where it is declared, and, by all means, just use one of the variants of "use"! -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 15:43 ` J-P. Rosen @ 2014-04-23 16:31 ` björn lundin 2014-04-23 16:42 ` J-P. Rosen 2014-04-23 20:03 ` Randy Brukardt 2014-04-23 18:02 ` Jeffrey Carter 1 sibling, 2 replies; 240+ messages in thread From: björn lundin @ 2014-04-23 16:31 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 17:43:48 UTC+2 skrev J-P. Rosen: > Le 23/04/2014 16:32, björn lundin a écrit : > > >> And what is the benefit over writing: > >> > Put_Line (F_T2_Image (V2)); > > not very much. > > But the usual case is that you have to write > > Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.F_T2_Image(V2) > > instead of V2'img > > Ah! Another case of "I don't want to use the use clause, give me > something else that avoids writing these damn long names". No. using the 'use' is certainly something one can have different opinions on. But I like to avoid these kind of errors SET_ERROR_MODE(NO_ERROR, CRANE_TYPES.ASSIGNMENT_TIMEOUT, FALSE); | >>> error: "NO_ERROR" is not visible >>> error: multiple use clauses cause hiding >>> error: hidden declaration at crane_types.ads:113 >>> error: hidden declaration at siemens_interface.ads:374 >>> error: hidden declaration at core_types.ads:71 One of the best thing with Ada05 was the approval of object.verb notation. Even if i get to use it seldom at work, I do in hobby projects, just for this reason. The variable/object knows where it belongs, no need to use 'use' everywhere. This is the basic idea for my 'img proposal. The variable knows its type. No need to have long package names or risk hidden declarations. By the way, the above hidden situation was because of adding a constant 'NO_ERROR' in siemens_interface.ads the other two was a constant and a coded value. no hiding before that. /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 16:31 ` björn lundin @ 2014-04-23 16:42 ` J-P. Rosen 2014-04-23 17:51 ` björn lundin 2014-04-23 20:11 ` Randy Brukardt 2014-04-23 20:03 ` Randy Brukardt 1 sibling, 2 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 16:42 UTC (permalink / raw) Le 23/04/2014 18:31, björn lundin a écrit : > No. using the 'use' is certainly something one can have different opinions on. > But I like to avoid these kind of errors > > SET_ERROR_MODE(NO_ERROR, CRANE_TYPES.ASSIGNMENT_TIMEOUT, FALSE); > | > >>> error: "NO_ERROR" is not visible > >>> error: multiple use clauses cause hiding > >>> error: hidden declaration at crane_types.ads:113 > >>> error: hidden declaration at siemens_interface.ads:374 > >>> error: hidden declaration at core_types.ads:71 > > > One of the best thing with Ada05 was the approval of object.verb notation. > Even if i get to use it seldom at work, I do in hobby projects, > just for this reason. The variable/object knows where it belongs, > no need to use 'use' everywhere. > > This is the basic idea for my 'img proposal. > The variable knows its type. No need to > have long package names or risk hidden declarations. > > By the way, the above hidden situation was because of > adding a constant 'NO_ERROR' in siemens_interface.ads > > the other two was a constant and a coded value. > no hiding before that. I would tend to say that the "use" has the benefit to show you that you used the same name in various contexts with various meanings, and that a bit of reingeneering might be in order... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 16:42 ` J-P. Rosen @ 2014-04-23 17:51 ` björn lundin 2014-04-23 21:29 ` Pascal Obry 2014-04-23 20:11 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: björn lundin @ 2014-04-23 17:51 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 18:42:55 UTC+2 skrev J-P. Rosen: > Le 23/04/2014 18:31, björn lundin a écrit : > > > No. using the 'use' is certainly something one can have different opinions on. > > > I would tend to say that the "use" has the benefit to show you that you > used the same name in various contexts with various meanings, and that a > bit of reingeneering might be in order... Yes. it might. or not. The code is written by several programmers during different times. I think each of them had good reasons to declare a constant NO_ERROR, when communicationg with different devices, like PLCs. Either in a conveyor sub system or in a crane sub system. Calling then SIEMENS_S5_NO_ERROR or CRANE_NO_ERROR would put the ambiguity away, but the code would look awful. The clash was recent, due to ever evolving changes- new demands from customers. New demands lead me to define yet another NO_ERROR constant, for a new subsystem, siemens s7. but reengineer a running project due to I cannot use 'use' in this context. Well, yes, if the customer pays for that. Otherwise, they are happy with me qualifying NO_ERROR with correct package name. So, In a technical sense I agree. Re-engineer. But in a practical sense I do not. Cost way too much, and gains too little. while my suggestions about 'Img may not gain very much, it would help at least me. and it would probably not cost very much /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 17:51 ` björn lundin @ 2014-04-23 21:29 ` Pascal Obry 2014-04-23 22:00 ` J-P. Rosen 0 siblings, 1 reply; 240+ messages in thread From: Pascal Obry @ 2014-04-23 21:29 UTC (permalink / raw) Le mercredi 23 avril 2014 à 10:51 -0700, björn lundin a écrit : > Calling then SIEMENS_S5_NO_ERROR or CRANE_NO_ERROR would put the ambiguity away, > but the code would look awful. I fully agree. I'm also in the "no use" clan. Far better to declare the constant NO_ERROR and the packages SIEMENS_S5 and CRANE. Then CRANE_NO_ERROR or CRANE.NO_ERROR does not have more characters and avoid to have a extended visibility. I've never understood why people just put use everywhere and most often at the top of the unit. This gives visibility to the whole unit plus all the children. It is then harder to refactor the code as it is quite difficult to see what is actually used and where. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 21:29 ` Pascal Obry @ 2014-04-23 22:00 ` J-P. Rosen 2014-04-23 23:48 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 22:00 UTC (permalink / raw) Le 23/04/2014 23:29, Pascal Obry a écrit : > I fully agree. I'm also in the "no use" clan. I am not, but see below > Far better to declare the constant NO_ERROR and the packages SIEMENS_S5 > and CRANE. Then CRANE_NO_ERROR or CRANE.NO_ERROR does not have more > characters and avoid to have a extended visibility. Having a "use" clause does not prevent to use a full name when one thinks it is more readable. I do that all the time. > I've never understood why people just put use everywhere and most often > at the top of the unit. This gives visibility to the whole unit plus all > the children. It is then harder to refactor the code as it is quite > difficult to see what is actually used and where. Sure. Actually, the carefull separation between "with" and "use" has been designed to allow opening visibility just when and where you need access to the content. Putting "use" on top of the unit defeats the very purpose of the "use" clause. "use" clauses are very helpful and make code a lot more readable, provided they are restricted to the innermost context where they are useful (and of course, you have an AdaControl rule to enforce that ;-) ). -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 22:00 ` J-P. Rosen @ 2014-04-23 23:48 ` Shark8 2014-04-24 5:28 ` J-P. Rosen 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-23 23:48 UTC (permalink / raw) On 23-Apr-14 16:00, J-P. Rosen wrote: > > Actually, the carefull separation between "with" and "use" has been > designed to allow opening visibility just when and where you need > access to the content. Putting "use" on top of the unit defeats the > very purpose of the "use" clause. I'm going to disagree, slightly; putting a use clause at the top of the unit can certainly be valid -- consider using a thick-binding hierarchy, to a library that you're using to implement functionality X -- since your writing to that binding it is perfectly valid to USE it. (And since you're writing specifically to that binding there's little sense in not doing it -- though, to be fair, you can make it so that the structure of your application is independent of the library via a "layered" approach... then using a different lib is simply writing to the application/binding interface you already have.) Another reason is uniformity -- if you have a unit that's going to be using a lot of the operations from different units you can use them all and keep things uniform: With Ada.Integer_IO, Ada.Text_IO, Some_Lib.Text_IO, Some_Lib.Types; Use Ada.Integer_IO, Ada.Text_IO, Some_Lib.Text_IO; -- Library-Level Put Procedure Put( Input : Some_Lib.Types.Some_Record ) si begin Put( "Integer-Field:" ); Put( Input.Integer_Field ); New_Line; Put( "Name:" ); Put( Input.Name ); New_Line; --... and so on. end Library_Level_Put; > "use" clauses are very helpful and make code a lot more readable, > provided they are restricted to the innermost context where they are > useful (and of course, you have an AdaControl rule to enforce that ;-) ). I fully agree that they are useful/helpful. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 23:48 ` Shark8 @ 2014-04-24 5:28 ` J-P. Rosen 0 siblings, 0 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-24 5:28 UTC (permalink / raw) Le 24/04/2014 01:48, Shark8 a écrit : > I'm going to disagree, slightly; putting a use clause at the top of the > unit can certainly be valid -- consider [...] Sure, but in theses cases I prefer to put the use clause right at the beginning of the declarative part than as a context clause. The only difference it that the use does not apply to other context clauses - no big deal, and it makes the programming rule more uniform. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 16:42 ` J-P. Rosen 2014-04-23 17:51 ` björn lundin @ 2014-04-23 20:11 ` Randy Brukardt 1 sibling, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-23 20:11 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> wrote in message news:lj8qid$j23$2@dont-email.me... ... > I would tend to say that the "use" has the benefit to show you that you > used the same name in various contexts with various meanings, and that a > bit of reingeneering might be in order... That's baloney. For instance, if we were to add an exception to Claw, it might very well have the same name as some exception the client (or even another third party) declared somewhere. Why do you think this is a problem? The teams maintaining the subsystems no contact and only happen to be both included in some client program. Our maintenance, however, could break the client program even though there is no intended use of the new entity. That's just wrong. I've come to realize that the problem isn't use-clauses per-se, it's use clauses of things that maintenance can change (specifically when changes to non-overloadable entities can happen). As such, package use clause is acceptable on language-defined packages that don't allow implementation-defined identifiers, but that's it. In contrast, "use all type" (and the more limited "use type") are acceptable anywhere, as their maintenance hazard is much more limited, mostly to things for which having the same name and type profile is dubious anyway. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 16:31 ` björn lundin 2014-04-23 16:42 ` J-P. Rosen @ 2014-04-23 20:03 ` Randy Brukardt 2014-04-24 9:08 ` björn lundin 1 sibling, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-23 20:03 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1525 bytes --] "björn lundin" <b.f.lundin@gmail.com> wrote in message news:4e3a0e68-1514-4255-9c76-ef8758991ded@googlegroups.com... ... >> Ah! Another case of "I don't want to use the use clause, give me >> something else that avoids writing these damn long names". > >No. using the 'use' is certainly something one can have different opinions >on. >But I like to avoid these kind of errors > > SET_ERROR_MODE(NO_ERROR, CRANE_TYPES.ASSIGNMENT_TIMEOUT, > FALSE); > | > >>> error: "NO_ERROR" is not visible > >>> error: multiple use clauses cause hiding > >>> error: hidden declaration at crane_types.ads:113 > >>> error: hidden declaration at siemens_interface.ads:374 > >>> error: hidden declaration at core_types.ads:71 This is precisely why I consider package use a significant maintenance hazard. That hazard could have been reduced by allowing more things (especially objects) to be overloadable, but it cannot be eliminated (with introducing Beaujolias or other nasty effects). >One of the best thing with Ada05 was the approval of object.verb notation. Ada 2012 adds "use all type" with essentially the same semantics as object.verb notation. If you have untagged types, especially enumerations, I strongly suggest using that. (Since it only makes overloadable entities visible, it doesn't have the maintenance hazard unless the profiles match -- in which case you have a design problem.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 20:03 ` Randy Brukardt @ 2014-04-24 9:08 ` björn lundin 0 siblings, 0 replies; 240+ messages in thread From: björn lundin @ 2014-04-24 9:08 UTC (permalink / raw) >>One of the best thing with Ada05 was the approval of object.verb notation. >Ada 2012 adds "use all type" with essentially the same semantics as >object.verb notation. If you have untagged types, especially enumerations, I >strongly suggest using that. (Since it only makes overloadable entities >visible, it doesn't have the maintenance hazard unless the profiles match -- >in which case you have a design problem.) Interesting. I did not know. I'll look into that /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 15:43 ` J-P. Rosen 2014-04-23 16:31 ` björn lundin @ 2014-04-23 18:02 ` Jeffrey Carter 2014-04-23 20:14 ` Randy Brukardt 1 sibling, 1 reply; 240+ messages in thread From: Jeffrey Carter @ 2014-04-23 18:02 UTC (permalink / raw) On 04/23/2014 08:43 AM, J-P. Rosen wrote: >> > Ah! Another case of "I don't want to use the use clause, give me > something else that avoids writing these damn long names". While I agree with your sentiment, I think there's something else involved here, too. The Ada-95 version of the PragmAda Reusable Components include protected versions of the data structures, and in numerous cases users chose the protected version for purely sequential software in order to obtain the Object.Operation notation that a protected type offers. This was true even for users who used use clauses, and so chose to write Queue.Put (Item => Thingy); rather than Put (Onto => Queue, Item => Thingy); I don't think this is an issue of saving keystrokes, but a belief that the former is easier to read than the latter. With the addition of such notation for tagged types in 2007, exposure to this difference has become more widespread, so desiring V'Image rather than T'Image (V) may not be entirely about saving keystrokes. -- Jeff Carter "Run away! Run away!" Monty Python and the Holy Grail 58 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 18:02 ` Jeffrey Carter @ 2014-04-23 20:14 ` Randy Brukardt 2014-04-24 9:16 ` björn lundin 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-23 20:14 UTC (permalink / raw) "Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:lj8v7s$l5o$1@dont-email.me... > On 04/23/2014 08:43 AM, J-P. Rosen wrote: >>> >> Ah! Another case of "I don't want to use the use clause, give me >> something else that avoids writing these damn long names". > > While I agree with your sentiment, I think there's something else involved > here, too. The Ada-95 version of the PragmAda Reusable Components include > protected versions of the data structures, and in numerous cases users > chose the protected version for purely sequential software in order to > obtain the Object.Operation notation that a protected type offers. This > was true even for users who used use clauses, and so chose to write > > Queue.Put (Item => Thingy); > > rather than > > Put (Onto => Queue, Item => Thingy); > > I don't think this is an issue of saving keystrokes, but a belief that the > former is easier to read than the latter. > > With the addition of such notation for tagged types in 2007, exposure to > this difference has become more widespread, so desiring V'Image rather > than T'Image (V) may not be entirely about saving keystrokes. It's not, it's mainly about wanting to avoid the effort to look up the exact subtype of an object before writing 'Image. That wastes far more time than the few keystrokes ever would take. (Which is redoubled if one has to find out whether Image exists or some function has to be used instead.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 20:14 ` Randy Brukardt @ 2014-04-24 9:16 ` björn lundin 2014-04-24 11:33 ` G.B. 0 siblings, 1 reply; 240+ messages in thread From: björn lundin @ 2014-04-24 9:16 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 22:14:11 UTC+2 skrev Randy Brukardt: > "Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message > > I don't think this is an issue of saving keystrokes, but a belief that the > > former is easier to read than the latter. > > > With the addition of such notation for tagged types in 2007, exposure to > > this difference has become more widespread, so desiring V'Image rather > > than T'Image (V) may not be entirely about saving keystrokes. > > > > It's not, it's mainly about wanting to avoid the effort to look up the exact > subtype of an object before writing 'Image. That wastes far more time than > the few keystrokes ever would take. (Which is redoubled if one has to find > out whether Image exists or some function has to be used instead.) I agree. It is not just to save keystrokes, it is to simplify work. And no-one here uses a debugger, so examining log-files is the way to find errors (around here anyway). Debugging does not help when you wan't to examine why something happend or did not happen at a running site. Logfiles do. If they contain the correct amount of logging. 'Img or 'Image would encourage more people to log stuff they perhaps do not know that they need to log. And it is a pain if you want to log a record, with many separate types, where the types are defined in several separate files. Varible'img or Varaible'Image would make life easier for me /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 9:16 ` björn lundin @ 2014-04-24 11:33 ` G.B. 2014-04-24 12:11 ` björn lundin 0 siblings, 1 reply; 240+ messages in thread From: G.B. @ 2014-04-24 11:33 UTC (permalink / raw) On 24.04.14 11:16, björn lundin wrote: > Debugging does not help when you wan't to examine why something happend or did not happen at a running site. A debugger can help examine a "running site", depending on the qualities of the debugger and on what the "running site" is offering to it. > Logfiles do. If they contain the correct amount of logging. Logfiles---very much part of my daily work--- require much more than a simple 'Img can achieve, even if 'Img were made a primitive operation. I need more flexibility than that. To match what I am using every day, Ada would need to provide for data introspection and for flexible output of this information. For example, I need 'Img to produce a string that some alread-opened logging facility will accept as properly encoded. I also need different representations to be produced in different locations in the program. 'Img is a "pragmatic" semi-solution, good for ASCII data, hence good for traditional Western engineering, and therefore set to stay forever, like C. What about this: X : Wide_Character := '€'; -- site handles currencies Y : Character := '¥'; ... Put (Latin_1_File, X'Img); Put (UTF_8_File, Y'Img); ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 11:33 ` G.B. @ 2014-04-24 12:11 ` björn lundin 2014-04-24 12:32 ` G.B. 0 siblings, 1 reply; 240+ messages in thread From: björn lundin @ 2014-04-24 12:11 UTC (permalink / raw) Den torsdagen den 24:e april 2014 kl. 13:33:00 UTC+2 skrev G.B.: > On 24.04.14 11:16, bj�rn lundin wrote: > > Debugging does not help when you wan't to examine why something happend or did not happen at a running site. > > A debugger can help examine a "running site", > depending on the qualities of the debugger and > on what the "running site" is offering to it. Perhaps you are right about that. Still, it does not change the validy of ME wanting a shoutcut for Type(varible)'image > > Logfiles do. If they contain the correct amount of logging. > Logfiles---very much part of my daily work--- > require much more than a simple 'Img can achieve, > even if 'Img were made a primitive operation. I guess 'depending on the qualities of the debugger and on what the "running site" is offering to it.' works well here to if you change 'debugger' to 'logging' It all depends. Here we run a business that uses logfiles for tracing down problems on customer sites. It works well for us. If it does no work for you - then too bad. > I need more flexibility than that. To match what I am > using every day, Ada would need to provide for data > introspection and for flexible output of this information. YOU might need more flexibility. I don't . I speak for myself in my wish/proposal. > > For example, I need 'Img to produce a string that > some alread-opened logging facility will accept > as properly encoded. I also need different representations > to be produced in different locations in the program. Then I suggest you improve my wish/proposal about makeing the progammer decide how to create the image. I suggested a userdefined function. Where is your proposal? > 'Img is a "pragmatic" semi-solution, good for ASCII data, and good for me too. > hence good for traditional Western engineering, and > therefore set to stay forever, like C. What about this: > > X : Wide_Character := '�'; -- site handles currencies > Y : Character := '�'; > ... > > Put (Latin_1_File, X'Img); > Put (UTF_8_File, Y'Img); Looks like you have a start for a proposal ... /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 12:11 ` björn lundin @ 2014-04-24 12:32 ` G.B. 0 siblings, 0 replies; 240+ messages in thread From: G.B. @ 2014-04-24 12:32 UTC (permalink / raw) On 24.04.14 14:11, björn lundin wrote: > Then I suggest you improve my wish/proposal about > makeing the progammer decide how to create the image. In this logging situation I'd want (a) what Bub Duff has hinted at, Java's I/O layering, for modernizing Ada's Put operations, (b) what Dmitry Kazakov keeps suggesting: MD, or, alternatively, what J.-P. Rosen has just said about generics. I have used Image as a primitive operation, and this worked for me, to some extent, but I'm not sure it could work for Ada. Programmers will have to write and rewrite Image, while they might expect something to be present already. 'Img works well for AdaCore it seems, like C works well for the majority of embedded systems, in a similar fashion. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 13:57 ` J-P. Rosen 2014-04-23 14:32 ` björn lundin @ 2014-04-23 14:38 ` Dmitry A. Kazakov 2014-04-23 15:46 ` J-P. Rosen 1 sibling, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 14:38 UTC (permalink / raw) On Wed, 23 Apr 2014 15:57:03 +0200, J-P. Rosen wrote: > Le 23/04/2014 14:55, björn lundin a écrit : > >> I'd like V'Img to be standard ada like T'Image(V); As in the gnat >> implementation >> > No big cost, no big benefit... > >> Also, I'd like to be able to define the string function for a record >> type to be used for the 'image attribute. >> >> type T2 is record A : T; B : T; end record; >> >> function F_T2_Image(O : T2) return String is begin return O.A'Img & " >> " O.B'Img; end F_T2_Image; >> >> for T2'Image use F_T2_Image >> >> V2 : T2; .. Put_Line(V2'Img); >> > And what is the benefit over writing: > Put_Line (F_T2_Image (V2)); > ? generic type T is private; package Foo is ... package body Foo is procedure Bar (X : T) is begin ... X'Img ... That is the only use case for an attribute, in absence of primitive operations of course. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 14:38 ` Dmitry A. Kazakov @ 2014-04-23 15:46 ` J-P. Rosen 2014-04-23 16:27 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 15:46 UTC (permalink / raw) Le 23/04/2014 16:38, Dmitry A. Kazakov a écrit : >> And what is the benefit over writing: >> > Put_Line (F_T2_Image (V2)); >> > ? > generic > type T is private; > package Foo is ... > > package body Foo is > procedure Bar (X : T) is > begin > ... X'Img ... > > That is the only use case for an attribute, in absence of primitive > operations of course. But that would require every type to have a 'Img. Yes, you said you wanted that, but there are clearly types where no sensible image could be provided. Of course, you can always provide non-sensible strings... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 15:46 ` J-P. Rosen @ 2014-04-23 16:27 ` Dmitry A. Kazakov 2014-04-23 16:40 ` J-P. Rosen 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 16:27 UTC (permalink / raw) On Wed, 23 Apr 2014 17:46:04 +0200, J-P. Rosen wrote: > Le 23/04/2014 16:38, Dmitry A. Kazakov a écrit : >>> And what is the benefit over writing: >>> > Put_Line (F_T2_Image (V2)); >>> > ? >> generic >> type T is private; >> package Foo is ... >> >> package body Foo is >> procedure Bar (X : T) is >> begin >> ... X'Img ... >> >> That is the only use case for an attribute, in absence of primitive >> operations of course. > > But that would require every type to have a 'Img. Yes, you said you > wanted that, but there are clearly types where no sensible image could > be provided. No, I didn't want that. Instead I would do two things: 1. Classes for all types; 2. An interface named Printable (or whatever else name) with the primitive operation Image. Now, if a type is supposed to have Image, it must implement the interface. All scalar types will. If a record type need to have Image, you inherit to Printable. If Image is needed in a generic the formal type inherits to Printable. That's it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 16:27 ` Dmitry A. Kazakov @ 2014-04-23 16:40 ` J-P. Rosen 2014-04-23 17:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 16:40 UTC (permalink / raw) Le 23/04/2014 18:27, Dmitry A. Kazakov a écrit : >> But that would require every type to have a 'Img. Yes, you said you >> > wanted that, but there are clearly types where no sensible image could >> > be provided. > No, I didn't want that. > > Instead I would do two things: > > 1. Classes for all types; > > 2. An interface named Printable (or whatever else name) with the primitive > operation Image. > > Now, if a type is supposed to have Image, it must implement the interface. > All scalar types will. > > If a record type need to have Image, you inherit to Printable. If Image is > needed in a generic the formal type inherits to Printable. That's it. But why require such a machinery? If you want to express that a formal type must feature an Image function, you can do it even in '83: generic type T is private; with function Image (Item : T) return String; package Foo is... What would an attribute bring as benefit? -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 16:40 ` J-P. Rosen @ 2014-04-23 17:39 ` Dmitry A. Kazakov 2014-04-23 21:40 ` J-P. Rosen 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 17:39 UTC (permalink / raw) On Wed, 23 Apr 2014 18:40:33 +0200, J-P. Rosen wrote: > Le 23/04/2014 18:27, Dmitry A. Kazakov a écrit : >>> But that would require every type to have a 'Img. Yes, you said you >>> > wanted that, but there are clearly types where no sensible image could >>> > be provided. >> No, I didn't want that. >> >> Instead I would do two things: >> >> 1. Classes for all types; >> >> 2. An interface named Printable (or whatever else name) with the primitive >> operation Image. >> >> Now, if a type is supposed to have Image, it must implement the interface. >> All scalar types will. >> >> If a record type need to have Image, you inherit to Printable. If Image is >> needed in a generic the formal type inherits to Printable. That's it. > > But why require such a machinery? If you want to express that a formal > type must feature an Image function, you can do it even in '83: > > generic > type T is private; > with function Image (Item : T) return String; > package Foo is... > > What would an attribute bring as benefit? Primitive operation (and an attribute) cannot get lost, become hidden, replaced by another operation. A stray formal function can and easily does. Furthermore, the formal declarations above is nothing but a poor man's description of an interface, ADT + operations (Image, ":=", "=", "/=" etc). Since Ada 95 has proper interfaces (tagged types), we should rather use them. Which is shorter (you don't need to reiterate the list of operations) and *greatly* safer, because proper interfaces are matched nominally, while generic formal interfaces are matched by structure, proper interfaces can be encapsulated in packages and formal interfaces cannot, proper interfaces can be reused in several packages and formal interfaces need cut and paste and so on. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 17:39 ` Dmitry A. Kazakov @ 2014-04-23 21:40 ` J-P. Rosen 2014-04-24 7:42 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: J-P. Rosen @ 2014-04-23 21:40 UTC (permalink / raw) Le 23/04/2014 19:39, Dmitry A. Kazakov a écrit : > Furthermore, the formal declarations above is nothing but a poor man's > description of an interface, ADT + operations (Image, ":=", "=", "/=" etc). I won't argue with that. We know that you (and many people, no blaming intended) see everything through inheritance. Other people (myself, Randy f.e.) use inheritance in rare cases, only when it is the right tool for a certain problem. Generics have also benefits over interfaces, especially since you can match any formal with any actual, while interfaces impose functions to have the same name to match. Just one example. So please consider (as my experience showed very often) that different people have different ways of thinking. Some think naturally with classification, others with composition. I don't know if it's related to being right- or left-brained, it's possible. Ada offers support for both, which is nice. Please just don't assume that your way of thinking is the only "right" one. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 21:40 ` J-P. Rosen @ 2014-04-24 7:42 ` Dmitry A. Kazakov 2014-04-24 9:18 ` J-P. Rosen 0 siblings, 1 reply; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-24 7:42 UTC (permalink / raw) On Wed, 23 Apr 2014 23:40:27 +0200, J-P. Rosen wrote: > Generics have also benefits over interfaces, especially since you can > match any formal with any actual, while interfaces impose functions to > have the same name to match. Just one example. Yes, they are matched by structure. I don't see it as a benefit. I see it as a hazard. > So please consider (as my experience showed very often) that different > people have different ways of thinking. Some think naturally with > classification, others with composition. I don't know if it's related to > being right- or left-brained, it's possible. Ada offers support for > both, which is nice. Please just don't assume that your way of thinking > is the only "right" one. And extending your argument (to so to say "cultural relativism") on the discussion on Ada vs. C. People, let's call them "top-brained", would claim that Ada were not any better than C. C would be for top-brained. Ada would for bottom-brained... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 7:42 ` Dmitry A. Kazakov @ 2014-04-24 9:18 ` J-P. Rosen 0 siblings, 0 replies; 240+ messages in thread From: J-P. Rosen @ 2014-04-24 9:18 UTC (permalink / raw) Le 24/04/2014 09:42, Dmitry A. Kazakov a écrit : > People, let's call them "top-brained", would claim > that Ada were not any better than C. C would be for top-brained. Ada would > for bottom-brained... (:-) Or better, as Dijkstra put it, small-brained... ;-) -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 12:55 ` björn lundin 2014-04-23 13:57 ` J-P. Rosen @ 2014-04-23 14:06 ` Dmitry A. Kazakov 2014-04-23 14:44 ` björn lundin 2014-04-23 14:58 ` björn lundin 2014-04-23 18:05 ` Jeffrey Carter 2014-04-23 19:48 ` Shark8 3 siblings, 2 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 14:06 UTC (permalink / raw) On Wed, 23 Apr 2014 05:55:00 -0700 (PDT), björn lundin wrote: > I'd like V'Img to be standard ada like T'Image(V); > As in the gnat implementation V means value, not an object? A value could be ambiguous. E.g. 123'Img OK, considering no place for the sign as in T'Image(V), the image of a modular and of an integer type will be same. But what about floating point types: 12.0001000020003'Img Depending on Float, Long_Float, IEEE_Float_32 the result will be different. > type T is some_discrete_type > V : T; > > Put_Line(V'Img); > > Also, I'd like to be able to define the string function > for a record type to be used for the 'image attribute. The only reason why anybody would use an attribute over a [primitive] function is that the attribute 'Image is predefined by the language/compiler. If record types ought to get 'Img, you should specify how to generate it for whatever record type. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 14:06 ` Dmitry A. Kazakov @ 2014-04-23 14:44 ` björn lundin 2014-04-23 20:28 ` Randy Brukardt 2014-04-23 14:58 ` björn lundin 1 sibling, 1 reply; 240+ messages in thread From: björn lundin @ 2014-04-23 14:44 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 16:06:55 UTC+2 skrev Dmitry A. Kazakov: > On Wed, 23 Apr 2014 05:55:00 -0700 (PDT), björn lundin wrote: > > I'd like V'Img to be standard ada like T'Image(V); > > As in the gnat implementation > V means value, not an object? A value could be ambiguous. E.g. Yes value. Sorry if I was not clear. > > OK, considering no place for the sign as in T'Image(V), the image of a > modular and of an integer type will be same. But what about floating point > types: I stated discrete_types. > > type T is some_discrete_type > > > Also, I'd like to be able to define the string function > > for a record type to be used for the 'image attribute. > The only reason why anybody would use an attribute over a [primitive] > function is that the attribute 'Image is predefined by the > language/compiler. If record types ought to get 'Img, you should specify > how to generate it for whatever record type. No. Not the only reason. Another reason is when you work on a legacy system, that was implemented with Ada83. The system then turns out to be stubbornly vital, so it won't go away for many years. But there are few or no tagged types. So, being able to define an 'Img attribute on eg type AD_ASSIGNMENT_RECORD is record ASSIGNMENT_ID : ASSIGNMENT_ID_TYPE; ASSIGNMENT_MODE : ASSIGNMENT_MODE_TYPE; ASSIGNMENT_TYPE : ASSIGNMENT_TYPE_TYPE; CURRENT_ADDRESS : ADDRESS_TYPE; DESTINATION : ADDRESS_TYPE; PRIORITY : INTEGER_4; LAST_ASSIGNMENT : YESNO_TYPE; LOAD_TYPE : PALLET_CODE_TYPE; LOAD_HEIGHT : HEIGHT_CODE_TYPE; LOAD_WEIGHT : INTEGER_4; ZONE : INTEGER_4; HANDLER : ADDRESS_TYPE; SEMI_AUTO_SUB_SYSTEM_ID: SUB_SYSTEM_ID_TYPE; SEQUENCE_ID : STRING(1..SEQUENCE_ID_MAX_LENGTH); PALLET_ID : PALLET_ID_TYPE; ADDITIONAL_INFO_LENGTH : ADDITIONAL_INFORMATION_LENGTH_TYPE; ADDITIONAL_INFO : ADDITIONAL_INFORMATION_TYPE; FILLER_1 : STRING(1..2); -- v8.1 TRANSPORT_TYPE : INTEGER_4; -- v9.1 SHIPPING_DATE : SATTMATE_CALENDAR.TIME_TYPE; -- v9.1 FILLER_2 : STRING(1..2); -- v9.1 end record; for AD_ASSIGNMENT_RECORD'alignment use 4; for AD_ASSIGNMENT_RECORD use -- V6.5b record ASSIGNMENT_ID at 0 range 0..31; -- V6.5b ASSIGNMENT_MODE at 4 range 0..31; -- V6.5b ASSIGNMENT_TYPE at 8 range 0..31; -- V6.5b CURRENT_ADDRESS at 12 range 0..8*24-1; -- V6.5b DESTINATION at 36 range 0..8*24-1; -- V6.5b PRIORITY at 60 range 0..31; -- V6.5b LAST_ASSIGNMENT at 64 range 0..31; -- V6.5b LOAD_TYPE at 68 range 0..31; -- V6.5b LOAD_HEIGHT at 72 range 0..31; -- V6.5b LOAD_WEIGHT at 76 range 0..31; -- V6.5b ZONE at 80 range 0..31; -- V6.5b HANDLER at 84 range 0..8*24-1; -- V6.5b SEMI_AUTO_SUB_SYSTEM_ID at 108 range 0..31; -- V6.5b SEQUENCE_ID at 112 range 0..8*4-1; -- V6.5b PALLET_ID at 116 range 0..8*16-1; -- V6.5b, v8.1 ADDITIONAL_INFO_LENGTH at 132 range 0..31; -- V6.5b, v8.1 ADDITIONAL_INFO at 136 range 0..8*50-1; -- V6.5b, v8.1 FILLER_1 at 186 range 0..8*2-1; -- v8.1 TRANSPORT_TYPE at 188 range 0..31; -- v9.1 SHIPPING_DATE at 192 range 0..16*7-1; -- v9.1 FILLER_2 at 206 range 0..8*2-1; -- v9.1 end record; -- V6.5b for AD_ASSIGNMENT_RECORD'SIZE use 8*208; -- V6.5b, v8.1, v9.1 would be really nice. All types within the record are 2 or 4 bytes integers or strings (The representation clauses where vital for sending record like this with generic functions using ipc on vax/ppc/ and intel boxes. They also where importatant when sending BETWEEN ppc and intelboxes. This is now rewritten, but not tested without the representation clauses so I do not dear to remove them just yet ) /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 14:44 ` björn lundin @ 2014-04-23 20:28 ` Randy Brukardt 2014-04-24 10:31 ` björn lundin 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-23 20:28 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2479 bytes --] "björn lundin" <b.f.lundin@gmail.com> wrote in message news:63812656-3d79-4330-8b02-1836f3669b00@googlegroups.com... Den onsdagen den 23:e april 2014 kl. 16:06:55 UTC+2 skrev Dmitry A. Kazakov: ... >> OK, considering no place for the sign as in T'Image(V), the image of a >> modular and of an integer type will be same. But what about floating >> point >> types: > >I stated discrete_types. That would be a very weird restriction, as subtype'Image is defined for all scalar types (including float and fixed types). Obj'Image almost certainly would not be defined for literals, as a literal cannot be the prefix of an attribute and changing the attribute machinery would kill the cost/benefit ratio of any such change. One could allow values that are names (Float'(3.14159)'Image) but there's not problem determining how to handle that. Also note that the name would be "Image". GNAT uses "Img" because language-defined attributes cannot be redefined, but they would have much preferred to call it "Image". No need nor sense to use a different name ('First can have an object or subtype prefix, so nothing new about that.) If it sounds like I've considered this extensively, that's because I have. :-) Another proposal that I worked on carefully was Obj'Succ (where Obj could be a complex expression, which is better than Obj := Obj + 1; as that has a duplication of Obj.) ... >No. Not the only reason. >Another reason is when you work on a legacy system, >that was implemented with Ada83. >The system then turns out to be stubbornly vital, >so it won't go away for many years. But there are >few or no tagged types. If it's still required to stay in Ada 83, then adding Obj'Image to Ada 2020 isn't going to help any. If it's able to be changed, then there are lot of things that ought to be re-engineered if substantial work is going to be done, and using Obj'Image is down in the noise. BTW, your proposal is a lot like the way stream attributes work, and that has proven to be a massive can-of-worms. The entire mess about availability of stream attributes comes about because of the ability of different views to have a different ideaa of whether an attribute is legal or not. This is not a trivial idea (nor is the one in AI12-0020-1). (Also note that providing 'Image implies providing a matching 'Value, just like providing 'Write implies providing 'Read. 'Value is a lot messier than 'Image, in general.) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 20:28 ` Randy Brukardt @ 2014-04-24 10:31 ` björn lundin 2014-04-25 1:22 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: björn lundin @ 2014-04-24 10:31 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 22:28:29 UTC+2 skrev Randy Brukardt: > "björn lundin" <b.f.lundin@a.gmail.com> wrote in message > news:63812656-3d79-4330-8b02-1836f3669b00@googlegroups.com... > > That would be a very weird restriction, as subtype'Image is defined for all > scalar types (including float and fixed types). Hmm, yes. But that comment was due to me misreading/misinterpreting Dmitrys answer with ambiguty for float values. So yes, it would be a weird restriction. My thought was to have it as a plain shortcut to standard Ada's Type(Variable)'Image or gnat's Varable'Img > Also note that the name would be "Image". GNAT uses "Img" because > language-defined attributes cannot be redefined, but they would have much > preferred to call it "Image". And that is totally ok with me. 'Img or 'Image on the varible is ok. Id just like to get rid of quilifying the type, since the variable knows it's own type. That is it. Then, to make log statements from records, i propose that the programmer can point out what funtion to use for 'Image for this record. makes it SOO much easier to throw in a log-line. > If it's still required to stay in Ada 83, then adding Obj'Image to Ada 2020 > isn't going to help any. It is not. We compile using Ada05 flag (gnat) We are migrating homebrew bindings to os-stuff via e.g. Ada.Directories. But a great chunk of the code is written in Ada83-style, meaning very few tagged objects. They are of course of much later date. > If it's able to be changed, then there are lot of > things that ought to be re-engineered if substantial work is going to be > done, and using Obj'Image is down in the noise. Well, that is a money question. I cannot justify too radical changes, without a firm return on investment paper. Obj'Image will not cause redesign. But sure, a complete redesign would be nice. But chances are that the decision will be : use C++ for the redesign, so I am a bit careful with that. > > BTW, your proposal is a lot like the way stream attributes work, and that > has proven to be a massive can-of-worms. The entire mess about availability > of stream attributes comes about because of the ability of different views > to have a different ideaa of whether an attribute is legal or not. This is > not a trivial idea (nor is the one in AI12-0020-1). I do not see the connection. Is it legal to use T'Image(Value) then why would not Value'Image be valid? It seems (to me) that gnat did figure that out, with Value'Img > > (Also note that providing 'Image implies providing a matching 'Value, just > like providing 'Write implies providing 'Read. 'Value is a lot messier than > 'Image, in general.) I can see that. But I suggested Img/'Image only. Not 'Value. /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 10:31 ` björn lundin @ 2014-04-25 1:22 ` Randy Brukardt 2014-04-25 2:19 ` Shark8 0 siblings, 1 reply; 240+ messages in thread From: Randy Brukardt @ 2014-04-25 1:22 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1794 bytes --] "björn lundin" <b.f.lundin@gmail.com> wrote in message news:cdd237eb-7cb1-404f-b18e-695cef9f2f73@googlegroups.com... Den onsdagen den 23:e april 2014 kl. 22:28:29 UTC+2 skrev Randy Brukardt: ... >> BTW, your proposal is a lot like the way stream attributes work, and that >> has proven to be a massive can-of-worms. The entire mess about >> availability >> of stream attributes comes about because of the ability of different >> views >> to have a different ideaa of whether an attribute is legal or not. This >> is >> not a trivial idea (nor is the one in AI12-0020-1). > >I do not see the connection. Is it legal to use T'Image(Value) >then why would not Value'Image be valid? >It seems (to me) that gnat did figure that out, with Value'Img Sorry, I was talking about the idea of user-defined 'Image for record types. That's currently not legal for T'Image(Obj), so it's not going to be legal for Obj'Image either. To make it legal is somewhat a can of worms, because visibility gets entwined -- especially if any automatic composition is provides (something I would like to see, otherwise there is little need for it to be an attribute). >> (Also note that providing 'Image implies providing a matching 'Value, >> just >> like providing 'Write implies providing 'Read. 'Value is a lot messier >> than >> 'Image, in general.) > >I can see that. But I suggested Img/'Image only. Not 'Value. If one supplies user-defined 'Image, we'd pretty much have to support user-defined 'Value as well. (You wouldn't have to use it, of course). It's rare that only one way I/O is needed. Of course, this ups the effort for composition a lot. I don't think I could support user-defined 'Image without user-defined 'Value -- it seems asymetric to me. Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-25 1:22 ` Randy Brukardt @ 2014-04-25 2:19 ` Shark8 2014-04-25 7:31 ` Dmitry A. Kazakov 0 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-25 2:19 UTC (permalink / raw) On 24-Apr-14 19:22, Randy Brukardt wrote: > > If one supplies user-defined 'Image, we'd pretty much have to support > user-defined 'Value as well. (You wouldn't have to use it, of course). It's > rare that only one way I/O is needed. Of course, this ups the effort for > composition a lot. I don't think I could support user-defined 'Image without > user-defined 'Value -- it seems asymetric to me. At that point it sounds like we're getting into the Stream attributes -- though it would be nice to have a secondary IO channel. The distinction is, of course, that user-defined 'Image/'Value would be more geared towards text rather than the generality of streams. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-25 2:19 ` Shark8 @ 2014-04-25 7:31 ` Dmitry A. Kazakov 0 siblings, 0 replies; 240+ messages in thread From: Dmitry A. Kazakov @ 2014-04-25 7:31 UTC (permalink / raw) On Thu, 24 Apr 2014 20:19:22 -0600, Shark8 wrote: > On 24-Apr-14 19:22, Randy Brukardt wrote: >> >> If one supplies user-defined 'Image, we'd pretty much have to support >> user-defined 'Value as well. (You wouldn't have to use it, of course). It's >> rare that only one way I/O is needed. Of course, this ups the effort for >> composition a lot. I don't think I could support user-defined 'Image without >> user-defined 'Value -- it seems asymetric to me. > > At that point it sounds like we're getting into the Stream attributes -- > though it would be nice to have a secondary IO channel. The distinction > is, of course, that user-defined 'Image/'Value would be more geared > towards text rather than the generality of streams. Interestingly that it is already here (A.12.2): package Ada.Text_IO.Text_Streams Though, there is a big BUT. Since stream attributes rather emulate multiple dispatch [*] than do full MD, we cannot have your second channel which would make Integer'Output (S, X); formatting X differently when S is a text file (or a string stream) from when S is a socket. ----------- * Stream attributes semantically do cascaded dispatch, first on the I/O item type, then on the stream type. This precludes stream-dependent formatting. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 14:06 ` Dmitry A. Kazakov 2014-04-23 14:44 ` björn lundin @ 2014-04-23 14:58 ` björn lundin 1 sibling, 0 replies; 240+ messages in thread From: björn lundin @ 2014-04-23 14:58 UTC (permalink / raw) Den onsdagen den 23:e april 2014 kl. 16:06:55 UTC+2 skrev Dmitry A. Kazakov: > On Wed, 23 Apr 2014 05:55:00 -0700 (PDT), björn lundin wrote: > V means value, not an object? A value could be ambiguous. E.g. I see now that I misinterpreted you. I did not mean value. I meant variable. object or not. as in the V in V : Integer > 123'Img Not like this > OK, considering no place for the sign as in T'Image(V), the image of a > modular and of an integer type will be same. But what about floating point > types: > > 12.0001000020003'Img Which take away this case, because it is not a variable. If it was, It would work like Float'Image(variable) or Long_Float'Image(Variable) depending on how varible was declared /Björn ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 12:55 ` björn lundin 2014-04-23 13:57 ` J-P. Rosen 2014-04-23 14:06 ` Dmitry A. Kazakov @ 2014-04-23 18:05 ` Jeffrey Carter 2014-04-23 19:48 ` Shark8 3 siblings, 0 replies; 240+ messages in thread From: Jeffrey Carter @ 2014-04-23 18:05 UTC (permalink / raw) On 04/23/2014 05:55 AM, björn lundin wrote: > > I'd like V'Img to be standard ada like T'Image(V); > As in the gnat implementation If this is accepted, it should be V'Image. GNAT uses 'Img because implementation-defined attributes are allowed; new uses of existing attributes are not. -- Jeff Carter "Run away! Run away!" Monty Python and the Holy Grail 58 ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 12:55 ` björn lundin ` (2 preceding siblings ...) 2014-04-23 18:05 ` Jeffrey Carter @ 2014-04-23 19:48 ` Shark8 2014-04-24 9:03 ` G.B. 3 siblings, 1 reply; 240+ messages in thread From: Shark8 @ 2014-04-23 19:48 UTC (permalink / raw) On 23-Apr-14 06:55, björn lundin wrote: > > I'd like V'Img to be standard ada like T'Image(V); > As in the gnat implementation I'd rather get a V'Type attribute; it would effectively solve your problem here as V'Img would be equivalent to: V'Type'Image( V ) This would also give us a bit more functionality rather than simply elevating a common case into the standard.. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-23 19:48 ` Shark8 @ 2014-04-24 9:03 ` G.B. 2014-04-25 1:27 ` Randy Brukardt 0 siblings, 1 reply; 240+ messages in thread From: G.B. @ 2014-04-24 9:03 UTC (permalink / raw) On 23.04.14 21:48, Shark8 wrote: > On 23-Apr-14 06:55, björn lundin wrote: >> >> I'd like V'Img to be standard ada like T'Image(V); >> As in the gnat implementation > > I'd rather get a V'Type attribute; it would effectively solve your > problem here as V'Img would be equivalent to: > V'Type'Image( V ) > > This would also give us a bit more functionality rather than simply > elevating a common case into the standard.. The real motivation for 'Img is debugging. But few Ada programmers know how to operate a good, programmable debugger. Fix that. ^ permalink raw reply [flat|nested] 240+ messages in thread
* Re: Your wish list for Ada 202X 2014-04-24 9:03 ` G.B. @ 2014-04-25 1:27 ` Randy Brukardt 0 siblings, 0 replies; 240+ messages in thread From: Randy Brukardt @ 2014-04-25 1:27 UTC (permalink / raw) "G.B." <rm-dash-bau-haus@dash.futureapps.de> wrote in message news:5358d373$0$6703$9b4e6d93@newsspool2.arcor-online.net... > On 23.04.14 21:48, Shark8 wrote: ... > But few Ada programmers know how to operate a good, > programmable debugger. That would require such a thing to exist. I'd suggest that it is one of those cases where you can choose any two of the three. :-) Randy. ^ permalink raw reply [flat|nested] 240+ messages in thread
end of thread, other threads:[~2014-04-29 19:42 UTC | newest] Thread overview: 240+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-25 21:41 Your wish list for Ada 202X Stoik 2014-03-25 22:14 ` Simon Wright 2014-03-26 6:25 ` Shark8 2014-03-26 20:41 ` Randy Brukardt 2014-03-27 9:20 ` Shark8 2014-03-27 21:50 ` Randy Brukardt 2014-03-28 1:54 ` Jeffrey Carter 2014-03-28 8:17 ` Dmitry A. Kazakov 2014-03-28 21:27 ` Randy Brukardt 2014-03-29 9:44 ` Dmitry A. Kazakov 2014-03-31 23:55 ` Randy Brukardt 2014-04-01 8:20 ` Dmitry A. Kazakov 2014-04-01 10:51 ` G.B. 2014-04-01 12:40 ` Dmitry A. Kazakov 2014-04-02 22:39 ` Randy Brukardt 2014-04-03 2:59 ` Shark8 2014-04-05 11:10 ` Dmitry A. Kazakov 2014-04-08 1:15 ` Randy Brukardt 2014-04-08 9:15 ` Dmitry A. Kazakov 2014-04-08 10:15 ` G.B. 2014-04-08 10:56 ` Dmitry A. Kazakov 2014-04-08 23:37 ` Randy Brukardt 2014-04-09 10:40 ` Dmitry A. Kazakov 2014-04-10 3:28 ` Randy Brukardt 2014-04-10 8:42 ` Georg Bauhaus 2014-04-10 21:52 ` Randy Brukardt 2014-04-10 15:31 ` Dmitry A. Kazakov 2014-04-10 22:08 ` Randy Brukardt 2014-04-11 6:20 ` Dmitry A. Kazakov 2014-04-11 21:34 ` Randy Brukardt 2014-04-10 22:39 ` Randy Brukardt 2014-04-11 6:40 ` Dmitry A. Kazakov 2014-04-11 21:44 ` Randy Brukardt 2014-04-12 8:45 ` Dmitry A. Kazakov 2014-04-14 23:39 ` Randy Brukardt 2014-04-15 7:55 ` Dmitry A. Kazakov 2014-04-15 21:27 ` Randy Brukardt 2014-04-16 7:52 ` Dmitry A. Kazakov 2014-04-16 21:53 ` Randy Brukardt 2014-04-17 7:39 ` Dmitry A. Kazakov 2014-04-17 17:29 ` Randy Brukardt 2014-04-17 19:54 ` Dmitry A. Kazakov 2014-04-11 19:04 ` Niklas Holsti 2014-04-11 20:43 ` Dmitry A. Kazakov 2014-04-11 22:04 ` Niklas Holsti 2014-04-12 8:20 ` Dmitry A. Kazakov 2014-04-12 8:39 ` Nasser M. Abbasi 2014-04-12 9:38 ` Dmitry A. Kazakov 2014-04-12 9:55 ` Georg Bauhaus 2014-04-12 10:45 ` Dmitry A. Kazakov 2014-04-14 23:45 ` Randy Brukardt 2014-04-12 10:17 ` Nasser M. Abbasi 2014-04-12 10:48 ` Dmitry A. Kazakov 2014-04-13 19:43 ` Niklas Holsti 2014-04-13 21:07 ` Dmitry A. Kazakov 2014-04-18 19:10 ` Niklas Holsti 2014-04-18 21:18 ` Dmitry A. Kazakov 2014-04-19 7:35 ` Niklas Holsti 2014-04-19 8:19 ` Dmitry A. Kazakov 2014-04-19 8:39 ` Dmitry A. Kazakov 2014-04-19 9:08 ` Niklas Holsti 2014-04-19 10:06 ` Dmitry A. Kazakov 2014-04-19 13:53 ` Niklas Holsti 2014-04-19 14:21 ` Dmitry A. Kazakov 2014-04-19 18:28 ` Niklas Holsti 2014-04-19 9:05 ` Niklas Holsti 2014-04-19 10:18 ` Dmitry A. Kazakov 2014-04-15 0:08 ` Randy Brukardt 2014-04-15 7:21 ` Natasha Kerensikova 2014-04-15 21:20 ` Randy Brukardt 2014-04-16 6:32 ` Niklas Holsti 2014-04-16 7:24 ` Natasha Kerensikova 2014-04-16 7:31 ` Dmitry A. Kazakov 2014-04-16 9:30 ` Redispatching (was: Your wish list for Ada 202X) J-P. Rosen 2014-04-16 19:53 ` Redispatching Niklas Holsti 2014-04-17 7:26 ` Redispatching Dmitry A. Kazakov 2014-04-17 8:22 ` Redispatching Georg Bauhaus 2014-04-18 20:08 ` Redispatching Niklas Holsti 2014-04-18 20:51 ` Redispatching Dmitry A. Kazakov 2014-04-19 9:17 ` Redispatching Georg Bauhaus 2014-04-19 10:58 ` Redispatching Dmitry A. Kazakov 2014-04-19 11:21 ` Redispatching Georg Bauhaus 2014-04-17 8:53 ` Redispatching J-P. Rosen 2014-04-16 21:44 ` Your wish list for Ada 202X Niklas Holsti 2014-04-16 22:27 ` Randy Brukardt 2014-04-18 19:59 ` Niklas Holsti 2014-04-18 21:28 ` Randy Brukardt 2014-04-19 8:14 ` Niklas Holsti 2014-04-21 23:09 ` Randy Brukardt 2014-04-22 6:08 ` Niklas Holsti 2014-04-22 8:02 ` Dmitry A. Kazakov 2014-04-22 8:30 ` Shark8 2014-04-22 9:14 ` Dmitry A. Kazakov 2014-04-22 23:23 ` Randy Brukardt 2014-04-23 7:45 ` Dmitry A. Kazakov 2014-04-23 19:43 ` Shark8 2014-04-23 20:00 ` Dmitry A. Kazakov 2014-04-23 21:28 ` Shark8 2014-04-24 7:30 ` Dmitry A. Kazakov 2014-04-24 15:20 ` Shark8 2014-04-24 16:19 ` Dmitry A. Kazakov 2014-04-24 16:50 ` Shark8 2014-04-24 16:57 ` Dmitry A. Kazakov 2014-04-19 10:02 ` Georg Bauhaus 2014-03-27 22:06 ` Randy Brukardt 2014-03-28 5:23 ` Shark8 2014-03-26 8:17 ` Dmitry A. Kazakov 2014-03-26 9:02 ` J Kimball 2014-03-26 9:27 ` Dmitry A. Kazakov 2014-03-26 10:30 ` Marius Amado-Alves 2014-03-26 15:11 ` G.B. 2014-03-26 21:55 ` Simon Clubley 2014-03-26 15:03 ` G.B. 2014-03-26 22:00 ` Simon Clubley 2014-03-26 16:01 ` Anh Vo 2014-03-26 17:04 ` Dmitry A. Kazakov 2014-03-27 15:03 ` Dan'l Miller 2014-03-27 16:02 ` Dmitry A. Kazakov 2014-03-26 16:17 ` Stoik 2014-03-26 17:15 ` Dmitry A. Kazakov 2014-03-26 18:04 ` G.B. 2014-03-26 18:47 ` Simon Wright 2014-03-26 19:51 ` Georg Bauhaus 2014-03-27 14:43 ` Jacob Sparre Andersen 2014-03-27 22:50 ` Randy Brukardt 2014-03-28 5:22 ` J-P. Rosen 2014-03-28 7:54 ` Jacob Sparre Andersen 2014-03-28 21:22 ` Randy Brukardt 2014-03-26 21:06 ` Randy Brukardt 2014-03-26 23:15 ` J Kimball 2014-03-27 8:26 ` Dmitry A. Kazakov 2014-03-27 10:54 ` Georg Bauhaus 2014-03-27 15:42 ` Dmitry A. Kazakov 2014-03-27 21:35 ` Randy Brukardt 2014-04-29 14:26 ` Tero Koskinen 2014-04-29 15:39 ` Dan'l Miller 2014-04-29 17:10 ` Simon Clubley 2014-04-29 17:13 ` Tero Koskinen 2014-04-29 19:42 ` Simon Clubley 2014-03-30 12:28 ` francois_fabien 2014-03-30 13:40 ` Luke A. Guest 2014-03-30 14:24 ` Simon Clubley 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 19:22 ` Dmitry A. Kazakov 2014-03-30 14:28 ` Simon Clubley 2014-03-30 15:14 ` Peter Chapin 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 18:48 ` Luke A. Guest 2014-03-30 23:41 ` Simon Clubley 2014-03-31 15:39 ` Adam Beneschan 2014-03-30 13:46 ` Simon Clubley 2014-03-30 19:02 ` Pascal Obry 2014-03-30 19:33 ` Dmitry A. Kazakov 2014-03-30 19:59 ` Pascal Obry 2014-03-31 15:13 ` Stoik 2014-03-31 16:22 ` Pascal Obry 2014-03-31 16:47 ` Pascal Obry 2014-03-31 18:59 ` Dmitry A. Kazakov 2014-04-05 8:28 ` Pascal Obry 2014-04-05 11:06 ` Georg Bauhaus 2014-04-05 11:20 ` Pascal Obry 2014-04-02 16:21 ` Britt 2014-04-02 22:53 ` Randy Brukardt 2014-04-03 0:01 ` Jeffrey Carter 2014-04-03 5:51 ` Pascal Obry 2014-04-03 6:27 ` Jeffrey Carter 2014-04-03 17:18 ` Pascal Obry 2014-04-03 19:11 ` Dan'l Miller 2014-04-03 19:18 ` Dan'l Miller 2014-04-03 21:17 ` Randy Brukardt 2014-04-04 0:29 ` Jeffrey Carter 2014-04-04 8:20 ` Stefan.Lucks 2014-04-04 19:52 ` J Kimball 2014-04-04 20:43 ` Randy Brukardt 2014-04-04 20:54 ` Shark8 2014-04-04 21:47 ` Luke A. Guest 2014-04-08 0:47 ` Randy Brukardt 2014-04-08 4:43 ` J Kimball 2014-04-08 5:25 ` Jeffrey Carter 2014-04-08 23:44 ` Randy Brukardt 2014-04-04 20:53 ` Randy Brukardt 2014-04-04 23:25 ` Jeffrey Carter 2014-04-03 6:30 ` Georg Bauhaus 2014-04-03 0:06 ` Britt 2014-04-03 15:15 ` Robert A Duff 2014-04-03 20:19 ` Qun-Ying 2014-04-03 22:56 ` Robert A Duff 2014-04-04 18:31 ` Dan'l Miller 2014-04-04 21:08 ` Randy Brukardt 2014-04-05 3:39 ` Peter Chapin 2014-04-04 20:27 ` Shark8 2014-04-14 4:59 ` J Kimball 2014-04-14 6:54 ` Shark8 2014-04-15 0:22 ` Randy Brukardt 2014-04-15 0:18 ` Randy Brukardt 2014-04-15 5:28 ` J Kimball 2014-04-14 22:36 ` Shark8 2014-04-15 8:41 ` J-P. Rosen 2014-04-18 0:55 ` Robert Love 2014-04-18 11:39 ` Simon Wright 2014-04-23 12:55 ` björn lundin 2014-04-23 13:57 ` J-P. Rosen 2014-04-23 14:32 ` björn lundin 2014-04-23 15:43 ` J-P. Rosen 2014-04-23 16:31 ` björn lundin 2014-04-23 16:42 ` J-P. Rosen 2014-04-23 17:51 ` björn lundin 2014-04-23 21:29 ` Pascal Obry 2014-04-23 22:00 ` J-P. Rosen 2014-04-23 23:48 ` Shark8 2014-04-24 5:28 ` J-P. Rosen 2014-04-23 20:11 ` Randy Brukardt 2014-04-23 20:03 ` Randy Brukardt 2014-04-24 9:08 ` björn lundin 2014-04-23 18:02 ` Jeffrey Carter 2014-04-23 20:14 ` Randy Brukardt 2014-04-24 9:16 ` björn lundin 2014-04-24 11:33 ` G.B. 2014-04-24 12:11 ` björn lundin 2014-04-24 12:32 ` G.B. 2014-04-23 14:38 ` Dmitry A. Kazakov 2014-04-23 15:46 ` J-P. Rosen 2014-04-23 16:27 ` Dmitry A. Kazakov 2014-04-23 16:40 ` J-P. Rosen 2014-04-23 17:39 ` Dmitry A. Kazakov 2014-04-23 21:40 ` J-P. Rosen 2014-04-24 7:42 ` Dmitry A. Kazakov 2014-04-24 9:18 ` J-P. Rosen 2014-04-23 14:06 ` Dmitry A. Kazakov 2014-04-23 14:44 ` björn lundin 2014-04-23 20:28 ` Randy Brukardt 2014-04-24 10:31 ` björn lundin 2014-04-25 1:22 ` Randy Brukardt 2014-04-25 2:19 ` Shark8 2014-04-25 7:31 ` Dmitry A. Kazakov 2014-04-23 14:58 ` björn lundin 2014-04-23 18:05 ` Jeffrey Carter 2014-04-23 19:48 ` Shark8 2014-04-24 9:03 ` G.B. 2014-04-25 1:27 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox