Re: ANN: Units of measurement for Ada v 3.4 released

["Dan'l Miller" <optikos@verizon.net>]

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.
> 
> > http://www.ada-auth.org/ais.html
> > Why not?  Have you made the case in officially-submitted Ada Issues (AIs)? 
> > Why let Ada languish unimproved when you as an expert (with demonstrable
> > concrete examples from in-use libraries) know how to make Ada better?
> 
> Because writing such complex proposal is beyond my knowledge and power.

And yet you would gut the entirely of the current Ada type system, rearchitect it via a different set of primitives, and set the current Ada type system backwards-compatibly on the new set of primitives.  :-)  It seems that that is 1 or 2 orders of magnitude more difficult than merely tinkering with compile-time staticness of discriminants and their mandatory representation per record.  Crawl, walk, run.  If you ever want to influence on major revolutions regarding type primitives, then you should get your feet wet on what 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 the 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 for
> minor patches.

If lack of compile-time staticness of discriminants and their mandatory representation per record has demonstrable downsides that your library can demonstrate, then I would think that an AI is precisely the proper defect-reporting mechanism to the ARG.  Compile-time-only discriminants would be a rather self-contained cohesive topic with relatively few tentacles elsewhere throughout the Ada language---not some sort of wholesale convulsion of the Ada language into a drastically different language with a drastically different philosophy.

> And it will never be accepted anyway.

Why would a good idea with excellent reasoning regarding the idea itself and all of its cascading ramifications be rejected without good reason?  You make it sound as though no matter how perfect the technical content is, there are nontechnical reasons for dismissal that would trump any technical perfection and any technical-outcome benefit.  Although in any group of people there might be entrenched politics & history, certainly it is not that scorched-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 corrosion 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-increased reliance on the functional-programming of metatemplate programming made possible by the accidental discovery that C++'s parametric polymorphism is in 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 was
> 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 polymorphism at compile-time and the semantics of runtime polymorphism (e.g., tagged types in Ada; virtual-function-pointer table in C++) were not represented by drastically different syntaxes?  What would that fusion look like?  What disadvantages would be precluded by that fusion?  What advantages fortuitously appear in or facilitated by that fusion?