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,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.200.202 with SMTP id ex10mr22348510qab.8.1368583492120; Tue, 14 May 2013 19:04:52 -0700 (PDT) MIME-Version: 1.0 Path: y6ni44338qax.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nrc-news.nrc.ca!News.Dal.Ca!citadel.nobulus.com!goblin3!goblin.stu.neva.ru!matrix.darkstorm.co.uk!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Thu, 9 May 2013 16:43:29 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <17ceq51ydy3s0.s94miqqzbg5w.dlg@40tude.net> <1vrhb7oc4qbob$.q02vuouyovp5$.dlg@40tude.net> <19lrzzbgm77v6.1dzpgqckptaj6.dlg@40tude.net> <1bp6zlpetr5l4.12a9zcd1x3yya.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368135811 29163 69.95.181.76 (9 May 2013 21:43:31 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 9 May 2013 21:43:31 +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-05-09T16:43:29-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1bp6zlpetr5l4.12a9zcd1x3yya.dlg@40tude.net... > On Wed, 8 May 2013 15:12:38 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:p0pf97g5w6xg.jhca6ztjwpde$.dlg@40tude.net... > >>> What I wish is to change the language foundation while keeping the >>> semantics of existing types intact. The whole idea is to move them onto >>> the library level rather than changing anything in them. >> >> That's precisely what I'm talking about. The result cannot be Ada, >> because >> the result is not going to be close to 100% compatible with Ada (and that >> should not be a criteria for a new language). > > I don't see obvious reason why. It is not about reworking exiting built-in > types and type-algebraic operations. There is nothing wrong with them. > >> Despite your fantasies to the >> contrary, there is no possibility of changing the models in any useful >> way >> and retaining compatibility in subtle cases. Moreover, even if possible, >> the >> pretzel-like rules needed would prevent the sort of overhaul that you >> really >> desire. So why cling to the mistakes of the past - flush all of that down >> the drain and start over. > > Because most of Ada semantics is OK. I don't see any mistakes. Even if > they > were, it is irrelevant because I am looking for a more general model, > where > mistake or not, it becomes just an implementation. So if you don't like a > particular built-in type for whatever reason, you make your own. No > problem. When you say "semantics", you're really only talking about the dynamic semantics, that is the runtime model. But the compile-time model is just as important. You would have to reproduce every feature and flaw of the existing compile-time model with a totally new underlying model. And doing that would be very, very complex. The problem is, when you do that, you'd have no way to determine whether or not it is really compatible. (After all, there is no formal model for Ada, and there never has been.) Ada's definition is just a mass of English text, and replacing it by a different mass of English text leaves one no practical way to prove compatibility. And it is very unlikely that there would be any interest in an incompatible version of Ada. Moreover, no one would be much interested in a version that's *almost* like Ada but would break almost everyone's code. If one starts over, you eliminate that need for absolute compatibility. You might still be fairly close to the semantics of Ada (although I don't see the point; it should be simplified by removing corner cases and little used stuff and features that are duplicative), but there is no need to prove compatibility (or convince anyone of it). And you could fix obvious mistakes of Ada (objects don't overload, for one example, and the more general user-defined indexing that you would like, and so on) without having to worry about the effects in private parts of nested packages -- which is what prevents most progress today. Randy.