ANN: Units of measurement for Ada v 3.4 released

ANN: Units of measurement for Ada v 3.4 released

[Dmitry A. Kazakov]

The library provides means to handle dimensioned values in Ada. It also
includes GTK+ widgets and renderers for unit selection and rendering
dimensioned values.

   http://www.dmitry-kazakov.de/ada/units.htm

Changes to the version 3.3:

- The widgets and renderers are adapted for the GTK 3.x. GTK 2.x is no more
supported;
- Procedure Split is added to the package Units;
- Only Ada 2005 and Ada 2012 are supported when widgets and renderers are
used. The non-GUI parts of the software remain Ada 95 conform;
- Bug fix in text conversion that led to false output of values with units
like square meter;
- Compiled with GNAT 4.9.

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

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

[Dan'l Miller]

On Monday, June 9, 2014 10:16:59 AM UTC-5, Dmitry A. Kazakov wrote:
> The library provides means to handle dimensioned values in Ada.

Dmitry, have you ever considered expanding your library to include integer, rational, and mixed-radix-positional-numeral-system numbers?    For example, a dozen is a commonplace unit of measure, but what to do with the extra 2 eggs when representing 14 eggs.  Of course, this would be the rational-number case (much like the a b/c functionality on Casio calculators since the early 1980s) where there is an integer portion (a), an integer numerator (b), and an integer denominator (c), where the denominator would be intrinsically 12 for the dozen unit.  From there, mixed-radix positional numbers could be supported as a tuple extrapolation of the a b/c rational-number for, say, 3 gallons 1 quart 1 pint 1 cup 2.5 fluid-ounces in base <Positive, 4, 2, 2, Float> positional numeral system in the proposed functionality of Units of Measure library = 130.5 ounces in the current functionality of Units of Measure library.  From there, mixed-radix positional numeral systems can be defined for various discrete-mathematics problemspaces, such as IEC 60027-2 Amendment 2 and IEEE1541 binary prefixes kibi, mebi, gibi, tebi, and so forth for DRAM as well as conversion to SI kilo, mega, giga, tera, and so forth for spinning mass-storage and teledatacom bandwidth.

Then, from there, time durations could be supported:  4 score 7 years ago or the deceased is aged 72 years 4 months 10 days 6 hours 17 minutes 33.3 seconds, where the base positional-numeral system varies by start-date, due to varying lengths of months and due to leap days & leap seconds.  Then, from there, full calendrical calculations could be added for various currently-in-effect calendars.  Then, from there, proleptic & anachronistic usage of calendars before & after of their intended time period could be added.  And then, :-) you are at version 17 of your library.  It would be an interesting roadmap-arc over several years.  Also, revealing which severe roadblocks (if any) that you hit using Ada2012 in bringing this library to fruition as this flower blossoms would be interesting to fix in Ada202X.

