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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 11 Jun 2014 13:17:57 -0700 (PDT), Dan'l Miller wrote:

> 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.

I don't think so. Discriminant removal requires abstraction of the object
representation and a mechanics of reconstructing the discriminant when
statically discriminated objects are passed to subprograms dealing with the
whole range of the discriminant. These are analogous (in fact equivalent
to) to class-wide operations.

The idea is that tag is nothing but a discriminant. There must be a
universal mechanism to deal with this.

Most people are not even ready to agree that a constrained subtype is a
type different from the unconstrained one.

> 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.

No. An analogy would be, when you sit in a local optimum, small increments
will never get you to the global one.

The small deeds theory does not work with language design. In fact all
languages degrade when incremental changes are applied.

>> 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).

The problem is to communicate the idea. Proposals are usually discarded
without consideration out of gut feeling. There is a handy mantra for this
"it would be incompatible to Ada."

>> 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.

There is nothing to demonstrate. It is *evident* that the discriminant
representing a measurement unit is space and time overhead when statically
known.

Furthermore, considering the language change, the mechanism shall support
propagating of discriminants and other constraints across the container
types and other types aggregating the discriminated one. Consider an array
of dimensioned values. You want discriminants of array elements removed and
single discriminant attached to the array as whole. Note how this again is
correlated to tags and other constraints:

   type List (Length : Natural) is
      array (Positive range <>) of String (1..Length);

Here is an array of same-length strings.

   type T is tagged ...;
   type List (Type_Tag : Tag) is
      array (Positive range <>) of T'Class (Type_Tag);

Here is an array of class-wide object, all of the same type, unknown until
run-time.

   type T is tagged ...;
   type Pointer (Type_Tag : Tag) is access T'Class (Type_Tag);

Constrainable pointer type. Etc.

>> 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.

This is how it works. Otherwise, nobody would ever use C, Java, Windows,
Linux, x86 and other inferior technologies dominating the world.

Don't ask me why, group dynamics is outside my scientific interest, if one
could call it science.

>> 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?

For each language primitive you get a generic counterpart. Generics form a
meta language relatively to the object, non-generic, core language. If
generics are any good, why not to abandon the object language?

>  What would the lack of corrosion look like?

Having two interweaved languages makes it incredibly complex. Language
issues are not addressed because there exist generic workarounds, which
look good-enough.

>> 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?

It is not different syntaxes, it is two different languages.

Dynamically polymorphic objects are proper objects of proper types. The
whole idea of having it is to get class-wide objects and types *in* the
language. A class-wide type is a substitute for a set of types, but it is a
proper type itself, with values operations etc.

Parametrically polymorphic things are entities of a meta language. Only
their instances are proper objects, types, packages of the object language.

> What disadvantages would be precluded by that fusion?  What
> advantages fortuitously appear in or facilitated by that fusion?

There is no advantages in having a meta language. The object language
should be fixed instead.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de