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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.246.196 with SMTP id xy4mr7050360pac.11.1402517877840; Wed, 11 Jun 2014 13:17:57 -0700 (PDT) X-Received: by 10.50.79.137 with SMTP id j9mr6804igx.6.1402517877565; Wed, 11 Jun 2014 13:17:57 -0700 (PDT) Path: border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!a13no1374261igq.0!news-out.google.com!qf4ni19599igc.0!nntp.google.com!a13no1374254igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 11 Jun 2014 13:17:57 -0700 (PDT) In-Reply-To: <1wbo1qf3k00xq.1mdfmh7loqg7t$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: <1rcdrvonn5xqi$.kavo0h1m48kk.dlg@40tude.net> <7a3c3540-323f-4dbe-b27a-cc6f89a30a39@googlegroups.com> <1wbo1qf3k00xq.1mdfmh7loqg7t$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <41ced67d-f3ae-4627-9697-c492eb2c784b@googlegroups.com> Subject: Re: ANN: Units of measurement for Ada v 3.4 released From: "Dan'l Miller" Injection-Date: Wed, 11 Jun 2014 20:17:57 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 5916 Xref: number.nntp.dca.giganews.com comp.lang.ada:186850 Date: 2014-06-11T13:17:57-07:00 List-Id: On Wednesday, June 11, 2014 2:32:05 PM UTC-5, Dmitry A. Kazakov wrote: > On Wed, 11 Jun 2014 11:25:17 -0700 (PDT), Dan'l Miller wrote: > > On Wednesday, June 11, 2014 4:37:13 AM UTC-5, Dmitry A. Kazakov wrote: > >> The things which could improve it are > >> compile-time discriminant expressions and mandatory removal of static > >> discriminants. I don't see them coming anytime soon in Ada. >=20 > > http://www.ada-auth.org/ais.html > > Why not? Have you made the case in officially-submitted Ada Issues (AI= s)?=20 > > Why let Ada languish unimproved when you as an expert (with demonstrabl= e > > concrete examples from in-use libraries) know how to make Ada better? >=20 > Because writing such complex proposal is beyond my knowledge and power. And yet you would gut the entirely of the current Ada type system, rearchit= ect it via a different set of primitives, and set the current Ada type syst= em backwards-compatibly on the new set of primitives. :-) It seems that t= hat is 1 or 2 orders of magnitude more difficult than merely tinkering with= compile-time staticness of discriminants and their mandatory representatio= n per record. Crawl, walk, run. If you ever want to influence on major re= volutions regarding type primitives, then you should get your feet wet on w= hat obviously is the simpler topic. > There is a huge distance between mere an idea (programmer's woe) and its > implementation in the form of AI (language design). Thinking through every nook & cranny of the cascading ramifications of th= e idea hones the idea to be a better idea. Plus, perhaps you will see why = people resist the idea (and you might be able to solve those areas as well,= dismantling resistance, winning converts). > Furthermore AI platform is completely unsuitable for big changes. AI is f= or > minor patches. If lack of compile-time staticness of discriminants and their mandatory rep= resentation per record has demonstrable downsides that your library can dem= onstrate, then I would think that an AI is precisely the proper defect-repo= rting mechanism to the ARG. Compile-time-only discriminants would be a rat= her self-contained cohesive topic with relatively few tentacles elsewhere t= hroughout the Ada language---not some sort of wholesale convulsion of the A= da language into a drastically different language with a drastically differ= ent philosophy. > And it will never be accepted anyway. Why would a good idea with excellent reasoning regarding the idea itself an= d all of its cascading ramifications be rejected without good reason? You = make it sound as though no matter how perfect the technical content is, the= re are nontechnical reasons for dismissal that would trump any technical pe= rfection and any technical-outcome benefit. Although in any group of peopl= e there might be entrenched politics & history, certainly it is not that sc= orched-Earth. > Templates did no good to C++, generics did even less to Ada. Parametric > polymorphism is corroding to the language structure. Specifically what does this corrosion look like? What would the lack of co= rrosion look like? > It was understandable > in 80's to add generics to the language because the alternative was a > preprocessor of C or PL/1 fashion. C++'s trend is to dismantle the need for the preprocessor via ever-increase= d reliance on the functional-programming of metatemplate programming made p= ossible by the accidental discovery that C++'s parametric polymorphism is i= n fact Turing-complete. If C++ templates weren't the best idea before then= , that moment is precisely when the train went off the rails into the abyss= . > Ada should have rid of generics in 95 when proper dynamic polymorphism wa= s > introduced and concentrate efforts on static checks to eliminate dispatch > and tags/discriminants in static cases (the realm of generics, static > polymorphism). I have often wondered this myself: What if the semantics of parametric pol= ymorphism at compile-time and the semantics of runtime polymorphism (e.g., = tagged types in Ada; virtual-function-pointer table in C++) were not repres= ented by drastically different syntaxes? What would that fusion look like?= What disadvantages would be precluded by that fusion? What advantages fo= rtuitously appear in or facilitated by that fusion?