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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.152.217 with SMTP id h25mr1246880bkw.3.1337063409191; Mon, 14 May 2012 23:30:09 -0700 (PDT) MIME-Version: 1.0 Path: e27ni3800bkw.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!news.tu-darmstadt.de!news.internetdienste.de!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Tue, 15 May 2012 01:30:03 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1337063407 25677 69.95.181.76 (15 May 2012 06:30:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 15 May 2012 06:30:07 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-05-15T01:30:03-05:00 List-Id: "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. ... >> 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. Just a bit: the string types have functions that convert through a universal representation. I used that because it was available, but it would work just as well with conversions directly between the various representations. ... > 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? Yes, of course, there would be a version of everything that takes a String that would take a Root_String'Class. (I don't think there are many routines that take "out" String parameters, because you can't change the size that way.) >> 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. 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. 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 (surely including your enumeration example). Randy.