CVS difference for acs/ac-00184.txt

Differences between 1.1 and version 1.2
Log of other versions for file acs/ac-00184.txt

--- acs/ac-00184.txt	2010/02/10 06:06:04	1.1
+++ acs/ac-00184.txt	2010/02/10 06:39:44	1.2
@@ -430,6 +430,684 @@
 
 ****************************************************************
 
+From: Christoph Grein
+Date: Thursday, October 29, 2010  7:45 AM
+
+> I was on a project where we used such a package for development.
+> Once we had the units straight, for production we replaced the
+> discriminated record type with a straight floating-point type.
+> This worked very well.
+
+This is exactly what my SI units package can do.
+
+In case you do not have the AE 2003 paper, you can find it here:
+
+http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension.html
+
+****************************************************************
+
+From: Christoph Grein
+Date: Thursday, October 29, 2010  7:45 AM
+
+Basically I am on Randy's side (i.e. I don't think that it's worth the effort to
+add dimensions to Ada), but I'm very curious to see how AdaCore's (Ed's)
+proposal works out.
+
+subtype ESU is CGS_Value;  -- charge: g**(1/2) * m(3/2) / s pragma Dimension (esu, 3/2, 1/2, -1);
+
+How do you specify which numeric pragma parameter defines which fundamental
+unit? So which is which in the line above? How many of them may there be? MKS 3,
+MKSA 4, Gaussian CGS 4, (full) SI 7. Is it customizable? Astrophysics might use
+sun masses, parsecs, centuries as fundamental units (dunno).
+
+Someone might even use it for currencies and define a "dimension" for each one:
+Euro ?, US-$, Swiss Francs, Turkish Lira ... Are there then 20 or more numeric
+parameters in pragma Dimension, as many currencies as this someone is going to
+consider?
+
+XYZ: MKS_Value := Some_Complicated_Formula;  -- which dimension does this have?
+
+This must be dynamically typed (and then constrained to the initial dimension).
+
+ABC: MKS_Value;  -- which dimension here? Is this illegal?
+
+ABC might be needed for some intermediate value - who cares for its dimension.
+It most probably will be an awful combination of fundamental units without a
+name.
+
+****************************************************************
+
+From: Christoph Grein
+Date: Thursday, October 29, 2010  7:54 AM
+
+> Basically I am on Randy's side (i.e. I don't think that it's worth the
+> effort to add dimensions to Ada), but I'm very curious to see how
+> AdaCore's (Ed's) proposal works out.
+
+There is an erratum to the AE 2003 paper you can also find here:
+http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension.html
+It states:
+"There are embarrassing details of the fiasco that are not included in the
+reports -- primarily management failures."
+
+This is why I don't believe in unit checking added to Ada - the problems are
+normally buried somewhere else.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Thursday, October 29, 2010  12:33 PM
+
+> Basically I am on Randy's side (i.e. I don't think that it's worth the
+> effort to add dimensions to Ada),
+
+I disagree. Dimensions themselves might be of little importance. The language
+mechanics necessary to express constraints similar to ones dimensions impose on
+the operations is of an immense importance for the whole language. I strongly
+believe that we should not build dimensions into the language. Instead of that
+we should extend it so that an implementation of dimensions became possible at
+the library level.
+
+> How do you specify which numeric pragma parameter defines which fundamental
+> unit? So which is which in the line above? How many of them may there be? MKS
+> 3, MKSA 4, Gaussian CGS 4, (full) SI 7. Is it customizable?
+
+That is the reason why Unit should be a compound type. You could pack there as
+much components you wanted. The compiler should compare Unit on equivalence =,
+and calculate Unit*Unit, Unit/Unit, Unit**Power. These operations should be
+abstract, provided by the programmer.
+
+> Astrophysics might use sun masses, parsecs, centuries as fundamental units
+> (dunno).
+
+Hmm, these are still M, L, T, nothing new.
+
+> But that Someone might even use it for currencies and define a "dimension" for
+> each one: Euro ?, US-$, Swiss Francs, Turkish Lira ...
+
+From a unit system point of view it would make no sense. The dimension is
+"currency" in all cases.
+
+> ABC might be needed for some intermediate value - who cares for its dimension.
+
+Yes, this is a strong argument in favor of dynamic dimensions support, even if
+actually all units are statically known, they aren't to the programmer.
+
+We will always return the fundamental issue of the compiler removing memory and
+time overhead imposed by static constraints. The case of units is a mere
+illustration why this technique, if existed, would be so great language
+improvement.
+
+****************************************************************
+
+From: Robert C. Leif
+Date: Thursday, October 29, 2010  1:17 PM
+
+From the time of Bill Whitaker, many of us, who are engaged in engineering
+and/or science have desired a means to check units in Ada at compile time
+without having any significant run-time overhead. This is effectively what we
+did in the age of slide-rules. Bill Whitaker has already provided what appears
+to be an adequate solution if one would permit run-time checking. I believe that
+the use of a pragma is to be preferred to any increase in the complexity of the
+Ada language. Could you conjure up a compile-time only check where the generated
+code would omit the run-time checking? This could also be a compile time only
+assertion.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Thursday, October 29, 2010  2:00 PM
+
+> How do you specify which numeric pragma parameter defines which fundamental
+> unit? So which is which in the line above? How many of them may there be? MKS
+> 3, MKSA 4, Gaussian CGS 4, (full) SI 7. Is it customizable? Astrophysics might
+> use sun masses, parsecs, centuries as fundamental units (dunno).
+
+Most likely we want names for the pragma arguments, and those not mentioned
+default to zero.
+
+> Someone might even use it for currencies and define a "dimension" for each
+> one: Euro ,, US-$, Swiss Francs, Turkish Lira ... Are there then 20 or more
+> numeric parameters in pragma Dimension, as many currencies as this someone is
+> going to consider?
+
+We were discussing internally such uses (someone suggested the need for
+computing dollars per furlong, which I suppose is some measure of the
+productivity of race horses).  My sense is that all of this is of interest
+chiefly for scientific and engineering computations, and there is no point in
+extending this model farther.  For anything involving currency, I would think
+that we want decimal types anyway. not floating-point ones.
+
+> XYZ: MKS_Value := Some_Complicated_Formula;  -- which dimension does this have?
+
+This must be dynamically typed (and then constrained to the initial dimension).
+
+> XYZ gets its dimensions from the rhs, and indeed this becomes constrained.
+
+> ABC: MKS_Value;  -- which dimension here? Is this illegal?
+
+I would make this illegal.  If dimensional checking is some specialized form of
+a typing discipline, there is no point in encouraging untyped constructs.
+
+> ABC might be needed for some intermediate value - who cares for its dimension.
+> It most probably will be an awful combination of fundamental units without a
+> name.
+
+Then it should be initialized. Leaving it like this is an invitation for
+multiple uses of ABC with different dimensions, a sure recipe for mistakes.
+
+In any case, my intent is obviously much more modest that your comprehensive set
+of packages.  I wanted to ask you about the user feedback you have gotten for
+it:  if it has been embraced by the community as the proper way to perform
+dimensional analysis, there might be no point in a compiler-based tool, we
+should just point anyone who brings up the topic to
+   http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension.htm
+
+(which everyone interested in the topic should read in any case)
+
+****************************************************************
+
+From: Jeffrey C. Carter
+Date: Thursday, October 29, 2010  2:21 PM
+
+> This is exactly what my SI units package can do.
+
+Sounds good. The project was c. 1996 and used Ada 83.
+
+****************************************************************
+
+From: Bob Duff
+Date: Thursday, October 29, 2010  2:44 PM
+
+> We were discussing internally such uses (someone suggested the need
+> for computing dollars per furlong, which I suppose is some measure of
+> the productivity of race horses).
+
+This web site:
+
+http://itotd.com/articles/286/furlongs-per-fortnight/
+
+says that the speed of light is exactly 1,802,617,500,000 furlongs per
+fortnight, which fits nicely into your scheme, as I understand it.  ;-) But I
+don't believe the "exact" part.
+
+****************************************************************
+
+From: Christoph Grein
+Date: Friday, October 30, 2010  2:53 AM
+
+> Most likely we want names for the pragma arguments, and those not
+> mentioned default to zero.
+
+But which names? It's rather arbitrary what you take as a base unit.
+SI chose Ampere because current is easier measurable than charge.
+
+British units use BTU as a fundamental unit for one of energy, power, work
+(don't know which) if I'm not too mistaken where SI has a derived unit instead.
+How you will deal with this?
+
+[Need some more pragmas to first define the basic unit names that will later be
+used in pragma Dimension ;-)]
+
+What if you want two systems, e.g. {m, s} and {nautical miles, knots} in
+parallel?
+
+> ABC: MKS_Value; -- which dimension here? Is this illegal?
+>
+> I would make this illegal. If dimensional checking is some
+> specialized form of a typing discipline, there is no point in
+> encouraging untyped constructs.
+
+Yes, necessarily, if you want checking during compile time.
+
+> Then it should be initialized. Leaving it like this is an invitation
+> for multiple uses of ABC with different dimensions, a sure recipe for
+> mistakes.
+
+This would mean we have to insert local declares everywhere we need an
+intermediate value. Desirable? But inevitable.
+
+> In any case, my intent is obviously much more modest that your
+> comprehensive set of packages.  I wanted to ask you about the user
+> feedback you have gotten for it:
+
+None for the SI units package, Big Bang to Universe is used here in several
+airborne systems, no feedback from others; and I don't know whether Dmitry has
+some for his packages.
+
+****************************************************************
+
+From: Niklas Holsti
+Date: Friday, October 30, 2010  3:53 AM
+
+> What if you want two systems, e.g. {m, s} and {nautical miles, knots} in
+> parallel?
+
+I may be misunderstanding the discussion, but it seems to me that two different
+issues are involved, and should be separated:
+
+- First, checking physical dimensions. The goal is to prevent errors such as
+  adding a length (meters) to an area (meters*meters). Any attempt to do so is
+  an error.
+
+- Second, checking physical units. The goal is to prevent errors such as adding
+  a length in meters to a length in feet. An attempt to do so could be
+  classified as an error, or could conceivably invoke an implicit rescaling of
+  one or both operands (I would not want such automatic rescaling, however).
+
+The AdaCore proposal (which I rather like) so far seems to address only the
+first issue, dimensions, and not the second issue, units, which Christoph is
+asking about. The AdaCore proposal could be extended to handle some of the units
+issue by adding a pragma parameter that names the system of units (eg. "MKS")
+and requiring at compile-time that all operands in an expression must use the
+same system of units. There would be a small set of predefined systems of units.
+Conversions between units (eg. feet to meters) would be unchecked.
+
+Another way would be to extend the dimension values in the pragma to include the
+name or abbreviation of the unit, for example
+
+    pragma Dimension (esu, (3/2,"m"), (1/2, "g"), (-1, "s"));
+
+The compiler could then check that all operands use the same unit names.
+
+I wonder if it would be useful to formulate this dimensions/units question using
+the concepts of aspect-oriented programming? In this view, the AdaCore pragma
+specifies an aspect of a subtype, and the compiler treats the assignments and
+application of arithmetic operations on these subtypes as cutpoints, where
+aspect-specific rules are applied (at compile-time) to check that the incoming
+aspect values (operand dimension and perhaps units) are compatible, and to
+derive outgoing aspect values (result dimensions and perhaps units).
+
+****************************************************************
+
+From: Franco Gasperoni
+Date: Friday, October 30, 2010  6:30 AM
+
+> Another way would be to extend the dimension values in the pragma to
+> include the name or abbreviation of the unit, for example
+>
+>     pragma Dimension (esu, (3/2,"m"), (1/2, "g"), (-1, "s"));
+>
+> The compiler could then check that all operands use the same unit names.
+
+That is interesting. One possibility - rather than using strings - would be to
+use type names directly. Let me put on the table an extension of Ed's proposal
+to all units and unit systems
+
+    package Predefined_Units is
+
+       --  The "mother" of all units
+
+       type Some_Unit is new Long_Float;
+       pragma Universal_Unit (Some_Unit);
+
+       --  Some "core" units
+
+       subtype Meters  is Some_Unit;
+       subtype Seconds is Some_Unit;
+
+       --  Some "multi-dimensional" units
+
+       subtype Meter_2 is Some_Unit;
+       pragma Dimension (Meter_2, Meter, 2);
+
+       subtype Velocity is Some_Unit;
+       pragma Dimension (Velocity, Meters, 1, Seconds, -1);
+
+       subtype Acceleration is Some_Unit;
+       pragma Dimension (Acceleration, Velocity, 1, Seconds, -1);
+
+       --  Some "scaled" units
+
+       subtype Millimiters is Some_Unit;
+       mm_2_m : constant := 0.001;
+       pragma Conversion (mm_2_m, Millimeters, Meters);
+
+       subtype Feet is Some_Unit;
+       ft_2_m : constant := 0.3048;
+       pragma Conversion (ft_2_m, Feet, Meters);
+
+       --  Some constants
+
+       m   : constant Meters       := 1.0;
+       mm  : constant Millimiters  := 1.0;
+       ft  : constant Feet         := 1.0;
+       sec : constant Second       := 1.0;
+       g   : constant Acceleration := 9.81 * m / (sec ** 2);
+
+and now let's use this package:
+
+       ...
+       L1 : Feet        := ...;
+       L2 : Millimiters := ...;
+       L3 : Meters      := ....;
+       T  : Seconds     := ...;
+
+       V  : Velocity := (L1 * ft_2_m + L2 * mm_2_m + L3) / T;
+
+If for some reason we mistakenly wrote
+
+       V  : Velocity := (L1 + L3) / T;
+or
+       V  : Velocity := L1 / T;
+
+we would get a compile-time warning (or error if we asked the compiler to treat
+this type of warning as an error).
+
+Ed's proposal like this extended version of Ed's proposal requires a restricted
+symbolic manipulation engine which should be within the realm of compiler
+implementation.
+
+****************************************************************
+
+From: John Barnes
+Date: Friday, October 30, 2010  6:09 AM
+
+I wouldn't bother about ridiculous units such as nautical miles and knots.
+How about the Flemish Ell and English scruple?
+
+I was brought up on cgs (centimetre, gram, second).  It is curious that the gram
+is quite small and that the metre is quite large otherwise the obvious system
+would be mgs.
+
+What do you mean Big Bang to Universe?
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Friday, October 30, 2010  9:17 AM
+
+This topic seems to have awakened the language designer / tool
+designer in the community!   I think the problems to be addressed, in
+order of decreasing importance, are the following:
+
+a) Provide a mechanism for defining a set of units
+
+b) Provide a tool for dimensional checking within a given system of units.
+
+c) Provide a mechanism to check mixed use of several systems of units
+
+d) Provide a user-friendly I/O system for display dimensioned values with their
+   names.
+
+
+For a), we need a set of names and a numeric type.
+
+       type MKS_Names is (Meter, Kilogram, Second, ....Candela);
+       type MKS_Value is new Long_Float;
+       pragma Dimension_Names (MKS_Value, MKS_Names);
+
+and then specific quantities are defined by subtypes, for example::
+
+        subtype Length is MKS_Value;
+        pragma Dimensions (Length, meter => 1);  --  named association available, default values
+
+        m : constant Length := 1.0;
+
+etc.  All of this appears within package MKS_Types. The same scheme can be used
+to define other systems of units:
+
+       type Electrotechnics_Names is (Volt, Ampere, Second);
+       type Electrotechnics_Value is new Long_Float;
+       etc.
+
+      type Old_Saxon_Names is (Furlong, Dram, Fortnight);
+      type Old_Saxon_Value is new Float;
+      ...
+
+b) Is provided within the compiler in the obvious way.
+
+Requirement c) seems to me less important, and here Ada provides already the
+first step:  diferent sets of units have different numeric types. It is
+reasonable to require users to describe their formulae in one consistent system.
+If an expression mixes meters and furlongs, it will simply get a type error.
+However, there is an occasional need to mix units, and then the user will have
+to supply explicit conversions.  Ideally, those conversions would provide the
+proper scaling factors, but the simple scheme proposed here cannot achieve this
+for free. Without more machinery it's not possible to indicate that meters and
+furlongs are in fact dimensionally compatible.  This does not seem critical (if
+the existence of the MKS package encourages the world to rally once and for all
+around the decimal system, the much the better!). Judicious use of names can
+help, but is not fool-proof
+
+        seconds_per_fortnight: constant := 14 * 24 * 3600.0
+
+d) will be helped by the use of dimension names, but nothing as ambitious as
+   Christoph's SI package I/O facilities is being proposed for now.
+
+****************************************************************
+
+From: Jeffrey R. Carter
+Date: Friday, October 30, 2010  1:02 PM
+
+> I was brought up on cgs (centimetre, gram, second).  It is curious
+> that the gram is quite small and that the metre is quite large
+> otherwise the obvious system would be mgs.
+
+Yes. It seems the definition of the gram is "wrong". If the unit of length is
+the meter, then the unit of mass should be the mass of a cubic meter of water
+[what we currently call a ton(ne)].
+
+It's also curious that we use the same time unit in both systems. If the idea is
+that "large" units have to be used together, shouldn't the time unit be larger
+for the system with the larger length and mass units?
+
+It's also curious that the length and time units are arbitrary, while the mass
+unit is derived from the length unit and from the nature of the universe. A
+second is a non-decimal fraction of the mean solar day, and the meter a
+non-decimal fraction of the circumference of the Earth, but the gram is the mass
+of a cubic centimeter of water.
+
+It always seemed to me that having selected a time unit, which is arbitrary, one
+should generate the length unit from a decimal multiple of the distance light
+travels in that time, and the mass unit can then be generated from that length
+unit.
+
+But this seems to be a tad OT.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Saturday, October 31, 2010  3:37 AM
+
+> Yes. It seems the definition of the gram is "wrong". If the unit of
+> length is the meter, then the unit of mass should be the mass of a
+> cubic meter of water [what we currently call a ton(ne)].
+
+That depends on the pressure and temperature. And why water and not air, gold,
+or for that matter the ARM (Springer Edition)? (:-))
+
+BTW, the unit of mass is kg, not g. SI is good balanced.
+
+Yet, for example, atmospheric pressure goes into hPa (100 Pa), capacitance is
+too big (Farad), cars are too speedy for m/s etc.
+
+> It's also curious that we use the same time unit in both systems. If
+> the idea is that "large" units have to be used together, shouldn't the
+> time unit be larger for the system with the larger length and mass units?
+>
+> It's also curious that the length and time units are arbitrary, while
+> the mass unit is derived from the length unit and from the nature of
+> the universe. A second is a non-decimal fraction of the mean solar
+> day, and the meter a non-decimal fraction of the circumference of the
+> Earth, but the gram is the mass of a cubic centimeter of water.
+
+Meter was introduced by the French Academy of Sciences from the Earth's meridian
+length in XVIII century.
+
+Second was a 60th part of hour, which was again derived from an Earth's
+constant. (The factor 60 is because of Babylonians.)
+
+> It always seemed to me that having selected a time unit, which is
+> arbitrary, one should generate the length unit from a decimal multiple
+> of the distance light travels in that time, and the mass unit can then be generated from that length unit.
+
+The first motivation behind unit choices has always been an ability to create
+master copies. So the first units used human body (e.g. foot). Later one
+switched to the Earth measures, because it has less variety than humans.
+Presently units are based on kernel physics.
+
+****************************************************************
+
+From: Stephen Leake
+Date: Saturday, October 31, 2010  10:40 AM
+
+> This topic seems to have awakened the language designer / tool
+> designer in the community!   I think the problems to be addressed, in
+> order of decreasing importance, are the following:
+>
+> a) Provide a mechanism for defining a set of units
+>
+> b) Provide a tool for dimensional checking within a given system of
+> units.
+>
+> c) Provide a mechanism to check mixed use of several systems of units
+>
+> d) Provide a user-friendly I/O system for display dimensioned values
+> with their names.
+
+This is a good list.
+
+It doesn't have to be in the compiler; an ASIS-based tool, or a SPARK feature,
+would be more appropriate, I think. SPARK would be able to extend the units
+analysis into generics and shared subprograms whose units must be dynamic.
+
+****************************************************************
+
+From: Robert Leif
+Date: Saturday, October 31, 2010  12:47 AM
+
+I have worked through units in the XML Schema Definition Language (XSDL).
+Since XSDL data-type definitions can and should be made as a one-to-one
+correspondence to those in an Ada specification, my XSDL results are relevant to
+Ada.
+
+I separate the prefixes from the units. The prefixes and units can each have
+multiple formats. There are multiple ways to abbreviate them. I have attached a
+zip file that contains the relevant schemas. I believe that it would be useful
+to have Ada output XML that conforms to parts of these schemas. I have included
+one schema about.xsd that serves as a template for the header sections of all of
+my CytometryML schemas. The information in the UCUM schema is based on others'
+work (1). The CytometryML collection of schemas is located at
+http://www.newportinstruments.com/cytometryml/cytometryml.htm.
+
+I suspect that the take-home lesson from my work is that a knowledge of Ada
+really helps when one works with other languages. In fact if Ada companies want
+to work in multiple languages, there may be significant profit in XML products.
+GNAT tools are far more mature than I presently use for XML schema.
+Unfortunately neither of the two products that I use, XMLSpy nor Stylus Studio,
+provide a make file. XSDL does not use any library technology to keep track of
+the files. The result is cumbersome. In this regard Ada is far superior.  I have
+observed some practices that I do not believe would have occurred had the
+programmers known Ada and software engineering. These include the use of case to
+distinguish data-types and two letter names for a significant number of
+data-types. The naming of schemas (packages) after the code-names of the
+committees that were responsible for their creation.
+
+1) The Unified Code for Units of Measure, Gunther Schadow Regenstrief Institute
+for Health Care and Indiana University School of Medicine Clement J. McDonald,
+Regenstrief Institute for Health Care and Indiana University School of Medicine
+Version: 1.6 (contains important corrections)
+Revision: $Revision: 1.2 $ Copyright C 1998-2005, Regenstrief Institute for
+Health Care.
+All rights reserved.
+http://aurora.regenstrief.org/UCUM/ucum.html#section-introduction
+
+****************************************************************
+
+From: Christoph Grein
+Date: Wednesday, November 18, 2010  7:24 AM
+
+I like this proposal. [He's referencing the proposal of October 30th - Editor.]
+I presume that the compiler will have to create some
+hidden discriminants (like my SI units package) for unit checking during compile
+time, but discriminants will not exist in the executable code.
+
+However I would not recommend using unit symbol names for constants like
+   m : constant Length := 1.0;
+because they are case sensitive and Ada is not. Apex is well known for
+automatically choosing capitalized style resulting in changing mS (Millisiemens)
+in Ms (Megaseconds).
+
+I would prefer
+
+   subtype Meter is MKS_Value;
+   pragma Dimension (Meter, ?meter => 1);  --  named association
+
+but we would then have to resolve the ambiguity with the literals of MKS_Names
+somehow (other names like e.g.
+
+   type MKS_Names is (Meter_Unit, Kilogram_Unit, ...);
+
+the latter would only be used in named associations of pragma Dimension, I
+presume).
+
+   pragma Dimension (Meter, Meter_Unit => 1);
+   pragma Dimension (Newton, Meter_Unit => 1, Kilogram_Unit => 1,
+                             Second_Unit => -2);
+
+This look promising (but of course too late for now).
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Thursday, November 19, 2010  9:52 AM
+
+> I like this proposal. I presume that the compiler will have to create some
+> hidden discriminants (like my SI units package) for unit checking during
+> compile time, but discriminants will not exist in the executable code.
+
+Actually the data structures are internal to the compiler, and discriminants
+are never mentioned, but the net result is a compile-time check on assignments
+and parameter passing that would be equivalent to discriminant checks (if those
+were performed statically).
+
+> However I would not recommend using unit symbol names for constants like
+>   m : constant Length := 1.0;
+> because they are case sensitive and Ada is not. Apex is well known for
+> automatically choosing capitalized style resulting in changing mS
+> (Millisiemens) in Ms (Megaseconds).
+
+I would like to use short names for the basic units in each system. Name clashes
+are the responsibility of the programmer, and there is always named notation to
+disambiguate multiple potentially use-visible entities.  Hopefully milliSiemens
+and Megaseconds are not declared in the same package, but for less frequently
+used names it seems acceptable to spell them  out in full.
+
+...
+> This look promising (but of course too late for now).
+
+There is no intent to make this part of the forthcoming Amendment to the
+language:  2 pragmas do not an AI make!   My proposal is to implement this in
+GNAT in the coming months, so that it is available for experimentation.
+Standardization can wait until it is polished by usage. Many thanks for your
+feedback!
+
+****************************************************************
+
+From: Christoph Grein
+Date: Thursday, November 19, 2010  11:43 PM
+
+> There is no intent to make this part of the forthcoming Amendment to
+> the language:
+
+Of course not, I did understand that.
+
+>2 pragmas do not an AI make!
+
+But there really is more in it than just two innocent-looking pragmas.
+
+> My proposal is
+> to implement this in GNAT in the coming months, so that it is
+> available for experimentation. Standardization can wait until it is
+> polished by usage. Many thanks for your feedback!
+
+Could you please post your proposal here in full as soon as it approaches a
+certain stage so that it can be "polished" early? I'm sure you will get lots of
+feedback. I could imagine that this is the way to go with physical units.
+
+****************************************************************
+
 From: Randy Brukardt
 Date: Wednesday, February 10, 2010  12:01 AM
 

Questions? Ask the ACAA Technical Agent