CVS difference for acs/ac-00184.txt

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

```--- acs/ac-00184.txt	2010/02/10 06:39:44	1.2
+++ acs/ac-00184.txt	2010/02/23 07:32:51	1.3
@@ -1008,7 +1008,7 @@
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
+Revision: \$Revision: 1.3 \$ Copyright C 1998-2005, Regenstrief Institute for
Health Care.
http://aurora.regenstrief.org/UCUM/ucum.html#section-introduction
@@ -1183,6 +1183,332 @@
clunky is the ugly aggregates to create values of the various types; perhaps a
little bit of syntactic sugar to make the aggregates read better would do the
trick?
+
+****************************************************************
+
+From: Christoph Grein
+Date: Wednesday, February 10, 2010  3:58 AM
+
+> > There is a famous paper (Grein, Kazakov, Wilson) about all issues
+> > with dimension computing in the proceedings of AE 2003 (Toulouse),
+> > LNCS 2655.
+...
+> The only thing that I see as clunky
+> is the ugly aggregates to create values of the various types; perhaps a
+> little bit of syntactic sugar to make the aggregates read better would do the
+> trick?
+
+If you look at the paper cited at the top, you can see that no ugly aggregates
+are needed if Ada is used cleverly. (I was the main author of that paper.)
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Wednesday, February 10, 2010  9:31 AM
+
+We now have a syntax to specify dimensions: it is just a new Aspect of a type:
+
+    type Meter is new ...
+    with Dimensions =>  (MSK, 1, 0, 0);
+
+and so on.  I think that seeing these dimensions as discriminants is
+bogus: they are certainly not going to be present at run-time, and all the
+dimensionality checking should be static. Dimensions are just properties of the
+type, that the compiler will use to verify consistency around arithmetic
+operations and assignments.  Dimensioned values remain scalar, and there is no
+issue of having to use aggregates to create them.
+
+****************************************************************
+
+From: Bob Duff
+Date: Wednesday, February 10, 2010  9:40 AM
+
+> ...Dimensions are just
+> properties of the type, ...
+
+Subtype, I think.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Wednesday, February 10, 2010  10:39 AM
+
+Indeed, thanks for the correction. We want each system of units to be
+single floating-point type.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, February 10, 2010  7:31 PM
+
+The syntax is reasonable, if you believe the assumption that all dimensions can be verified statically. I *know* that could never be true in Janus/Ada (it's an impossibility in a generic body), and Christoph had other examples where specifying the dimensi
ons statically would be hard/impossible.
+
+The advantage of using discriminants should be clear: they'll work on every Ada
+compiler (with overhead), and the optimizations to remove the overhead will help
+out lots of types that have nothing to do with dimensions. And of course it will
+work in generics without violating contracts and there is no doubt it will
+always be checked. So it seems to be a more general feature.
+
+Moreover, there is no need to invent new kinds of names to describe dimensions
+(the discriminant names will take care of that nicely), and really no need to
+invent anything. The trick is to hide the discriminants most of the time, and
+Christoph always has shown that can be done.
+
+It seems to me that Hiflinger's statement "Dimensions as types have no place in
+Ada because they are *definable* in Ada with no extra language features." is
+really true; the problem is that implementations have not optimized this use,
+and the Standard has not *highlighted* this use. (Both are necessary for a
+widely accepted solution.)
+
+Anyway, lots to discuss, but not now (as this is not on the agenda of the
+upcoming meeting).
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Wednesday, February 10, 2010  8:34 PM
+
+>>    type Meter is new ...
+>>    with Dimensions =>  (MSK, 1, 0, 0);
+
+As Bob noted, dimensions should be aspects of subtypes, not types. The whole
+point is that at the arithmetic level these are just floating point operations,
+and no operator declarations are ever needed.
+
+...
+> The syntax is reasonable, if you believe the assumption that all
+> dimensions can be verified statically. I *know* that could never be
+> true in Janus/Ada (it's an impossibility in a generic body), and
+> Christoph had other examples where specifying the dimensions
+> statically would be hard/impossible.
+
+I agree that shared generics would complicate this approach. I disagree that
+this ever has to be dynamic:  there are no engineering calculations that raise a
+dimensioned quantity to an unknown exponent:  it does not make  physical sense.
+Full dimensional analysis would require a complete set of declarations, with a
+few simple rules for literals,  arithmetic operations and elementary functions,
+but I am certain that a static system is all that is needed. This is why I find
+that the discriminant model, however attractive, is a distraction.   Dimensional
+checking is just a particular kind of type checking. And to handle incomplete
+specifications of dimensions, there surely is pragma Suppress (Dimension_Check)!
+
+> Moreover, there is no need to invent new kinds of names to describe
+> dimensions (the discriminant names will take care of that nicely), and
+> really no need to invent anything. The trick is to hide the
+> discriminants most of the time, and Christoph always has shown that
+> can be done.
+
+Well, if you want decent I/O and meaningful conversions (look at Christoph's
+full package) the names of discriminants are certainly not going to be
+sufficient. You would need at least a different set of names for each system of
+units.
+
+> It seems to me that Hiflinger's statement "Dimensions as types have no
+> place in Ada because they are
+> *definable* in Ada with no extra language features." is really true;
+> the problem is that implementations have not optimized this use, and
+> the Standard has not *highlighted* this use. (Both are necessary for a
+> widely accepted solution.)
+
+in the meantime, there is room for compilers to experiment with other
+approaches, possibly easier to implement. As soon as Ada 2012 is solidly
+defined....
+
+> Anyway, lots to discuss, but not now (as this is not on the agenda of
+> the upcoming meeting).
+
+Indeed, but still a fun topic!
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, February 11, 2010  12:54 PM
+
+...
+> > The syntax is reasonable, if you believe the assumption that all
+> > dimensions can be verified statically. I *know* that could never be
+> > true in Janus/Ada (it's an impossibility in a generic body), and
+> > Christoph had other examples where specifying the dimensions
+> > statically would be hard/impossible.
+>
+> I agree that shared generics would complicate this approach.
+
+It's not shared generics per-se, it's the Ada contract model. The approach that
+I think you are suggesting essentially abandons that to look inside of generic
+bodies. We've *never* done that in the past (and there surely have been times it
+was tempting); changing that would be a major switch in philosophy and if we're
+willing to do that there are much more general changes that ought to be made to
+the language (that would allow something like Boost to be directly written in
+Ada, eliminating the need for this change). Something to think about, at least.
+
+> I disagree that this ever has to be dynamic:  there are no engineering
+> calculations that raise a dimensioned quantity to an unknown exponent:
+> it does not make  physical sense.  Full dimensional analysis would
+> require a complete set of declarations, with a few simple rules for
+> literals,  arithmetic operations and elementary functions, but I am
+> certain that a static system is all that is needed.
+
+If you are willing to abandon the contract model, don't ever plan to read in
+dimensions, etc. Probably fine for an extension outside of the language, much
+more dubious for an addition to the language.
+
+> This is why I find
+> that the discriminant model, however attractive, is a distraction.
+> Dimensional checking is just a particular kind of type checking. And
+> to handle incomplete specifications of dimensions, there surely is
+> pragma Suppress (Dimension_Check) !
+
+Pragma Suppress only has an effect on runtime checks; it surely has no effect on
+Legality Rules (which is what these would be -- unless you are proposing a new
+class of compile-time checks??). And pragma Suppress always can be ignored,
+you're proposing to change that??
+
+> > Moreover, there is no need to invent new kinds of names to describe
+> > dimensions (the discriminant names will take care of that nicely),
+> > and really no need to invent anything. The trick is to hide the
+> > discriminants most of the time, and Christoph always has shown that
+> > can be done.
+>
+> Well, if you want decent I/O and meaningful conversions (look at
+> Christoph's full package) the names of discriminants are certainly not
+> going to be sufficient. You would need at least a different set of
+> names for each system of units.
+
+Yes, but those names are of the various subtypes:
+
+subtype MPH is Units (Distance => Miles, Time => Hours);
+
+(assuming suitable constants).
+
+> > It seems to me that Hiflinger's statement "Dimensions as types have
+> > no place in Ada because they are
+> > *definable* in Ada with no extra language features." is really true;
+> > the problem is that implementations have not optimized this use, and
+> > the Standard has not *highlighted* this use. (Both are necessary for
+> > a widely accepted solution.)
+>
+> in the meantime, there is room for compilers to experiment with other
+> approaches, possibly easier to implement. As soon as Ada 2012 is
+> solidly defined....
+
+Surely. I just don't see this working as part of the language because it seems
+to be ignoring the basic tenets of the language (contract model in particular).
+And that seems absolutely necessary to make this work.
+
+The main problem that I see with the Units stuff is that there is insufficient
+be able to do it even better, as the pre/post conditions will allow moving the
+checks to the call site, where they can be eliminated/failure detected at
+compile time). Putting a package like Christoph's into the Standard would
+probably be enough to encourage people to "improve" it for their own purposes
+(especially if it came with a pragma that told the compiler that omitting the
+discriminants from objects was encouraged). Fancier approaches seem to just add
+complexity without much additional power, and the effort is better put toward
+optimizing the building blocks we already have.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Thursday, February 11, 2010  5:58 AM
+
+> It's not shared generics per-se, it's the Ada contract model. The
+> approach that I think you are suggesting essentially abandons that to
+> look inside of generic bodies. We've *never* done that in the past
+> (and there surely have been times it was tempting); changing that
+> would be a major switch in philosophy and if we're willing to do that
+> there are much more general changes that ought to be made to the
+> language (that would allow something like Boost to be directly written
+> in Ada, eliminating the need for this change). Something to think
+
+I'm not proposing to abandon the contract model at all. Obviously you can
+specify the dimensions of formal types if you want to. More importantly you can
+use the system of units (some enumeration type defined in some package
+Dimensions) as a generic parameter, so you can specify that two other parameters
+(say a length and a time) belong to the same system of units, and consistency is
+verified at instantiation time.  Not sure how you would achieve this with
+discriminants (no to mention defining formal types with half-a-dozen of those).
+
+The open question is how to handle a generic package where formals have no
+dimension aspect specified, but the actuals do.  I would say that in such cases
+the implicit specification for the formals is "any", and no checks are
+necessary. apart from that. the usual rules would apply that in the instance the
+properties of the formal are those of the actual, ditto for dimensions.
+
+For example, it's easy enough to have an instantiation for Kilometer_IO,  but if
+I use Float_IO directly to read a kilometer value that should work.  I don't see
+how discriminants would help you here, since most certainly you won't put them
+on the file.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, February 11, 2010  6:23 PM
+
+> The open question is how to handle a generic package where formals
+> have no dimension aspect specified, but the actuals do.  I would say
+> that in such cases the implicit specification for the formals is
+> "any", and no checks are necessary. apart from that. the usual rules
+> would apply that in the instance the properties of the formal are
+> those of the actual, ditto for dimensions.
+>
+> For example, it's easy enough to have an instantiation for
+> Kilometer_IO,  but if I use Float_IO directly to read a kilometer
+> value that should work.  I don't see how discriminants would help you
+> here, since most certainly you won't put them on the file.
+
+OK, I guess, but that seems to make a big possible hole. It would be quite
+possible for an existing generic to do dimensional coding. That would be
+unchecked, and could cause big problems. Not sure if people really care or not,
+though.
+
+The problem would be most acute with existing generics that were repurposed.
+Imagine:
+
+    generic
+        type Flt is digits <>;
+        type Time is delta <>;
+        function Get_Velocity (Distance : Flt; Seconds : Time) return Flt;
+        ...
+
+The parameter Distance and result of Get_Velocity have different dimensions, but
+this generic does not expose that. Either you force total rewriting of the
+generic, or you have a bad hole where the dimensions are lost (and unchecked)
+within the generic. (This particular example isn't very realistic, but it is the
+sort of thing that could happen in more complex cases.)
+
+Maybe a better example would be a user that wanted to instantiate
+Ada.Numerics.Generic_Real_Arrays with a dimensioned type. Simply rejecting
+instantiations with conflicts would make that impossible. And how would the
+compiler figure out the proper dimensionality for
+    function "*" (Left : Real'Base; Right : Real_Vector) return Real_Vector;
+
+This would be a way to calculate a velocity vector; I would think it would be
+annoying for that not to work.
+
+Anyway, more food for thought.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Saturday, February 13, 2010  3:30 AM
+
+> So it seems that only a bit of "help" is needed to make a viable
+> solution out of this.
+
+I am not sure about "bit".
+
+The problem is that the discriminants needs to be folded when you use
+dimensioned types as build blocks of other types. E.g/:
+
+   type Vector (...) is array (...) of Quant;
+   function "+" (Left, Right : Vector) return Vector;
+
+You have to move the discrimnants of Quant to Vector. You have to bring them
+back when elements are extracted as Quants. You have to allow an efficient
+implementation of "+" in terms of Floats.

****************************************************************

```

Questions? Ask the ACAA Technical Agent