In C++, Boost has served as a most-excllent stressor that motivates the standardization of C++2011 and C++2014.  (Yes, I know, the C++ community drops the century for C++1x/C++11 and C+1y/C++14 as if the Y2K problem never occurred.)  Informally & formally reporting obstacles in writing useful libraries to the language-standardization people can light the fires for change quite tangibly.  Note however Boost libraries distorted modern C++ by institutionalizing metatemplate programming (MTP, via Turing-completeness of their equivalent of Ada generics to form a [disgusting] poor-man's functional-programming language).  In Boost and Loki, these MTP libraries were not viewed as demonstration of how disgusting the technique was to motivate a better solution in language evolution.  Rather a derivative form of some of these MTP libraries in Boost were officially standardized or effectively quasi-standardized as technical reports.  So, Boost should not be mimicked line-by-line or package-by-package, but the general pressure that a de facto standard library development can bring to bear on the syntax & semantics of the language itself can be quite valuable.

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

[Dmitry A. Kazakov]

On Tue, 10 Jun 2014 12:13:42 -0700 (PDT), Dan'l Miller wrote:

> On Monday, June 9, 2014 10:16:59 AM UTC-5, Dmitry A. Kazakov wrote:
>> The library provides means to handle dimensioned values in Ada.
> 
> Dmitry, have you ever considered expanding your library to include
> integer, rational, and mixed-radix-positional-numeral-system numbers?
> For example, a dozen is a commonplace unit of measure, but what to do with
> the extra 2 eggs when representing 14 eggs.

1.16(6) dozens

> Of course, this would be the
> rational-number case (much like the a b/c functionality on Casio
> calculators since the early 1980s) where there is an integer portion (a),
> an integer numerator (b), and an integer denominator (c), where the
> denominator would be intrinsically 12 for the dozen unit.

Rational arithmetic is a different thing. If there is one, it is no problem
to make it dimensioned. Likewise, vectors, arrays, matrices any other
things forming or containing elements of a group. For example:

http://www.dmitry-kazakov.de/ada/fuzzy.htm#4.2

Rational and fixed point dimensioned numbers have the issue of precision
loss if you keep the base unit (as well as radix). There is a historic
anecdote about an US B-bomber landed in USSR during WWII. It was not
returned but carefully disassembled in order to copy it. That didn't work
because inches were used as the "radix" all throughout the design.

> Then, from there, full calendrical calculations could be added for various
> currently-in-effect calendars.

Political time is not a measurement unit.

> Also, revealing which severe roadblocks (if any) that you hit using
> Ada2012 in bringing this library to fruition as this flower blossoms would
> be interesting to fix in Ada202X.

It is kept compilable with Ada 2012. 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.

> In C++, Boost has served as a most-excllent stressor that motivates the
> standardization of C++2011 and C++2014.

Ada's container library existed as an independent project before it was
taken as a template for the standard.

> technical reports.  So, Boost should not be mimicked line-by-line or
> package-by-package, but the general pressure that a de facto standard
> library development can bring to bear on the syntax & semantics of the
> language itself can be quite valuable.

It is difficult to say if language design driven by libraries is good or
bad. STL influenced C++ before Boost.

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

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

[Dan'l Miller]

On Wednesday, June 11, 2014 4:37:13 AM UTC-5, Dmitry A. Kazakov wrote:
> On Tue, 10 Jun 2014 12:13:42 -0700 (PDT), Dan'l Miller wrote:
> > Also, revealing which severe roadblocks (if any) that you hit using
> > Ada2012 in bringing this library to fruition as this flower blossoms would
> > be interesting to fix in Ada202X.
> 
> It is kept compilable with Ada 2012. 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?

> It is difficult to say if language design driven by libraries is good or
> bad. STL influenced C++ before Boost.

http://en.wikipedia.org/wiki/Standard_Template_Library#History
Alexander Stepanov wrote the initial versions of STL in Ada.  C++1998 was heavily influenced by that Ada work to bring C++'s feature-set on parity with Ada.

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

[Dmitry A. Kazakov]

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:
>> On Tue, 10 Jun 2014 12:13:42 -0700 (PDT), Dan'l Miller wrote:
>>> Also, revealing which severe roadblocks (if any) that you hit using
>>> Ada2012 in bringing this library to fruition as this flower blossoms would
>>> be interesting to fix in Ada202X.
>> 
>> It is kept compilable with Ada 2012. 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.
There is a huge distance between mere an idea (programmer's woe) and its
implementation in the form of AI (language design).

Furthermore AI platform is completely unsuitable for big changes. AI is for
minor patches.

And it will never be accepted anyway.

>> It is difficult to say if language design driven by libraries is good or
>> bad. STL influenced C++ before Boost.
> 
> http://en.wikipedia.org/wiki/Standard_Template_Library#History
> Alexander Stepanov wrote the initial versions of STL in Ada.  C++1998 was
> heavily influenced by that Ada work to bring C++'s feature-set on parity
> with Ada.

That is because only Ada had generics that time. Stepanov mistakenly
thought that generics were a way to go.

Templates did no good to C++, generics did even less to Ada. Parametric
polymorphism is corroding to the language structure. It was understandable
in 80's to add generics to the language because the alternative was a
preprocessor of C or PL/1 fashion.

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

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

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

[Dan'l Miller]

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?

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

[Dmitry A. Kazakov]

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