From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,81bb2ce65a3240c3 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.154.133 with SMTP id o5mr549916bkw.0.1336938820201; Sun, 13 May 2012 12:53:40 -0700 (PDT) Path: h15ni4582bkw.0!nntp.google.com!news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sun, 13 May 2012 22:53:38 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> Mime-Version: 1.0 X-Trace: individual.net I9Tg9SkBiYxAN7WQ4WTNIAdFS3B0skvUwS26UYjy0uIiB5BaPjjRC6AeipLbU2qzgM Cancel-Lock: sha1:gKLgpEc/7X9G/I2MHnXpgD77SRo= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-13T22:53:38+03:00 List-Id: On 12-05-10 03:47 , Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net... >> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote: >>> I would like to make the "deepening" derivation as similar as possible >>> to the derivation of enumeration types in >> >> With the problems solved you will get enumeration extension for granted. >> Your proposal rounds about how to generate conversion functions. You can >> generate in-conversion, but cannot out-conversions. The case of plain >> extension has the opposite problem: in-conversions are impossible. But the >> mechanics of all this is same: interface inheritance, delegation of some >> inherited operations to the parent's body composed with a conversion. >> >> Semantically, there always will be some issue with conversions, because >> any >> non-trivial modification of a type, must break something. If it did not, >> you would use the old type instead. It is not the language business, it is >> up to the programmer to resolve. The language should simply refuse to >> automate suspicious cases forcing the programmer to intervene. > > Here I agree with Dmitry (but note that the mechanism he is talking about > here has nothing to do with multiple inheritance; it works just fine with > Ada 95 type derivation or something similar to that). I agree with Dmitry's and your rejection of automated but suspect conversions, which is why I suggested not to inherit parent operations that would need conversion from the parent enumeration type to the "deepened" enumeration type. I could also accept the alternative to inherit abstract versions of such parent operations, which would be more useful for class-wide programming. But I don't see how a single programmer-defined conversion function from the parent type to the deepened type could work in general, that is, how the same conversion would be appropriate for all "out", "in out", and function-return positions in all parent operations. And if different conversion functions are needed for different operations/parameters, we may as well choose "inherit as abstract" and require the programmer to implement these operations for the derived type. > It makes more sense to > allow the programmer to provide the needed conversion functions than to come > up with special features for doing that. The goal of the "deepening extension" for enumerated types is not to define conversion functions, but to create classes of enumeration types with logical (and hopefully useful) relationships (refinement of classifications). The conversion function arises naturally from the relationship. (Which of course does not mean that this particular kind of relationship is useful enough to merit specific support in the language.) > I designed a straw-man "Root_String" around such conversion functions (you > can find it in AI12-0021-1), Thanks for the pointer. I have read the AI, but I'm not sure which "conversion functions" you mean, and how the AI relates to the present discussion. The AI defines an interface Root_String with (among others) operations Set_Char and Get_Char to set or get the N'th character of the string, as a Wide_Wide_Character. The AI then suggests concrete instances that implement the Root_String interface using a String representation, or an UTF_8_String representation, which means that the instances must implement Set_Char and Get_Char that convert between Character and Wide_Wide_Character, or a UTF-8 encoding and Wide_Wide_Character, respectively. Are these the "conversion functions" that you mean? But they don't convert between Root_String and its instances, they just adapt the Root_String operations to various representations. This is "conversion" in some abstract sense, but not a conversion of a whole string value from one "string" type to another "string" type. The AI suggests that "most of the IO routines that take strings would have versions that would take Root_String'Class" and that "the string types would carry their representation along when passed into routines". I can understand how that works for "in" parameters, but it is not so clear for "in out" parameters and function return values. For example, the function Ada.Directories.Current_Directory now returns String; how would that, and other I/O functions that return String, be handled? Would they return Root_String'Class? > This wasn't vetted by anyone, so take it with a grain of salt... > but it illustrates the possibilities. I think Root_String is a special case, because the only real difference is in the representation of the string characters. Also, Wide_Wide_Character fortuitously provides a universal representation (in the current language). I'm not denying that such hand-built conversions/adapters can be useful, but (so far) they seem a bit clumsy compared to more integrated type constructions such as tagged type classes. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .