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: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.86.34 with SMTP id m2mr17723wiz.5.1363918565783; Thu, 21 Mar 2013 19:16:05 -0700 (PDT) MIME-Version: 1.0 Path: bp2ni113202wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!216.196.110.142.MISMATCH!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!news.unit0.net!newsfeed.fsmpi.rwth-aachen.de!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: Is this expected behavior or not Date: Mon, 18 Mar 2013 18:13:39 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <513faaf7$0$6626$9b4e6d93@newsspool2.arcor-online.net> <51408e81$0$6577$9b4e6d93@newsspool3.arcor-online.net> <11rcs3gg4taww$.bylek8fsshyz$.dlg@40tude.net> <99929f93-b80f-47c3-8a37-c81002733754@googlegroups.com> <87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com> <78103a2f-5d19-4378-b211-1917175d5694@googlegroups.com> <3p6p8k0yfly7.ctazdw7fc5so$.dlg@40tude.net> <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> <1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1363648421 17863 69.95.181.76 (18 Mar 2013 23:13:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 18 Mar 2013 23:13:41 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-03-18T18:13:39-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net... ... >> That might be less of a problem than you might think; the 'Read and >> 'Write >> should handle the Octet-view while the type as-defined handles the >> Array-of-[[Wide_]Wide_]Character view. > >That would make string tagged, which in turn would imply certain >representation [embedded tag] and forced by-reference semantics. The >consequences are far reaching, e.g. you would have to drop slices etc. For string, requiring by-reference would have little practical effect, as almost all compilers pass strings by-reference anyway. There is no OOP-way to make slicing work, since slices are by definition references (in C-terms, they're an l-value), and since the representations have to vary, that isn't going to be possible. My rough proposed Root_String_Type would be an abstract tagged type, but it wouldn't provide slices directly (it would provide functions for that purpose). But that's OK, because such a construct would have to be alongside the existing string types; we can't replace or change them in any significant way and I think that means we'll have to start over. ... > This is again a key issue. Ada often conflates interface and > representation/implementation. This must be fixed. But I am not even > allowed to name > > subtype Positive is Integer range 1..Integer'Last; > > a type. What would happed if I asked to be able to provide an alternative > representation for Positive? To disallow unary minus? That's easy: nothing would happen. Compatibility with existing code almost always has priority. If you can describe the changes in terms of the existing semantics, then you might have a chance, but if you invent your own terminology and propose to throw out the existing rules, no one is going to pay much attention. Even if you are right (and you may very well be right), it is just too likely to introduce intolerable incompatibilities. ... > I presume that back in 90's there was too much opposition to overhaul the > type system. Tagged types were added to the existing types, while one > should have made classes and interfaces fundamental to all types. We got > an > outbuilding instead of new fundament. [We must be happy that Taft managed > to pressure for at least this change.] You do know that the original Ada 9x design was much like you are describing, with 'Class for all types? 'Class for untagged types eventually got dropped because of various semantics issues (mainly, they just worked differently than the tagged version, and that was thought to be confusing) -- and when people thought that Ada 9x was just too large and stuff had to go, that was one of the first. Of course, for composite types, almost everything should be tagged and controlled (there would have to be a critical memory usage reason to avoid that), and in that case everything works sanely. (Even indexing, given the new Ada 2012 features). So we're mostly talking about scalar type 'Class (we don't need any more anonymous access types of any kind, and they're essentially structural equivalence as it is, so 'Class would buy very little there). I think the more interesting thing is that we've never brought it back. It seems that we haven't seen any truly compelling uses for the idea, because if we had, I'm sure it would have come back in Ada 2005 or Ada 2012. Randy.