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 o5mr1120449bkw.0.1337284186428; Thu, 17 May 2012 12:49:46 -0700 (PDT) Path: e27ni4459bkw.0!nntp.google.com!news1.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!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: Thu, 17 May 2012 22:48:31 +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 Wb3donPo0Wpp3ne32RxOKg9iZtsyYsCwcu7HQ/JeNkDv02w0OileGKRT2EgnVD7qKZ Cancel-Lock: sha1:W7B0ky44yUYJmq5ghg73Hmux/dY= 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-17T22:48:31+03:00 List-Id: On 12-05-15 09:30 , Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:a1ahq2F7e2U1@mid.individual.net... >> 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. > > "Conversion" is almost never a single function; indeed, Ada requires it to > work both ways in most cases. In particular, if you have "out" parameters, > you need a conversion from the parent to the child type, just like you need > a conversion from the child to the parent to implement "in" parameters. That is how it works in Ada now, yes. Well, except for the view conversions of tagged types et c., I would say. >> 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? > > Yes, of course, there would be a version of everything that takes a String > that would take a Root_String'Class. Ok, that is consistent. The implementation of Ada.Directories on the current system decides which concrete kind of string is proper for this system, and returns such an object, but seen as Root_String'Class by the caller. > (I don't think there are many routines > that take "out" String parameters, because you can't change the size that > way.) But in general, how would "out" parameters of type Root_String'Class (or SomeType'Class) work? Of course the subprogram can call operations like Set_Char on the parameter to alter its value, but what about a whole-object assignment, Parameter := Value? I guess that must raise Constraint_Error if the new Value does not match the actual Parameter in type or discriminants. > The problem is that the language doesn't provide the syntax to connect the > "hand-built" conversions with the existing machinery of (sub)type > conversion; I'm assuming that would be done if the conversion solution was > intended to be used as a first-class technique. Yes, I think I see what you mean. > Specifically, when you "derive" a new type from an existing type, the idea > is that you could give the derived type any declaration and representation > you want (it wouldn't have to be related to the parent, with some limits), > and you could then define conversion functions (always two) similarly to the > way that streaming subprograms are defined. Inherited routines would use > those conversions when conversions are needed (as already defined by the > language). That would allow one to have very unrelated types be "related" > via derivation. > > I'm not sure that it is good idea in general, but certainly it makes sense > in limited cases Same sentiments here (I assume by "limited cases" you don't mean "limited types" in the Ada sense). The main limitation, I think, is that the derived type cannot be much more "meaningful" -- that is, carry more information -- than the parent type; if it is, the conversion from parent to derived would have to supply the additional information, from nothing. > (surely including your enumeration example). I don't think so, because the "deepened" enumeration type has more information than the parent type. In the example I gave, the derived-type literals Read and Write convert to the parent-type literal Request, but the conversion back from Request to the derived type would have to choose either Read or Write, and it has no information to guide that choice. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .