Re: Announce: Grace project site operational

Re: Announce: Grace project site operational

[Grein, Christoph]

From: "Martin Dowie" <martin.dowie@nospam.baesystems.com>
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:3CE15D0A.3050100@mail.com...
> [snip]
> > I first saw this idiom in _Scientific and Engineering C++_
> > by Bartion & Nackman.
> >
> > template<typename RepType, int Mass, int Distance, int Time>
> > struct Unit
> > {
> > RepType value;
> > explicit Unit(value) : value(value) { }
> > Unit operator+(Unit other)
> > { return Unit(value + other.value); }
> > Unit operator-(Unit other)
> > { return Unit(value - other.value); }
> > };
> [snip]
> 
> Didn't someone post an Ada units package similar to
> this a while back (> 1 year)?..

This is a theme that at least once a year re-appears. There is somewhere in 
Dabid Botton's AdaPower a paper by me about these physical types with a 
reference to a more detailed paper how my company handles this in several 
ebedded real-time avionics projects.

All "solutions" to this problem I've seen so far can be split into three 
methods:

1. Use subtypes with proper names like Meter, Kilogramm, Ohm just for
   documentation, i.e. no type checking.
2. Use strong types with separate types and operator overloading.
   This only works (except for broken exponents like 1/2 as in sqrt (Meter);
   yes, these occur quite often with rational values 1/2, 1/3, 3/2, 4/3 just
   to name some) for limited subsets of SI units (two or three).
3. Discrimiated types with dimensions carried as discriminants.
   This is the most general method which, if rational (not integer)
   arithmetic is applied to exponents, but is run-time intensive, so possibly
   not applicable to real-time.

There is a fourth method, preprocessors.
And a fifth, if you create a language that can handle dimensions.

My feeling is that method 1 should be the preferred one. two is out (expontial 
explosion of number of operations, rational exponents cannot be handled), 3 if 
execution time does not matter.

In theoretical phycial work, dimensionless forms of the equations are preferred 
after all.

Re: Announce: Grace project site operational

[Ted Dennison]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message news:<mailman.1021456922.26837.comp.lang.ada@ada.eu.org>...
> All "solutions" to this problem I've seen so far can be split into three 
> methods:
> 
> 1. Use subtypes with proper names like Meter, Kilogramm, Ohm just for
>    documentation, i.e. no type checking.
...
> My feeling is that method 1 should be the preferred one. two is out (expontial 
> explosion of number of operations, rational exponents cannot be handled), 3 if 
> execution time does not matter.

That's the way everyone I've ever seen tackle the problem end up
going. Yo do get range checking, so you aren't entirely check-free.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Grein, Christoph]

From: "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de>
> Consider:
> 
>    type Graph_Node is private;
>    No_Node : constant Graph_Node; -- Deferred, but visible
>    function Get_Next_Child
>       (Parent : Graph_Node; Child : Graph_Node := No_Node)
>          return Graph_Node;
> 
> Here I exposed No_Node, which then can be abused like:
> 
>    Get_Next_Child (No_Node);
> 
> A solution could be some sort of incomplete declaration for
> subprograms:
> 
>    type Graph_Node is private;
>    function Get_Next_Child
>       (Parent : Graph_Node; Child : Graph_Node := <>)
>          return Graph_Node;

Your caller has to have some variable Current_Parent, which might have the value 
No_Node, e.g. when it is undefined (private types should be defaulted to 
something like this so that they always have a value even when never assigned a 
value).
So you must make sure in any case that the actual for Parent is different from 
No_Node, so the abusive

  Get_Next_Child (No_Node);

is caught in any case.

There are cases where

         .---------------------------------------.
         | Information Hiding Considered Harmful |
         `---------------------------------------'


> 
> private
>    type Graph_Node is ...;
>    No_Node : constant Graph_Node := ...;
>    function Get_Next_Child
>       (Parent : Graph_Node; Child : Graph_Node := No_Node)
>          return Graph_Node;
> 
> ---
> Regards,
> Dmitry Kazakov
> www.dmitry-kazakov.de
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Wed, 15 May 2002 13:32:48 +0200 (MET DST), "Grein, Christoph"
<christoph.grein@eurocopter.com> wrote:

>From: "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de>
>> Consider:
>> 
>>    type Graph_Node is private;
>>    No_Node : constant Graph_Node; -- Deferred, but visible
>>    function Get_Next_Child
>>       (Parent : Graph_Node; Child : Graph_Node := No_Node)
>>          return Graph_Node;
>> 
>> Here I exposed No_Node, which then can be abused like:
>> 
>>    Get_Next_Child (No_Node);
>> 
>> A solution could be some sort of incomplete declaration for
>> subprograms:
>> 
>>    type Graph_Node is private;
>>    function Get_Next_Child
>>       (Parent : Graph_Node; Child : Graph_Node := <>)
>>          return Graph_Node;
>
>Your caller has to have some variable Current_Parent, which might have the value 
>No_Node, e.g. when it is undefined (private types should be defaulted to 
>something like this so that they always have a value even when never assigned a 
>value).

Fortunately, with Ada 95 we have a way to ensure that all variables
get initialized:

type Graph_Node (<>) is private; -- Prevents uninitialized variables

>So you must make sure in any case that the actual for Parent is different from 
>No_Node, so the abusive
>
>  Get_Next_Child (No_Node);
>
>is caught in any case.

That's for sure, because Graph_Node will probably be a record
containing an access type, dereferenced and thus checked at run-time.
But this is no matter, because no run-time checks may supersede
compile-time ones.

Another story is that with a more advanced ADT there might be a way to
easily create a supertype Graph_Node_With_No_Node and then leave the
work to the compiler. But this is a long way to go.

>There are cases where
>
>         .---------------------------------------.
>         | Information Hiding Considered Harmful |
>         `---------------------------------------'

Egh, where am I? Is this comp.lang.ada? (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Announce: Grace project site operational

[Ted Dennison]

I'm pleased to announce that the Grace project is now operational. The 
homepage is at http://www.freesoftware.fsf.org/Grace/Grace_Home.html , 
and the main project page on the Gnu Savannah is at 
http://savannah.gnu.org/projects/grace/ .

Currently, the only thing in the CVS tree is the first version of our 
Unbounded Lists package, and a reference implementation of it. I have 
set up a project for a Maps package, but the tasks are currently 
unassigned. Anyone who wants to help is encouraged to participate in the 
mailing lists, get a Savannah account and become a developer, or just 
hang out here and participate in the discussions.

I'd like to say more, but that roughly covers it, and I have a crying 
baby to attend to. :-) If anyone wants to know anything more, reply here 
or on one of the mailing lists.

Re: Announce: Grace project site operational

[Larry Kilgallen]

In article <3CD88FBD.4070706@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
> I'm pleased to announce that the Grace project is now operational. The 
> homepage is at http://www.freesoftware.fsf.org/Grace/Grace_Home.html , 
> and the main project page on the Gnu Savannah is at 
> http://savannah.gnu.org/projects/grace/ .
> 
> Currently, the only thing in the CVS tree is the first version of our 
> Unbounded Lists package, and a reference implementation of it. I have 
> set up a project for a Maps package, but the tasks are currently 
> unassigned. Anyone who wants to help is encouraged to participate in the 
> mailing lists, get a Savannah account and become a developer, or just 
> hang out here and participate in the discussions.
> 
> I'd like to say more, but that roughly covers it, and I have a crying 
> baby to attend to. :-) If anyone wants to know anything more, reply here 
> or on one of the mailing lists.

Well, in article <3CD85124.8070005@mail.com>, Hyman Rosen <hyrosen@mail.com> wrote:

> Which makes me think - in the recent specifications for containers
> that were posted here, do the generics have a parameter for the
> type used to count the members of the container? Otherwise when I
> ask my LinkedListOfApples and my LinkedListOfCartPushers how many
> things each contains I'll have to convert the result, and then I
> could make the same mistake that a C++ programmer would.

Re: Announce: Grace project site operational

[Ted Dennison]

Larry Kilgallen wrote:

> Well, in article <3CD85124.8070005@mail.com>, Hyman Rosen <hyrosen@mail.com> wrote:
> 
>>Which makes me think - in the recent specifications for containers
>>that were posted here, do the generics have a parameter for the
>>type used to count the members of the container? Otherwise when I
>>ask my LinkedListOfApples and my LinkedListOfCartPushers how many
>>things each contains I'll have to convert the result, and then I
>>could make the same mistake that a C++ programmer would.


I'm not sure I understand either the question or the suppossed problem. 
The only way you could possibly get different types back for a size 
operation would be if there *were* such a generic parameter.

Re: Announce: Grace project site operational

[Marin David Condic]

Not everything needs to have its own type. This is (IMHO) a typical
"beginner" mistake - someone gets sold on the notion of "strong typing" (A
Good Thing)then goes to the extreme of having a unique type for everything
(A Bad Thing) - which just makes life very confusing and difficult. There is
such a thing as "Overkill".

Subtypes are often a good alternative when you're dealing with things that
have some known constraint, but even there I don't think its necessary for
every counter or index in a program to be of its own unique subtype. I don't
see anything wrong with a generic package for containing unknown objects to
return a count of whatever its holding as a type Natural and leave it to the
user to convert it to some other type if they really think they need to. You
know the number should never be negative and Natural'Last is probably big
enough for any collection of stuff in memory. Given the likely uses of a
"Length" function, I doubt it would cause much trouble.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CD91E31.1060004@telepath.com...
>
>
> I'm not sure I understand either the question or the suppossed problem.
> The only way you could possibly get different types back for a size
> operation would be if there *were* such a generic parameter.
>
>
>

Re: Announce: Grace project site operational

[Randy Brukardt]

Marin David Condic wrote in message ...
>You know the number should never be negative and Natural'Last is
probably big
>enough for any collection of stuff in memory.

Not necessarily. I know at least one Ada compiler that has type Integer
as 16-bits on all targets (so all targets have the same memory layout).

If you care about the range, always use a user-defined type. Certainly
in this case, you'll need a type with a longer range than 32767.

            Randy.

Re: Announce: Grace project site operational

[Marin David Condic]

IIRC, there was XD-Ada targeted to the Mil-Std-1750a and its Integer was 16
bits. This was Ada83 and, on that hardware, it didn't make much sense to do
anything else anyway. Of course, this was an embedded application where
dynamic allocation was undesirable and the hardware only had 64k words of
memory anyway, so you probably wouldn't have cared much if the count
returned was only 16 bits.

However, I see your point. The Lists package could conceivably define its
own List_Element_Count type (with the customary Ada style "implementation
defined" we see in lots of the Ada packages now. :-) to guarantee it had
sufficient size for most uses. That might make more sense than adding
another generic parameter and would be in keeping with the style of lots of
other standard Ada packages.

Of course, arguably, if a given implementation is only supporting 16 bit
integers, it is likely to be for a machine (like the 1750a) that may not
easily handle larger sizes and may not have the large memory needed to
support lists that would exceed the 32767 elements it could count anyway.
Its likely that you'd be working with a machine that had other practical
limits (like strings that can't get larger than 32767 characters because
they're indexed by Integers as well?) so would you really care? Its just
another implementation limit you have to work with - or modify the source
since you have it readily available.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:udlkuuac05v2c2@corp.supernews.com...
>
> Not necessarily. I know at least one Ada compiler that has type Integer
> as 16-bits on all targets (so all targets have the same memory layout).
>
> If you care about the range, always use a user-defined type. Certainly
> in this case, you'll need a type with a longer range than 32767.
>

Re: Announce: Grace project site operational

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<abelpc$p6i$1@nh.pace.co.uk>...
> IIRC, there was XD-Ada targeted to the Mil-Std-1750a and its Integer was 16
> bits. This was Ada83 and, on that hardware, it didn't make much sense to do
> anything else anyway. Of course, this was an embedded application where
...
> Of course, arguably, if a given implementation is only supporting 16 bit
> integers, it is likely to be for a machine (like the 1750a) that may not
> easily handle larger sizes and may not have the large memory needed to
> support lists that would exceed the 32767 elements it could count anyway.

That would be my argument as well. :-)

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Announce: Grace project site operational

[Randy Brukardt]

Marin David Condic wrote in message ...
>Of course, arguably, if a given implementation is only supporting 16
bit
>integers, it is likely to be for a machine (like the 1750a) that may
not
>easily handle larger sizes and may not have the large memory needed to
>support lists that would exceed the 32767 elements it could count
anyway.
>Its likely that you'd be working with a machine that had other
practical
>limits (like strings that can't get larger than 32767 characters
because
>they're indexed by Integers as well?) so would you really care? Its
just
>another implementation limit you have to work with - or modify the
source
>since you have it readily available.

The implementation in question supports 32-bit integers on all targets,
but "Integer" is 16-bits ("Long_Integer" is 32-bits). On some targets,
32-bit operations are more expensive; on 32-bit targets like the
Pentium, that's not even true, but "Integer" is 16-bits for
interoperability with the older targets.

Don't use Integer if you (may) need a range beyond 32767. (Which, BTW,
is a significant complaint of mine about the design of the standard
string libraries, but enough of that...)

            Randy.

Re: Announce: Grace project site operational

[Larry Hazel]

Marin David Condic wrote:
> 
> Not everything needs to have its own type. This is (IMHO) a typical
> "beginner" mistake - someone gets sold on the notion of "strong typing" (A
> Good Thing)then goes to the extreme of having a unique type for everything
> (A Bad Thing) - which just makes life very confusing and difficult. There is
> such a thing as "Overkill".
> 
I remember starting in the middle of an Ada 83 project.  There was a separate
type defined for everything.  An old Elvis song kept going through my head.  But
instead of "girl happy", I was substituting "type happy".

Larry

Re: Announce: Grace project site operational

[David C. Hoos]

----- Original Message -----
From: "Larry Hazel" <lhhazel@otelco.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Friday, May 10, 2002 9:17 AM
Subject: Re: Announce: Grace project site operational
<snip>
> I remember starting in the middle of an Ada 83 project.  There was a
separate
> type defined for everything.  An old Elvis song kept going through my
head.  But
> instead of "girl happy", I was substituting "type happy".

I'll bet I know what project that was!

Re: Announce: Grace project site operational

[Marin David Condic]

"Larry Hazel" <lhhazel@otelco.net> wrote in message
news:3CDBD673.FF452A3D@otelco.net...
> >
> I remember starting in the middle of an Ada 83 project.  There was a
separate
> type defined for everything.  An old Elvis song kept going through my
head.  But
> instead of "girl happy", I was substituting "type happy".
>
Been there. Done that. Got the t-shirt. The problem is coming up with a
guideline or some other sort of rule of thumb that offers constructive
advice (especially to the beginner) as to when creating more types isn't
really helpful. It really is a kind of an "art".

Example: There are times when one might want to have unique types for Volts
and Amps and Ohms (reading from different sensors) and there are times when
this would only be extremely painful (when calculating typical electrical
relationships) and what exactly would the type conversions mean anyway? If I
say "Amps := Amps_Type (Volts) / Amps_Type (Ohms) ;" am I really converting
volts to amps and ohms to amps as it appears? Not exactly as it reads. So
there can be an awful large amount of gray area in deciding when to create
types and when doing so is going to just make things worse. But I can
usually spot "worse" when I see it. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Announce: Grace project site operational

[Preben Randhol]

On Fri, 10 May 2002 11:38:14 -0400, Marin David Condic wrote:
> Example: There are times when one might want to have unique types for
> Volts and Amps and Ohms (reading from different sensors) and there are
> times when this would only be extremely painful (when calculating
> typical electrical relationships) and what exactly would the type
> conversions mean anyway? If I say "Amps := Amps_Type (Volts) /
> Amps_Type (Ohms) ;" am I really converting volts to amps and ohms to
> amps as it appears? Not exactly as it reads. So there can be an awful
> large amount of gray area in deciding when to create types and when
> doing so is going to just make things worse. But I can usually spot
> "worse" when I see it. :-)

I agree. 

Say you instead defined them as subtypes of Float (for this example)
with allowed ranges for each type, would that be an enhancement over
only using Float? 

I'm asking because I can see that you run the risk of getting some
constraint errors you have to deal with in your program, but on the
other hand the program will tell you when your calcultaions gives very
wrong results which may indicate errors in your code.

Preben
-- 
�.., chaos is found in greatest abundance wherever order is being
sought. It always defeats order, because it is better organized.�
                            -- Interesting Times, Terry Pratchett

Re: Announce: Grace project site operational

[martin.m.dowie]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnadq9vg.21p.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Fri, 10 May 2002 11:38:14 -0400, Marin David Condic wrote:
> > Example: There are times when one might want to have unique types for
> > Volts and Amps and Ohms (reading from different sensors) and there are
> > times when this would only be extremely painful (when calculating
> > typical electrical relationships) and what exactly would the type
> > conversions mean anyway? If I say "Amps := Amps_Type (Volts) /
> > Amps_Type (Ohms) ;" am I really converting volts to amps and ohms to
> > amps as it appears? Not exactly as it reads. So there can be an awful
> > large amount of gray area in deciding when to create types and when
> > doing so is going to just make things worse. But I can usually spot
> > "worse" when I see it. :-)
>
> I agree.
>
[snip]

In these sorts of cases I would use an 'SI_Units' package (like the
"Whitaker"
one) that provided all the nice conversion for me...

e.g. function "/" (V : Volts; O : Ohms) return Amps;

etc

I find this _very_ convenient and highly reusable.

Anyone for a 'Grace.SI_Units' package?..

Re: Announce: Grace project site operational

[William C. Brennan]

On Sat, 11 May 2002 12:58:55 -0400, martin.m.dowie wrote
(in message <t5cD8.853$vb.80665@news8-gui.server.ntli.net>):

> I find this _very_ convenient and highly reusable.
> 
> Anyone for a 'Grace.SI_Units' package?..

Count me in this camp too.  I usually end up creating some units
packages, for whatever project I'm one, that does these sorts of
conversions.  (Sadly, I don't get to work in Ada professionally 
very much anymore.)

This is just the sort of _wonderful_ use of good typing (IMHO) that makes
programs _readable_ and trustworthy.  I love Ada because it lets me do
this, and makes my intentions absolutely clear.  (Am I too effusive?)

Yes, it is more trouble to write this way, establishing the appropriate
type conversions in utilities.  But isn't this why we use Ada - 
weighted in favor of the reader as opposed to the writer?

   -- Bill

-- 
Bill Brennan
brennan@netaxs.com

Re: Announce: Grace project site operational

[Preben Randhol]

On Sat, 11 May 2002 17:58:55 +0100, martin.m.dowie wrote:
> 
> In these sorts of cases I would use an 'SI_Units' package (like the
> "Whitaker"
> one) that provided all the nice conversion for me...

Do you have a link? Is it free (speech) code?

> Anyone for a 'Grace.SI_Units' package?..

Absolutely.

Preben

Re: Announce: Grace project site operational

[martin.m.dowie]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnadqulp.74i.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Sat, 11 May 2002 17:58:55 +0100, martin.m.dowie wrote:
> >
> > In these sorts of cases I would use an 'SI_Units' package (like the
> > "Whitaker"
> > one) that provided all the nice conversion for me...
>
> Do you have a link? Is it free (speech) code?

No idea (I think I have a copy of the original packages at work - I'll try
and
dig them out Monday). You can *buy*(!) a copy from the IEEE
(www.ieee.org and search for "ABBET LOG 1000").

We used one that was 'like' the whitaker one (I used Whitaker as a reference
as I thought many people would be familiar with it - almost no one here
would
be familiar with anything I've written! ;-)

Re: Announce: Grace project site operational

[Marin David Condic]

I'd love to see Grace include all sorts of useful mathematical, scientific
and engineering packages. (I have some useful business calculations that I
keep around for reuse because the formulas aren't hard to build and why not?
Its an easy extension to the language.) Wouldn't Ada be much more
interesting if it had a whole bunch of common formulaic things around that
would appeal to a variety of fields? It isn't hard to dream them up.
Statistics, Linear-A, Operations Research, Electrical Engineering, Physics,
Chemistry, Rocket Science, etc. etc. etc.

Maybe if we came up with a package spec that defined a style for
implementing math libraries for problem domains, we could get a bunch of
them built rather readily - seeing as how there are lots of Ada enthusiasts
who have special domain knowledge & might be willing to contribute?

Or is there no consensus that Grace should include things beyond containers?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:t5cD8.853$vb.80665@news8-gui.server.ntli.net...
>
> In these sorts of cases I would use an 'SI_Units' package (like the
> "Whitaker"
> one) that provided all the nice conversion for me...
>
> e.g. function "/" (V : Volts; O : Ohms) return Amps;
>
> etc
>
> I find this _very_ convenient and highly reusable.
>
> Anyone for a 'Grace.SI_Units' package?..
>
>
>

Re: Announce: Grace project site operational

[Marin David Condic]

Hard to say. Depends somewhat on the app. I might create a whole separate
floating point type for electrical calculations where I intend to mix volts
and amps and ohms. That would keep it separate from whatever other
calculations might be going on. In this case, I don't know that ranges would
figure into it - conceptually at least the calculations can go to +/-
infinity, so any subtype with a range constraint might be strictly for
hardware concerns. Unless, of course, you're getting the values from some
real world source with real world limitations.

My point is that you have to give some careful thought to creating types and
that doing it for every identifiable unique item is not usually smart.
Decisions should be made with some sensitivity as to what the types
represent and how much mixing together of the different types is needed. I'd
love to see some textbook on computer philosophy that attempted to describe
how to make those decisions, but I've not run into any.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnadq9vg.21p.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> Say you instead defined them as subtypes of Float (for this example)
> with allowed ranges for each type, would that be an enhancement over
> only using Float?
>

Re: Announce: Grace project site operational

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<abodqj$3qh$1@nh.pace.co.uk>...
> My point is that you have to give some careful thought to creating types and
> that doing it for every identifiable unique item is not usually smart.
> Decisions should be made with some sensitivity as to what the types
> represent and how much mixing together of the different types is needed. I'd

That's the biggie. If you try to make separate types for velocities
and accelerations, you will suddenly find that you also need separate
types for times and distances, and perhaps even Hz and mass and forces
and rotational orientations and velocitites and accelerations. Then
you'll find how annoying it is to have to do type conversions on every
factor in every formula. A more attractive option may be to write your
own math operators that return the correct type given their two input
types. But that causes an exponential growth in operators that you
have to create every time you add a new unit.

To do this kind of thing *right*, you'd really need a language that
relies on structural equivalence for types, and automaticly generates
the proper new type given the operator and the types of its operands.
In Ada, you just can't do that.

Generally, what I see Ada folk do is use *subtypes* for all this
stuff. That way ranges are checked, but formulas don't become a chore
(although you still have to be really careful with intermediate values
blowing out of subtype constraints).

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Marin David Condic]

Think about why it is that Ada provides separate types with strong rules
about separate-but-equal treatment of them. Its about keeping things
separate that belong separate. So you need to ask the question "Should these
things (almost) never be mixed or confused with each other?" In my
produce-inventory-program I (almost) never have a good reason to mix up a
count of apples with a count of oranges - hence the archetypical example.

But if you're doing computations with velocities and accelerations and such,
then you thoroughly intend to mix them and you are then saying "I'm dealing
with general mathematical relationships between one thing and another" That
sort of calls for a common type of sufficient size to support the
anticipated calculations. After all, the common object of interest here is
the "mathematical relationship", not the not the particular items in some
specific engineering units.

I agree that a good compromise is to have subtypes that can then be freely
mixed with possible constraints as needed. This provides you with some
ability to distinguish in your code where you are dealing with one thing
versus another (velocities versus accelerations) and have the values sanity
checked by your constraints, while leaving you the ability to freely mix the
math operations. Of course, this doesn't save you from everything - e.g.
passing a velocity to a function that needs an acceleration - but you just
can't always have absolute safety. Absolute safety is for people who don't
have the balls to live in the real world. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205140718.3ddb1b2a@posting.google.com...
>
> That's the biggie. If you try to make separate types for velocities
> and accelerations, you will suddenly find that you also need separate
> types for times and distances, and perhaps even Hz and mass and forces
> and rotational orientations and velocitites and accelerations. Then
> you'll find how annoying it is to have to do type conversions on every
> factor in every formula. A more attractive option may be to write your
> own math operators that return the correct type given their two input
> types. But that causes an exponential growth in operators that you
> have to create every time you add a new unit.
>
> To do this kind of thing *right*, you'd really need a language that
> relies on structural equivalence for types, and automaticly generates
> the proper new type given the operator and the types of its operands.
> In Ada, you just can't do that.
>
> Generally, what I see Ada folk do is use *subtypes* for all this
> stuff. That way ranges are checked, but formulas don't become a chore
> (although you still have to be really careful with intermediate values
> blowing out of subtype constraints).
>
> --
> T.E.D.
> Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Hyman Rosen]

Marin David Condic wrote:
> Of course, this doesn't save you from everything - e.g. passing a
 > velocity to a function that needs an acceleration - but you just
> can't always have absolute safety.

Except that, since the C++ solution does offer such absolute safety,
with zero runtime overhead in speed or space, we are merely seeing
a deficiency in Ada.

Re: Announce: Grace project site operational

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Think about why it is that Ada provides separate types with strong rules
> about separate-but-equal treatment of them. Its about keeping things
> separate that belong separate. So you need to ask the question "Should these
> things (almost) never be mixed or confused with each other?" In my
> produce-inventory-program I (almost) never have a good reason to mix up a
> count of apples with a count of oranges - hence the archetypical example.

True.

> But if you're doing computations with velocities and accelerations
> and such, then you thoroughly intend to mix them and you are then
> saying "I'm dealing with general mathematical relationships between
> one thing and another" That sort of calls for a common type of
> sufficient size to support the anticipated calculations. After all,
> the common object of interest here is the "mathematical
> relationship", not the not the particular items in some specific
> engineering units.

Not quite true. For me, the point of having Ada "do units right" is to
catch errors. For example, Newton's second law is F = m a. F is in
kg-m/s^2, m is in kg, a is in m/s^2. If I accidently code this as:

Force := Mass / Acceleration;

I'd like the compiler to say "hey, you got the units wrong".

> I agree that a good compromise is to have subtypes that can then be
> freely mixed with possible constraints as needed. This provides you
> with some ability to distinguish in your code where you are dealing
> with one thing versus another (velocities versus accelerations) and
> have the values sanity checked by your constraints, while leaving
> you the ability to freely mix the math operations. 

For me, subtypes are like comments; they can help, but they can also
mislead. In physical systems, it is often more of a nuisance to have
constraints.

> Of course, this doesn't save you from everything - e.g. passing a
> velocity to a function that needs an acceleration - but you just
> can't always have absolute safety. 

An automatically generated Ada package with _all_ the necessary types
would give you full unit checking. So do the C++ templates.

> Absolute safety is for people who don't have the balls to live in
> the real world. :-)

I agree with this principle in general, but in this case it doesn't
apply :).

-- 
-- Stephe

Re: Announce: Grace project site operational

[Martin Dowie]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205140718.3ddb1b2a@posting.google.com...
> That's the biggie. If you try to make separate types for velocities
> and accelerations, you will suddenly find that you also need separate
> types for times and distances, and perhaps even Hz and mass and forces
> and rotational orientations and velocitites and accelerations. Then
> you'll find how annoying it is to have to do type conversions on every
> factor in every formula. A more attractive option may be to write your
> own math operators that return the correct type given their two input
> types. But that causes an exponential growth in operators that you
> have to create every time you add a new unit.
>
> To do this kind of thing *right*, you'd really need a language that
> relies on structural equivalence for types, and automaticly generates
> the proper new type given the operator and the types of its operands.
> In Ada, you just can't do that.
>
> Generally, what I see Ada folk do is use *subtypes* for all this
> stuff. That way ranges are checked, but formulas don't become a chore
> (although you still have to be really careful with intermediate values
> blowing out of subtype constraints).

Can't say I've ever seen these as subtypes and I'm not sure
I like the idea...

The ability to not add volts and metres together is one of
things I like about Ada!

In the same vein as the standard Ada maths library doesn't try to
cover _all_ possible maths packages, an 'elementary SI' package should
be possible (I feel) to cover 99% of project needs (e.g. SI units and
support for powers to the +/- 3 plus a base 'dimensionless' unit).

I have no evidence to support this supposition other than my own experience
that the above would cover every project I've ever work on (and that's
including some heavy duty 3-d geometry type projects).

It might be big, it might not be pretty, but once its there it's not
exactly going to be changing! :-)

Re: Announce: Grace project site operational

[Ted Dennison]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message news:<3ce1424a$1@pull.gecm.com>...
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0205140718.3ddb1b2a@posting.google.com...
> > To do this kind of thing *right*, you'd really need a language that
> > relies on structural equivalence for types, and automaticly generates
> > the proper new type given the operator and the types of its operands.
> > In Ada, you just can't do that.
...
> In the same vein as the standard Ada maths library doesn't try to
> cover _all_ possible maths packages, an 'elementary SI' package should
> be possible (I feel) to cover 99% of project needs (e.g. SI units and
> support for powers to the +/- 3 plus a base 'dimensionless' unit).
...
> It might be big, it might not be pretty, but once its there it's not
> exactly going to be changing! :-)

I'm certianly not an engineering math expert, but I've watched enough
of them try to go this route and fail that I'm skeptical. The big
problem was always the geometric explosion of operators required for
every new unit added. Its no biggie when you just have positions and
velocities, but at ((n-1)n * p)/2 custom operators requred (where n =
# of units in your system and p = the average number of operators per
unit combo), you could potentially have to add 45p operators when the
10th unit is added, 105p operators when the 15th unit is added, and
190p operators when the 20th unit is added. If p is 2 ("*" and "/"),
then that's 90, 210, and 380 operator subprograms respectively.

According to http://www.unc.edu/~rowlett/units/index.html, there are
actually 7 "fundamental" units, 22 more derived units with approved
names, and a theoreticly limitless amount of derived units without
approved names (eg: volume, luminance). There are 21 prefixes (powers
of 10 scalings) any one of these units may have applied to them. Of
course many of those would make no sense and could probably be left
out (eg: yottaseconds, zeptoamperes). But if you try to do the math
from here, you get into a ludicrous number of operator routines you
are going to have to create.

Now its quite possible that p is not constant in this equation, in
other words that there are only a limited number of other units that
any one unit will ever have to interact with (not related at all to
n). That might make things manageable. That's one of the things I
wouldn't know, not being an engineering math user myself.

Now I'm not saying I think an SI package is a Bad Idea. Every project
I've worked on had its own auxililary math ops and types package, so
that would be a silly claim. Even without a separate type for every
SI, it would be useful. I just want to make sure you really know what
you are getting into. If you do go down this path, at least figure out
up front how you are going to cull things down to keep it humanly
doable.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Marin David Condic]

Not only is there the proliferation of operators as an issue, but one of
efficiency as well. Perhaps you can pragma Inline them all or otherwise get
the code minimized & avoid all the function calls, but it seems this is
still "at risk" to not be very efficient or small if a given compiler is not
very good at the optimizations. The point is that even if you want some
separation of the types at the abstract, high-level of your program, what
you want in the way of machine code is a simple
add/subtract/multiply/divide. If you can't make it degenerate to that, then
you've got efficiency concerns.

Besides, it seems to kind of be working at cross purposes. First you create
separate types to avoid the arbitrary mixing of one thing with another, then
you invent a bunch of operators that allow you to mix them up again. Yeah,
you still have protection from some kinds of errors (assigning Volts to
Amps, e.g.)  but we ought to ask if these are the most prevalent of errors
that strong typing protects against and is it worth the bazillion operators,
overhead, & potential obfuscation that results?

It might be sufficient and simpler to do something like define a type
Electrical_Units_Type (or Physics_Units_Type, or whatever others you think
of) out of which you can make Volts and Amps & etc. (or Mass & Acceleration
& etc.) That might fall into the category of Good Enough. That would let you
do Volts * Amps but not Volts * Mass. Is that sufficient type safety?

OTOH, if someone wanted to come up with an all-encompassing set of packages
that provided engineering unit calculations & conversions with generic
versions for Integer, Fixed, Decimal and Floating Point types, I doubt I'd
try to stop them. If it looked good and seemed to be workable on a practical
level, I'd be willing to go along with adding it to Grace. Just because I
can't imagine such a package that wouldn't be a major pain in the posterior
doesn't mean that someone more clever than myself won't come up with one.
:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205150657.3b695758@posting.google.com...
>
> I'm certianly not an engineering math expert, but I've watched enough
> of them try to go this route and fail that I'm skeptical. The big
> problem was always the geometric explosion of operators required for
> every new unit added. Its no biggie when you just have positions and
> velocities, but at ((n-1)n * p)/2 custom operators requred (where n =
> # of units in your system and p = the average number of operators per
> unit combo), you could potentially have to add 45p operators when the
> 10th unit is added, 105p operators when the 15th unit is added, and
> 190p operators when the 20th unit is added. If p is 2 ("*" and "/"),
> then that's 90, 210, and 380 operator subprograms respectively.
<snip>

Re: Announce: Grace project site operational

[tmoran]

> Not only is there the proliferation of operators as an issue, but one of
> efficiency as well. Perhaps you can pragma Inline them all or otherwise get
  Think of type dimension checking as a special check performed by a
special tool - your compiler.  If you currently have a nice efficient
  package My_Units is  -- version after the compiler has said dimensions are OK
    subtype Miles is Float range ...
    subtype Hours is Float range ...
  end My_Units;
then, when it's time to check that the dimensions are OK, replace that
package with
  package My_Units is -- version to check if I screwed up dimensions
    type Miles is new Float range ...
    type Hours is new Float;
    -- appropriate '*' and '/' functions
  end My_Units;
and see if your program still compiles.  If not, fix the problem.  When
it does compile, switch back to the original package My_Units and
compile to generate code.

Re: Announce: Grace project site operational

[tmoran]

> Not only is there the proliferation of operators as an issue, but one of
> efficiency as well. Perhaps you can pragma Inline them all or otherwise get
  Think of type dimension checking as a special check performed by a
special tool - your compiler.  If you currently have a nice efficient
  package My_Units is  -- version without any dimension checking
    subtype Miles is Float range ...
    subtype Hours is Float range ...
  end My_Units;
then, when it's time to check that the dimensions are OK, replace that
package with
  package My_Units is -- version to check if I screwed up dimensions
    type Miles is new Float range ...
    type Hours is new Float;
    -- appropriate '*' and '/' functions
  end My_Units;
and see if your program still compiles.  If not, fix the problem.  When
it does compile, switch back to the original package My_Units and
compile to generate code.

Re: Announce: Grace project site operational

[Marin David Condic]

I see what you're saying and I could see how it would be useful in specific
environments where you have a limited set of units you're using. I think
there would be a problem attempting to come up with something more general
for a package like Grace that wants to provide utility for as yet TBD
applications. There the proliferation of operations and the ability to
substitute subtypes for types could be problematic.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


<tmoran@acm.org> wrote in message
news:MqZE8.20$Td3.11723926@newssvr21.news.prodigy.com...
>   Think of type dimension checking as a special check performed by a
> special tool - your compiler.  If you currently have a nice efficient
>   package My_Units is  -- version without any dimension checking
>     subtype Miles is Float range ...
>     subtype Hours is Float range ...
>   end My_Units;
> then, when it's time to check that the dimensions are OK, replace that
> package with
>   package My_Units is -- version to check if I screwed up dimensions
>     type Miles is new Float range ...
>     type Hours is new Float;
>     -- appropriate '*' and '/' functions
>   end My_Units;
> and see if your program still compiles.  If not, fix the problem.  When
> it does compile, switch back to the original package My_Units and
> compile to generate code.

Re: Announce: Grace project site operational

[tmoran]

> something more general for a package like Grace that wants to provide
> utility for as yet TBD applications.
  It wouldn't be the first time an attempt to please everybody wound up
pleasing nobody.  Probably the least likely to offend approach is to
simply decide that dealing with units is not a part of Grace.

Re: Announce: Grace project site operational

[Martin Dowie]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205150657.3b695758@posting.google.com...
> > It might be big, it might not be pretty, but once its there it's not
> > exactly going to be changing! :-)
>
> [snip lots of healthy skeptisism]
>
> Now I'm not saying I think an SI package is a Bad Idea. Every project
> I've worked on had its own auxililary math ops and types package, so
> that would be a silly claim. Even without a separate type for every
> SI, it would be useful. I just want to make sure you really know what
> you are getting into. If you do go down this path, at least figure out
> up front how you are going to cull things down to keep it humanly
> doable.

AOL :-)

Getting agreement on this could be tricky.

The package I'm looking just now has:
 12 powers of 10
  7 basic SI units
  2 'supplementary units
 58 'derived' units
 23 'other' units
282 "/", "*" & "**" functions

and a couple of dozen elementary math functions!

I understand how these things can add up. Unfortunately, I'm not sure
of the copyright status of this package (I think it is based on the
"whitaker" package, but I have made it generic and played around with
adding some generic formal packages.

There is also a sibling package containing conversions from a couple
of dozen non-SI units.

Re: Announce: Grace project site operational

[Larry Kilgallen]

In article <3ce28401$1@pull.gecm.com>, "Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0205150657.3b695758@posting.google.com...
>> > It might be big, it might not be pretty, but once its there it's not
>> > exactly going to be changing! :-)
>>
>> [snip lots of healthy skeptisism]
>>
>> Now I'm not saying I think an SI package is a Bad Idea.

It sounds like a good idea to me, and I do feel I understand the
discussion, but could somebody please tell me what "SI" means ?

Re: Announce: Grace project site operational

[David C. Hoos]

----- Original Message -----
From: "Larry Kilgallen" <Kilgallen@SpamCop.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Wednesday, May 15, 2002 12:33 PM
Subject: Re: Announce: Grace project site operational

<snip>

> It sounds like a good idea to me, and I do feel I understand the
> discussion, but could somebody please tell me what "SI" means ?
>
Systeme Internationale (I hope my French spelling is correct), the
International
System of Units.  See (e.g.) http://physics.nist.gov/cuu/Units/

Re: Announce: Grace project site operational

[tmoran]

> actually 7 "fundamental" units, 22 more derived units with approved
> names, and a theoreticly limitless amount of derived units without
> approved names (eg: volume, luminance). There are 21 prefixes (powers
> of 10 scalings) any one of these units may have applied to them. Of
> course many of those would make no sense and could probably be left
> out (eg: yottaseconds, zeptoamperes). But if you try to do the math
> from here, you get into a ludicrous number of operator routines you
> are going to have to create.
>...
> other words that there are only a limited number of other units that
> any one unit will ever have to interact with (not related at all to

    So it's a Bad Idea to try to make one units package for all the world
to use, but reasonable ones for reasonable subsets of the world may still
be a Good Idea.  Should a single program actually deal with some distances
in meters, some in centimeters, and some in kilometers, or miles?  Given
floating point arithmetic, that sounds to me like a way to write sloppy,
debug slowly (or explain to Congress, painfully).  In the real world, how
often does a chemist need accelerations, or a mechanical engineer mol,
anybody mole*acceleration.
    Strong typing is a powerful tool to expose errors.  You need an
awfully good reason to forswear use of such a tool.

Re: Announce: Grace project site operational

[Marin David Condic]

I agree that strong typing is a good thing - usually. But do you think you
might get the benefit of strong typing if, for example, there was a single
type being used for a package supporting Chemistry calculations - possibly
with subtypes for the individual units? Or would you insist that the safety
can only come if each variety of unit has its own type? (In the first case,
you would definitely catch Mole * Acceleration, because the two would be of
different types for different problem-domain packages.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


<tmoran@acm.org> wrote in message
news:KLBE8.2611$Ms5.182082818@newssvr21.news.prodigy.com...
> debug slowly (or explain to Congress, painfully).  In the real world, how
> often does a chemist need accelerations, or a mechanical engineer mol,
> anybody mole*acceleration.
>     Strong typing is a powerful tool to expose errors.  You need an
> awfully good reason to forswear use of such a tool.

Re: Announce: Grace project site operational

[Ted Dennison]

tmoran@acm.org wrote in message news:<KLBE8.2611$Ms5.182082818@newssvr21.news.prodigy.com>...
>     So it's a Bad Idea to try to make one units package for all the world
> to use, but reasonable ones for reasonable subsets of the world may still
> be a Good Idea. 

Possibly. But if you are talking about subsets for certain jobs, you
are no longer talking about a general-purpose package, which means you
are also no longer talking about Grace.
 
> ...             Should a single program actually deal with some distances
> in meters, some in centimeters, and some in kilometers, or miles?  Given

Typically not. But a general SI package would have to support all of
them, because some users might need meters (flight sims) while others
might need kilometers (space probes).


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Marin David Condic]

Just a hunch, but I'd bet that if Grace provided a few packages that did
garden variety unit calculations and maybe some general
scientific/engineering math and that all they had were a generic parameter
for the user to specify the floating point type they wanted (and/or fixed,
decimal & integer variations on the theme.) that this would get used quite a
bit. Would developers eschew it in favor of their own strongly-typed custom
packages if these a) existed already and b) were known to be reliable?

I know if I'm reading volts or frequencies or something like this from the
outside world, I'll create a special type to represent it, but if I had to
do some general engineering calculations, I'd convert to some numeric type
of sufficient accuracy & take my chances without distinct types for each
unit. If I had the package already built for me and all I had to do was
instantiate it with the numeric accuracy I wanted? I'd be thrilled that I
got the leverage with a well tested, proven package. If it came with my Ada
compiler rather than having to go dig around for it somewhere? Even better.
"Hey all you engineers & scientists out there! Get rid of your C and Fortran
compilers and write your code in Ada because it already comes with a bunch
of code you need!!!" :-)

There might be better answers out there, but I'd be happy with a sub-optimal
answer that was simple to use & got my job done *today* rather than some
nebulous time in the future when everything is going to be sunshine and
rainbows. But that's just me. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205160543.34b32481@posting.google.com...
>
> Typically not. But a general SI package would have to support all of
> them, because some users might need meters (flight sims) while others
> might need kilometers (space probes).
>

Re: Announce: Grace project site operational

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> tmoran@acm.org wrote in message
> news:<KLBE8.2611$Ms5.182082818@newssvr21.news.prodigy.com>... 
> >     So it's a Bad Idea to try to make one units package for all the world
> > to use, but reasonable ones for reasonable subsets of the world may still
> > be a Good Idea. 
> 
> Possibly. But if you are talking about subsets for certain jobs, you
> are no longer talking about a general-purpose package, which means you
> are also no longer talking about Grace.

Actually, I think a tool that generates the package on demand _is_ a
good candidate for Grace. Well, as long as it's written in Ada :).

> > ... Should a single program actually deal with some distances in
> > meters, some in centimeters, and some in kilometers, or miles?
> > Given
> 
> Typically not. But a general SI package would have to support all of
> them, because some users might need meters (flight sims) while others
> might need kilometers (space probes).

I always use meters for all internal calculations even for space
probes. With 64 bit floating point, three orders of magnitude is
insignificant. The potential for confusion is too great otherwise.

Case in point; I had a nine orders of magnitude error once, because
there was a constant that had units of m^3, and someone provided it in
km^3. After that, I learned to insist on meters, everywhere.

However, user interfaces are another matter. Users want their
"favorite units", even if they are non-SI. So perhaps a second package
that provides conversion between "standard" and "non-standard" units
is needed; it need not provide any other operations on the
non-standard units.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Marin David Condic]

But then you're widening out the scope of Grace. Is Grace a simple library
of useful, general purpose, programming utilities? Or is Grace a software
development kit? I personally would like to see it stick to being just a
collection of useful packages that address general programming problems.
That way, there is some reasonable liklihood that it can become something of
a standard. It also keeps the scope down to something likely to be
achievable within our lifetimes. :-)

I think if someone wanted to produce a tool to generate packages on demand,
this might be a useful thing, but that it probably should not be part of
Grace.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ud6vu23gc.fsf@gsfc.nasa.gov...
>
> Actually, I think a tool that generates the package on demand _is_ a
> good candidate for Grace. Well, as long as it's written in Ada :).
>

Re: Announce: Grace project site operational

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> But then you're widening out the scope of Grace. Is Grace a simple library
> of useful, general purpose, programming utilities? 

Yes.

> Or is Grace a software development kit? 

Also yes. 

> I personally would like to see it stick to being just a collection
> of useful packages that address general programming problems. That
> way, there is some reasonable liklihood that it can become something
> of a standard. 

Well, the "standardization committee" can pick and choose from Grace
components.

> It also keeps the scope down to something likely to be achievable
> within our lifetimes. :-)

I'd like to open it up to anything anyone wants to contribute, that
has a reasonable chance of being useful to many people. I have not yet
looked at PragmArc's unit package generator, but it's probably a good
first draft, which puts it on a par with Grace.Lists. It's certainly a
less complex problem; I think it received a reasonable amount of
design discussion here, and a reasonable amount of "I'd like that".

> I think if someone wanted to produce a tool to generate packages on
> demand, this might be a useful thing, but that it probably should
> not be part of Grace.

Sounds like we need a "Grace committee" to vote on what goes in Grace.
That might be a good idea; the "GNAT committee" has done a fantastic
job :).

-- 
-- Stephe

PS. Yes, I know ACT is way more than a committee. That's what the
smiley is for.

Re: Announce: Grace project site operational

[Ted Dennison]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<ulmadlgv3.fsf@gsfc.nasa.gov>...

> Sounds like we need a "Grace committee" to vote on what goes in Grace.
> That might be a good idea; the "GNAT committee" has done a fantastic
> job :).

Our philosophy so far has been consensus rather than voting. I
understand that is the norm for successful collabarative software
projects, so I'd like to stick to that rule.

Re: Announce: Grace project site operational

[Marin David Condic]

The only problem is that it is a Consensus of those who care enough to post
something about it. :-) I'd say that the best approach would be that if
someone had a notion that something belonged in Grace, they ought to post a
trial-specification here with enough meat to it that people could get a
flavor of what it would be like. If its got any appeal, that would become
apparent & it would likely end up in the project. That's basically how the
Lists package got there.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205210924.47123478@posting.google.com...
> Our philosophy so far has been consensus rather than voting. I
> understand that is the norm for successful collabarative software
> projects, so I'd like to stick to that rule.

Re: Announce: Grace project site operational

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'd say that the best approach would be that if
> someone had a notion that something belonged in Grace, they ought to post a
> trial-specification here with enough meat to it that people could get a
> flavor of what it would be like. If its got any appeal, that would become
> apparent & it would likely end up in the project. 

Seems to me "marks" and "make_unit" meet that criterion. Now we just
need to work out a consensus on the format of the units definition
input file, and some style details for the generated Ada spec. Then
we'd have a specification for a standard Grace component.

Although, I'd hold off a little bit till people actually try it in
real projects. I'm not convinced it will turn out to be useful.

Well, it would be useful in physics classes, and possibly in computer
science classes, as an example of what kinds of thing _can_ be done.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Martin Dowie]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uelg4jgrx.fsf@gsfc.nasa.gov...
> Seems to me "marks" and "make_unit" meet that criterion. Now we just
> need to work out a consensus on the format of the units definition
> input file, and some style details for the generated Ada spec. Then
> we'd have a specification for a standard Grace component.
>
> Although, I'd hold off a little bit till people actually try it in
> real projects. I'm not convinced it will turn out to be useful.

I haven't had the benefit of a 'units' generator but I have re-used
the same (simple) SI units package on a few projects - an all to
rare example of real software re-use!

Re: Announce: Grace project site operational

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:<ulmadlgv3.fsf@gsfc.nasa.gov>...
> 
> > Sounds like we need a "Grace committee" to vote on what goes in Grace.
> > That might be a good idea; the "GNAT committee" has done a fantastic
> > job :).
> 
> Our philosophy so far has been consensus rather than voting. I
> understand that is the norm for successful collabarative software
> projects, so I'd like to stick to that rule.

Consensus is fine, but you still need to define the group that needs
to reach consensus. "whoever posts on this topic on comp.lang.ada" is
one definition, but it's a little too vague for me.

-- 
-- Stephe

Re: Announce: Grace project site operational

[John English]

Ted Dennison wrote:
> I'm certianly not an engineering math expert, but I've watched enough
> of them try to go this route and fail that I'm skeptical. The big
> problem was always the geometric explosion of operators required for
> every new unit added. Its no biggie when you just have positions and
> velocities, but at ((n-1)n * p)/2 custom operators requred (where n =
> # of units in your system and p = the average number of operators per
> unit combo), you could potentially have to add 45p operators when the
> 10th unit is added, 105p operators when the 15th unit is added, and
> 190p operators when the 20th unit is added. If p is 2 ("*" and "/"),
> then that's 90, 210, and 380 operator subprograms respectively.

Surely the "right" way to do it is to express each value as a tuple
consisting of magnitude and the exponents of each dimension, so
9.8 m/s**2 is (9.8, length=>1, time=>-2). Then you just have at most
three versions of each operation (tuple op tuple, tuple op magnitude,
magnitude op tuple) or even just tuple op tuple with a conversion
from magnitude to (magnitude, others=>0).

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Announce: Grace project site operational

[Stephen Leake]

John English <je@brighton.ac.uk> writes:

> Surely the "right" way to do it is to express each value as a tuple
> consisting of magnitude and the exponents of each dimension, so
> 9.8 m/s**2 is (9.8, length=>1, time=>-2). Then you just have at most
> three versions of each operation (tuple op tuple, tuple op magnitude,
> magnitude op tuple) or even just tuple op tuple with a conversion
> from magnitude to (magnitude, others=>0).

Yes, that is the easiest to implement, and covers all possible units.
But it has run-time overhead, which is just not acceptable in a
real-time system.

One approach is to use such a package during development and unit
testing, to help catch unit errors. Then switch to a flat "all types
are float" package for the final build and system test. If the switch
can be made cleanly, and yield _no_ runtime overhead, this might be
the best approach.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Hyman Rosen]

John English wrote:
> Surely the "right" way to do it is to express each value as a tuple
> consisting of magnitude and the exponents of each dimension, so
> 9.8 m/s**2 is (9.8, length=>1, time=>-2).

Yes. The question is, are the exponents part of the type,
or part of the object?

> Then you just have at most three versions of each operation

So you are talking about making the exponents part of the object.
This loses in two ways. First, every unit object carries along a
tuple, instead of just holding its value. Second, the compiler
no longer provides any type checking for unit correctness, since
tuple compatibility will involve a runtime check.

Re: Announce: Grace project site operational

[tmoran]

> That's the biggie. If you try to make separate types for velocities
> and accelerations, you will suddenly find that you also need separate
> types for times and distances, and perhaps even Hz and mass and forces
> and rotational orientations and velocitites and accelerations. Then
> you'll find how annoying it is to have to do type conversions on every
> factor in every formula. A more attractive option may be to write your
> own math operators that return the correct type given their two input
> types. But that causes an exponential growth in operators that you
> have to create every time you add a new unit.
  How about "usually use Standard.Float but rarely use Standard.Integer".
Most of the times expressions mix types they are physical things, and
typically floating point, while integers are usually used for things
like counts and subscripts, where mixed expressions are rare.

> ... automaticly generates the proper new type given the operator and
> the types of its operands.
  How about a(nother) new Ada 0x construct:
     dimension <real type> <multiplying operator> <real type>
optionally appended to a type declaration, eg
type Seconds is new Float;
type Centimeters is new Float;
type Grams is new Float;
type Velocity is new Float dimension Centimeters/Seconds;
type Acceleration is new Float dimension Velocity/Seconds;
type Dynes is new Float dimension Grams*Acceleration;
 t : Seconds;
 d : Centimeters range 0.0 .. 100.0;
 v : Velocity;
 f : Dynes;
  Then have the compiler allow an expression like "v*t" and have it
do the dimensional analysis at compile seconds to know the result is
of some declared type, in this case Centimeters.  v+t is still
caught as an error and, since neither a square centimeter nor an erg
type have been declared, expressions like d*d and f*d are caught.

> Generally, what I see Ada folk do is use *subtypes* for all this
  That's really orthogonal.  In a program about electric cars you
should be able to say
type Miles is digits 4 range 0.0 .. 100.0;
type Hours is new Float range 0.0 .. 2.0;
type Speed is new Float range 0.0 .. 60.0 dimension Miles/Seconds;

Re: Announce: Grace project site operational

[Preben Randhol]

On Tue, 14 May 2002 17:50:47 GMT, tmoran@acm.org wrote:
>   How about a(nother) new Ada 0x construct:
>      dimension <real type> <multiplying operator> <real type>
> optionally appended to a type declaration, eg
> type Seconds is new Float;
> type Centimeters is new Float;
> type Grams is new Float;
> type Velocity is new Float dimension Centimeters/Seconds;
> type Acceleration is new Float dimension Velocity/Seconds;
> type Dynes is new Float dimension Grams*Acceleration;
>  t : Seconds;
>  d : Centimeters range 0.0 .. 100.0;
>  v : Velocity;
>  f : Dynes;
>   Then have the compiler allow an expression like "v*t" and have it
> do the dimensional analysis at compile seconds to know the result is
> of some declared type, in this case Centimeters.  v+t is still
> caught as an error and, since neither a square centimeter nor an erg
> type have been declared, expressions like d*d and f*d are caught.

As a chemist I want mol and Kelvin, but how do one deal with
constructions like this:

Constant = (C1*C2)/(C3^0.5)  = mol�/mol^0.5 = mol^(3/2)
or
Constant = C1/C2 = mol / mol = unitless

Preben

Re: Announce: Grace project site operational

[Preben Randhol]

On Tue, 14 May 2002 18:07:53 +0000 (UTC), Preben Randhol wrote:
> 
> As a chemist I want mol and Kelvin, but how do one deal with
> constructions like this:
> 
> Constant = (C1*C2)/(C3^0.5)  = mol�/mol^0.5 = mol^(3/2)

oops forgot to say that Constant is alway unitless as one divides by the
standard state, but one still will use the concentrations as above as
the standard state is 1. I didn't write mol/l in order to make it less
confusing.

Another example:

   CO2 (g)  = CO2 (aq)
   
   Constant = atm/(mol/l)

Preben

Re: Announce: Grace project site operational

[Hyman Rosen]

Preben Randhol wrote:
>>As a chemist I want mol and Kelvin, but how do one deal with
>>constructions like this:
>>
>>Constant = (C1*C2)/(C3^0.5)  = mol�/mol^0.5 = mol^(3/2)

Time for me to bring up my usual post about units in C++,
which can be done with complete type safety and with no
run-time overhead in time or storage, because of C++'s
automatic instantiation rules. Here's the simplified
example involving only mass, distance, and time. The code
allows only like units to be added or subtracted, but
arbitrary units to be multiplied or divided, with the
correctly typed result. Constants are units with all
paremeters set to zero. All the verbiage is for types;
the actual storage for each unit object is just the
value, and all type correctness is checked at compile
time, not run time. The correctly typed operators are
automatically instantiated when used, without manual
intervention.

I first saw this idiom in _Scientific and Engineering C++_
by Bartion & Nackman.

template<typename RepType, int Mass, int Distance, int Time>
struct Unit
{
	RepType value;
	explicit Unit(value) : value(value) { }
	Unit operator+(Unit other)
	{ return Unit(value + other.value); }
	Unit operator-(Unit other)
	{ return Unit(value - other.value); }
};

template<typename RepType,
	 int MassL, int DistanceL, int TimeL,
	 int MassR, int DistanceR, int TimeR>
Unit<RepType,
      MassL + MassR,
      DistanceL + DistanceR,
      TimeL + TimeR>
operator*(Unit<RepType, MassL, DistanceL, TimeL> l,
	  Unit<RepType, MassR, DistanceR, TimeR> r)
{
	return Unit<RepType,
		    MassL + MassR,
		    DistanceL + DistanceR,
		    TimeL + TimeR>(l.value * r.value);
}

template<typename RepType,
	 int MassL, int DistanceL, int TimeL,
	 int MassR, int DistanceR, int TimeR>
Unit<RepType,
      MassL - MassR,
      DistanceL - DistanceR,
      TimeL - TimeR>
operator/(Unit<RepType, MassL, DistanceL, TimeL> l,
	  Unit<RepType, MassR, DistanceR, TimeR> r)
{
	return Unit<RepType,
		    MassL - MassR,
		    DistanceL - DistanceR,
		    TimeL - TimeR>(l.value / r.value);
}

typedef Unit<double, 0, 1, -1> Velocity;
typedef Unit<double, 0, 1, -2> Acceleration;
typedef Unit<double, 1, 2, -2> Energy;
typedef Unit<double, 0, 0, -1> Herz;
// etc.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Tue, 14 May 2002 14:52:58 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Time for me to bring up my usual post about units in C++,
>which can be done with complete type safety and with no
>run-time overhead in time or storage, because of C++'s
>automatic instantiation rules.

The same could be achieved without templates if there were a way to
ensure that a user-defined subroutine is compile-time and known type
discriminants / tags are removed [*]. I believe that an improvement of
Ada's ADT/OO gears is much more important than any investments in
inherently flawed generics-templates-macros.

Generally, I dislike any type-based solution of the unit problem. I
believe that the right way is a subtype-based, OO-ish one. Whether the
dimension be a discriminant or tag [**] is no matter. There must be a
way to write class-wide subroutines for dimensioned values. Any
type-based solution lacks that without any hope.

[*] Well, there is a performance problem with tagged types which were
unnecessarily forced to be always by-reference.

[**] Here I consider derived tagged types "subtypes".

>Here's the simplified
>example involving only mass, distance, and time. The code
>allows only like units to be added or subtracted, but
>arbitrary units to be multiplied or divided, with the
>correctly typed result. Constants are units with all
>paremeters set to zero. All the verbiage is for types;
>the actual storage for each unit object is just the
>value, and all type correctness is checked at compile
>time, not run time. The correctly typed operators are
>automatically instantiated when used, without manual
>intervention.
>
>I first saw this idiom in _Scientific and Engineering C++_
>by Bartion & Nackman.
>
>template<typename RepType, int Mass, int Distance, int Time>
>struct Unit
>{
>	RepType value;
>	explicit Unit(value) : value(value) { }

A small correction. The above should be:
   explicit Unit(RepType value) : value(value) {}

>	Unit operator+(Unit other)
>	{ return Unit(value + other.value); }
>	Unit operator-(Unit other)
>	{ return Unit(value - other.value); }
>};
>
>template<typename RepType,
>	 int MassL, int DistanceL, int TimeL,
>	 int MassR, int DistanceR, int TimeR>
>Unit<RepType,
>      MassL + MassR,
>      DistanceL + DistanceR,
>      TimeL + TimeR>
>operator*(Unit<RepType, MassL, DistanceL, TimeL> l,
>	  Unit<RepType, MassR, DistanceR, TimeR> r)
>{
>	return Unit<RepType,
>		    MassL + MassR,
>		    DistanceL + DistanceR,
>		    TimeL + TimeR>(l.value * r.value);
>}
>
>template<typename RepType,
>	 int MassL, int DistanceL, int TimeL,
>	 int MassR, int DistanceR, int TimeR>
>Unit<RepType,
>      MassL - MassR,
>      DistanceL - DistanceR,
>      TimeL - TimeR>
>operator/(Unit<RepType, MassL, DistanceL, TimeL> l,
>	  Unit<RepType, MassR, DistanceR, TimeR> r)
>{
>	return Unit<RepType,
>		    MassL - MassR,
>		    DistanceL - DistanceR,
>		    TimeL - TimeR>(l.value / r.value);
>}
>
>typedef Unit<double, 0, 1, -1> Velocity;
>typedef Unit<double, 0, 1, -2> Acceleration;
>typedef Unit<double, 1, 2, -2> Energy;
>typedef Unit<double, 0, 0, -1> Herz;
>// etc.

As always with C++, the above does not work with MS-VC++, but it does
work with gcc. Diagnostics in case of a unit error is a mess, as
expected. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 > I believe that an improvement of Ada's ADT/OO gears is
 > much more important than any investments in inherently
 > flawed generics-templates-macros.

There were no macros in my C++ code, and there are no macros
in Ada. Generics/templates are not inherently flawed.

> Generally, I dislike any type-based solution of the unit problem.
> I believe that the right way is a subtype-based, OO-ish one.

Yes, that seems to go along with your "inherently flawed".
You're wrong, because units exist, even in the real world,
only to serve as type tags. The operations on them are just
pure arithmetic on the values they represent; the unit itself
plays no part in the calculation. (Aside from the silly biased
temperature units, which are just dispensed with by working in
Kelvin.) I fail to see the need for any OO approach to units.
What are you placing in derived types which is different from
the base type? Why do you want run-time dispatching?

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Wed, 15 May 2002 14:30:30 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> > I believe that an improvement of Ada's ADT/OO gears is
> > much more important than any investments in inherently
> > flawed generics-templates-macros.
>
>There were no macros in my C++ code, and there are no macros
>in Ada. Generics/templates are not inherently flawed.

In short, generics are macros.

>> Generally, I dislike any type-based solution of the unit problem.
>> I believe that the right way is a subtype-based, OO-ish one.
>
>Yes, that seems to go along with your "inherently flawed".
>You're wrong, because units exist, even in the real world,
>only to serve as type tags. The operations on them are just
>pure arithmetic on the values they represent; the unit itself
>plays no part in the calculation. (Aside from the silly biased
>temperature units, which are just dispensed with by working in
>Kelvin.)

I do not see why the above should serve an argument against a
subtype-based solution. Generics are bad for units because they
enforce dimensioned values be of unrelated types. Note that it has
nothing to do with strong typing and compile-time checks. All that can
be done with subtypes.

>I fail to see the need for any OO approach to units.
>What are you placing in derived types which is different from
>the base type?

Nothing. The derived type is just another subtype to enforce
compile-time type checking. For instance, a discriminant-based
variant:

   type Measure (SI : Unit := Unitless) is record
      Gain : Number;
   end record;)

You can derive a subtype from it by constraining:

   subtype Speed is Measure (Velocity);
   subtype Length is Measure (Distance);

Now:

   X : Speed;
   Y : Length;

   X := Y; -- Constraint_Error

It is absolutely safe, and a decent Ada compiler should give you
warning at compile time.

>Why do you want run-time dispatching?

How do you write a Put for dimensioned values? It shall be class-wide
= work on all unit [sub]types. Do you want to make it generic and
instantiate each time? Consider a real-world application. There is a
roller dynamometer. It has thousands of sensors and actors, many of
them are just analogue inputs/outputs. It has a human interface with
hundreds virtual instruments capable to indicate readings in any unit.
The operator can configure measurement channels dynamically. Nobody
knows which unit will have the input channel 1208 next day. Nobody
knows whether the gauge X on the panel Y will show the velocity in
km/h or in mph. With a type-based units implementation you will be
lost.

A real unit solution should combine compile-time checks and effective
removal of unit information when it is statically known, with an
ability to deal with measures of unknown dimension with checks at
run-time.

Re: Announce: Grace project site operational

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> In short, generics are macros.

In exactly the same sense that FOR loops are GOTOs.

> Generics are bad for units because they enforce dimensioned
 > values be of unrelated types.

Why is that bad?

 > For instance, a discriminant-based variant:
>    type Measure (SI : Unit := Unitless) is record
>       Gain : Number;
>    end record;

In all Ada versions that anyone here has ever mentioned,
this drags along a discriminant as part of the object,
making it bigger.

>    X := Y; -- Constraint_Error
> 
> A decent Ada compiler should give you warning at compile time.

In the type-based version, it *must* fail at compile time.

> How do you write a Put for dimensioned values? It shall be class-wide
> = work on all unit [sub]types. Do you want to make it generic and
> instantiate each time?

Yes, I would make it generic and instantiate each time.
In C++, of course, the instantiation would be done for me.
Here's what it would look like for a simple gram-centimeter-second
system. All of the 'if' tests in the code below are static at
compile time, so they will not consume any runtime.

template<typename Stream, typename RepType, int Mass, int Distance, int Time>
Stream &operator<<(Stream &out, const Unit<RepType, Mass, Distance, Time> &u)
{
	out << u.value;
	if (Mass > 0) out << " gm";
	if (Mass > 1) out << "^" << Mass;
	if (Distance > 0) out << " cm";
	if (Distance > 1) out << "^" << Distance;
	if (Time > 0) out << " sec";
	if (Time > 1) out << "^" << Time;
	if (Mass < 0 || Distance < 0 || Time < 0) out << " /";
	if (Mass < 0) out << " gm";
	if (Mass < -1) out << "^" << -Mass;
	if (Distance < 0) out << " cm";
	if (Distance < -1) out << "^" << -Distance;
	if (Time < 0) out << " sec";
	if (Time < -1) out << "^" << -Time;
	return out;
}

And it's used like this, given suitable typedefs and values:
	Mass m = 3 * pound;
	Acceleration g = 32 * foot / second / second
	std::cout << " Mass = " << m
		  << " Acceleration = " << g
		  << " Force = " << m * g
		  << '\n';

> There is a roller dynamometer.

Shrug. Yes, if you really have a system where everything is
completely dynamic, then a type-based solution will be difficult
or perhaps impossible to use. On the other hand, I'm guessing
that most people's sensors stay put and measure one thing.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Thu, 16 May 2002 15:42:06 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> In short, generics are macros.
>
>In exactly the same sense that FOR loops are GOTOs.

In which sense? For and goto are language constructs. Generics are
rather meta-language (preprocessor's language) constructs. The idea of
a generic is: let's substitute A for X and see if the compiler will
eat that. Macros substitute arbitrary strings. C++ templates
substitute arbitrary types. Ada is much better in that respect, but is
still bad. If you consider Ada generics from ADT point of view, i.e.
how actual paramters match formal ones, you will note that it is
strong typed, but has no user-defined types (of formal generic
parameters) at all. All types are built-in: (<>), range <>, digits <>,
etc. C++ templates are simply untyped, substitute'n'pray.

>> Generics are bad for units because they enforce dimensioned
> > values be of unrelated types.
>
>Why is that bad?

Because dimensioned values are not unrelated. Their types are
siblings, having a common supertype, and very often we need objects of
that supertype.

> > For instance, a discriminant-based variant:
>>    type Measure (SI : Unit := Unitless) is record
>>       Gain : Number;
>>    end record;
>
>In all Ada versions that anyone here has ever mentioned,
>this drags along a discriminant as part of the object,

Yes it is an unfortunate feature of Ada [C++ is not better], which
tries to treat subtypes as things having same representation. Once
language designers drop this IMO unnecessary limitation, they will
say, that an unconstrainted subtype of Measure shall keep the
discriminant, while a constrained one shall not. Same with tags,
class-wide objects have one, specific ones do not. End of story.

>making it bigger.

That's no problem, your macro expansions (:-)) will probably eat even
more. The real problem is that it is slower. My implementation of
measurement units is approximately 4 times slower as compared with
pure floating-point arithmetic. (:-()

>>    X := Y; -- Constraint_Error
>> 
>> A decent Ada compiler should give you warning at compile time.
>
>In the type-based version, it *must* fail at compile time.

Just set warnings = errors in your IDE.

>> How do you write a Put for dimensioned values? It shall be class-wide
>> = work on all unit [sub]types. Do you want to make it generic and
>> instantiate each time?
>
>Yes, I would make it generic and instantiate each time.

How big will be your application, if all possible subroutines dealing
with units will be instantiated?

>In C++, of course, the instantiation would be done for me.
>Here's what it would look like for a simple gram-centimeter-second
>system. All of the 'if' tests in the code below are static at
>compile time, so they will not consume any runtime.

It will consume memory at run time. Your system will be too big. You
will be unable to put the things into a library, because, well,
generics are macros. You will be unable to write some applications at
all. Consider a unit-aware calculator. How to implement it with
generics?

>> There is a roller dynamometer.
>
>Shrug. Yes, if you really have a system where everything is
>completely dynamic, then a type-based solution will be difficult
>or perhaps impossible to use. On the other hand, I'm guessing
>that most people's sensors stay put and measure one thing.

Yes, but a sensor is usually attached to the system via an A/D
converter, which are expensive. So customers routinely reuse their
converters by re-attaching different sensors to the system: today a
temperature sensor, tomorrow a pressure sensor, etc. But the main
problem is virtual instuments. Should we instantiate all of them for
all necessary units, the system would probably require a cluster of
supercomputers. (:-))

The moral of the story is that no real system uses 100% static or 100%
dynamic checks. It is 20/80 or 80/20 depending on the application.
Therefore an ultimative solution shall effectively support both.
Generics cannot help us in that, they are doomed to be static.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 > The idea of a generic is: let's substitute A for X
 > and see if the compiler will eat that.

In the same way that a procedure is: let's substitute
V for P and see if the compiler will eat that. Clearly,
you dislike generics so you invent extra-linguistic
nomenclature to claim that one language construct is
within the language while another is not.

> Because dimensioned values are not unrelated. Their types are
> siblings, having a common supertype, and very often we need objects of
> that supertype.

Why is a kilometer at all related to an hour?
Why do they need a common supertype?

>  an unconstrainted subtype of Measure shall keep the
> discriminant, while a constrained one shall not. Same with tags,
> class-wide objects have one, specific ones do not.

What good is a "specific" tagged object without a tag?

> your macro expansions (:-)) will probably eat even more.

The C++ versions reduce to plain arithmetic. Object sizes
are the same as the unadorned value representation.

> How big will be your application, if all possible
 > subroutines dealing with units will be instantiated?

Only the ones used get instantiated. If it turns out
that too many routines are generated, the solution is
to write a dynamic version and let the generic ones
just call the dynamic one -

template<typename Stream, typename RepType>
Stream &print(Stream &out, const RepType &value, int mass, int distance, int time)
{ /* similar to earlier version */ }
template<typename Stream, typename RepType, int Mass, int Distance, int Time>
Stream &operator<<(Stream &out, const Unit<RepType, Mass, Distance, Time> &u)
{ return print(out, u.value, Mass, Distnace, Time); }

> The moral of the story is that no real system
 > uses 100% static or 100% dynamic checks.

This is not true. Many real systems use only static checks.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Mon, 20 May 2002 13:08:16 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> > The idea of a generic is: let's substitute A for X
> > and see if the compiler will eat that.
>
>In the same way that a procedure is: let's substitute
>V for P and see if the compiler will eat that.

Not the compiler, but CPU. A substitution happens at run time. But the
main difference is how fine you can specify what can be substituted.
For subroutines we have the whole type system to specify that. Now
consider generics. Presently it is a very restricted set of formal
generic types that is supported. At the same time they match almost
everything.

>Clearly,
>you dislike generics so you invent extra-linguistic
>nomenclature to claim that one language construct is
>within the language while another is not.

I claim that, because, everything can be made generic. In C++ there
are generic types and subroutines. In Ada there are generic packages.
One can easily invent generic variables, literals, if-then-else or
whatsoever. Generics are alien to the language. One need them only
when the type system is underdeveloped.

>> Because dimensioned values are not unrelated. Their types are
>> siblings, having a common supertype, and very often we need objects of
>> that supertype.
>
>Why is a kilometer at all related to an hour?
>Why do they need a common supertype?

Because, there is a gauge that can show both. Because there is a data
base which is able to store measures with their dimensions, etc.

>>  an unconstrainted subtype of Measure shall keep the
>> discriminant, while a constrained one shall not. Same with tags,
>> class-wide objects have one, specific ones do not.
>
>What good is a "specific" tagged object without a tag?

Why a specific object should have a tag? It is specific, so its tag is
*statically* known. Keeping its tag is wasting resources. One reason
why this might be needed is re-dispatch, which itself is very
suspicious. Another is: if specific objects are relatively big and
passed by reference, then it makes no difference to have tag in them.

>> your macro expansions (:-)) will probably eat even more.
>
>The C++ versions reduce to plain arithmetic. Object sizes
>are the same as the unadorned value representation.

Yes, as long plain arithmetic is all what you do. If you start to
develop a real system upon generic units, you will have to make all
subroutines dealing with generic measurements also generic. The impact
will be catastrofic. Consider a generic matrix package built on
generic units. Then you start to instantiate a matrix inversion
subroutine for all sizes, units you need. Instantiate some
optimization subroutines, etc. Good luck!

>> How big will be your application, if all possible
> > subroutines dealing with units will be instantiated?
>
>Only the ones used get instantiated. If it turns out
>that too many routines are generated, the solution is
>to write a dynamic version and let the generic ones
>just call the dynamic one -

Why not to have a solution that does this from the very start?

>> The moral of the story is that no real system
> > uses 100% static or 100% dynamic checks.
>
>This is not true. Many real systems use only static checks.

How many? (:-))

I suppose we both have no figures. In automotive industry it is almost
0%. For instance, many hardware I/O protocols transfer units along
with values, so you just have no known units.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> On Mon, 20 May 2002 13:08:16 -0400, Hyman Rosen <hyrosen@mail.com>
> wrote:
>>Why is a kilometer at all related to an hour?
>>Why do they need a common supertype?
> 
> Because, there is a gauge that can show both. Because there is a data
> base which is able to store measures with their dimensions, etc.

I am sitting in front of a monitor that can display anything.
By your logic, all data types should therefore have a common
supertype. Shrug. You program in your way, and I'll program
in mine.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Tue, 21 May 2002 11:57:28 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> On Mon, 20 May 2002 13:08:16 -0400, Hyman Rosen <hyrosen@mail.com>
>> wrote:
>>>Why is a kilometer at all related to an hour?
>>>Why do they need a common supertype?
>> 
>> Because, there is a gauge that can show both. Because there is a data
>> base which is able to store measures with their dimensions, etc.
>
>I am sitting in front of a monitor that can display anything.

Compare dimensioned values and strings. The string length is not a
part of the type it is a constraint. Same is valid for dimension. Then
your logic is wrong. Your monitor CAN display anything, but it DOES
NOT. How "anything" looks like? (:-))

>By your logic, all data types should therefore have a common
>supertype. Shrug.

This is another question. The answer is yes and no. No because only
related types should have a common ancestor. Yes because in some sense
(defined by the application) all types CAN be related. Consider 'Size
attribute. It is an operation applied to any type, so there is a
common ancestor type from which they inherit it. A good language
should allow to create supertypes (common ancestors) as necessary,
because types related for one application might be unrelated for
another. If you get tired to write To_String each time you have to
convert an unbounded string to a string, define a common ancestor for
both and here you are.

>You program in your way, and I'll program
>in mine.

Absolutely no objection here.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

:  C++ templates are simply untyped, substitute'n'pray.

Is this a general statement? Out of couriosity:

template <
  class Thing,
  int a,
  int plop(Thing a)
>
int oodle(Thing b) {
  return plop(b + a);
}

class does_not_have_plus
{
public:
  int count() { return 42; }

};

int clrkpt(does_not_have_plus p) {  return p.count(); }


int main(int c)
{
  does_not_have_plus me;
  return oodle<does_not_have_plus, 9, clrkpt>(me);
}

g++ -c test.cc
test.cc: In function
	`int oodle<does_not_have_plus, 9, clrkpt>(does_not_have_plus)':
test.cc:24:   instantiated from here
test.cc:7: no match for `does_not_have_plus & + int'

So (lack of C++ template understanding on my side not withstanding)
there are cases where a prayer isn't needed?

-- Georg

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Wed, 22 May 2002 11:40:35 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>:  C++ templates are simply untyped, substitute'n'pray.
>
>Is this a general statement? Out of couriosity:
>
template <
  class Thing,
[ ... example skipped ]
>
>g++ -c test.cc
>test.cc: In function
>	`int oodle<does_not_have_plus, 9, clrkpt>(does_not_have_plus)':
>test.cc:24:   instantiated from here
>test.cc:7: no match for `does_not_have_plus & + int'
>
>So (lack of C++ template understanding on my side not withstanding)
>there are cases where a prayer isn't needed?

I did not claimed that C++ is untyped. I claimed that the formal
template parameters are untyped in the sense that you cannot say:

template <class Thing that has +,

This requirement cannot be made a part of the contract. The contract
is as simple as "any type that makes macro expansion a valid program".
It is not much better than: #define private public. So far the result
remains a valid programs it is fine! That actual has or has not plus
will be checked in C++ only after substitution. One need body to check
that! Consider that somebody has instantiated your template, but did
not use the bodies where + is used. No error, though the contract is
broken. Well, after 10 years or so, somebody would try to use that
bodies and run at misterious errors in the code which is supposed to
be safe. In Ada at least one can write:

generic
   type Thing is new Field with private; -- Field has "+"

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: 
: template <class Thing that has +,
: 
: This requirement cannot be made a part of the contract.
: [...]
:  In Ada at least one can write:
: 
: generic
:   type Thing is new Field with private; -- Field has "+"

Ah, I see, thanks for the clarification.

-- Georg

Re: Announce: Grace project site operational

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> I did not claimed that C++ is untyped. I claimed that the formal
> template parameters are untyped in the sense that you cannot say:
> 
> template <class Thing that has +,
> 
> This requirement cannot be made a part of the contract. The contract
> is as simple as "any type that makes macro expansion a valid program".

Not macro expansion, but substantially correct otherwise.

> It is not much better than: #define private public.

I don't understand what this means. If you do this inconsistently,
you are violating the rules of the language, and the result is
undefined behavior. I cannot imagine how this is related to templates.

 > So far the result
> remains a valid programs it is fine! That actual has or has not plus
> will be checked in C++ only after substitution. One need body to check
> that! Consider that somebody has instantiated your template, but did
> not use the bodies where + is used. No error, though the contract is
> broken. Well, after 10 years or so, somebody would try to use that
> bodies and run at misterious errors in the code which is supposed to
> be safe.

Once they try to use the body, the code will fail to compile.
This will not be unsafe in the sense of causing the program
to behave improperly, since it will not build at all. Meanwhile,
there will have been ten years of perfectly good and valid use.

 > In Ada at least one can write:
> generic
>    type Thing is new Field with private; -- Field has "+"

In C++, an expression like a + b can find the meaning of it's
"+" operator in many ways. There can be free functions, member
functions, and conversions involved, and circumstances dictate
using various approaches. Therefore, it is difficult, and likely
useless, for a template writer to specify some definite origin
for the operator. The only purpose will be to limit the utility
of the template.

Nevertheless, some people (like you!) want this kind of checking
anyway, and it is possible to code the checks in C++, through a
process called "concept checking". This uses template metaprogramming
to cause templates to fail to compile when instantiated with types
that fail the concept check.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Wed, 22 May 2002 12:31:05 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> It is not much better than: #define private public.
>
>I don't understand what this means. If you do this inconsistently,
>you are violating the rules of the language, and the result is
>undefined behavior. I cannot imagine how this is related to templates.

The problem is that you cannot gain very much by checking the program
against specifications alone. That is not enough, you need the body =
implementation. You might argue that it is no matter because to change
the implementation one need to recompile the whole system. But I doubt
that this another disadvantage of generics is an excuse.

> > So far the result
>> remains a valid programs it is fine! That actual has or has not plus
>> will be checked in C++ only after substitution. One need body to check
>> that! Consider that somebody has instantiated your template, but did
>> not use the bodies where + is used. No error, though the contract is
>> broken. Well, after 10 years or so, somebody would try to use that
>> bodies and run at misterious errors in the code which is supposed to
>> be safe.
>
>Once they try to use the body, the code will fail to compile.
>This will not be unsafe in the sense of causing the program
>to behave improperly, since it will not build at all.

Yes, but you should agree that for a large project that could be
unacceptable.

>Therefore, it is difficult, and likely
>useless, for a template writer to specify some definite origin
>for the operator. The only purpose will be to limit the utility
>of the template.

I agree with you but for other reason. If you can specifiy the formal
type as 

    type Thing is new Field with private;

then probably you need no generic at all. Because if declaring objects
of Thing and operations on Thing is all what you need, then
Field'Class would perfectly do the work. So my original point, if a
language has a good type system, then there is little need in
generics. Class-wide programming might supersede programming with
generics.

I strongly believe that as ADT will progress, generics will become
sort of GOTOs = use only if you really need it, once in your life.

>Nevertheless, some people (like you!) want this kind of checking
>anyway, and it is possible to code the checks in C++, through a
>process called "concept checking". This uses template metaprogramming
>to cause templates to fail to compile when instantiated with types
>that fail the concept check.

That's good, but not enough, because the semantic of the operator +
might be different. For instance, not all floating-point algorithms
are working on integers. So your program might pass the compiler and
yet be corrupt. Templates violate LSP too readily.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3CE15D0A.3050100@mail.com...
[snip]
> I first saw this idiom in _Scientific and Engineering C++_
> by Bartion & Nackman.
>
> template<typename RepType, int Mass, int Distance, int Time>
> struct Unit
> {
> RepType value;
> explicit Unit(value) : value(value) { }
> Unit operator+(Unit other)
> { return Unit(value + other.value); }
> Unit operator-(Unit other)
> { return Unit(value - other.value); }
> };
[snip]

Didn't someone post an Ada units package similar to
this a while back (> 1 year)?..

Re: Announce: Grace project site operational

[Stephen Leake]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:

> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:3CE15D0A.3050100@mail.com...
> [snip]
> > I first saw this idiom in _Scientific and Engineering C++_
> > by Bartion & Nackman.
> >
> > template<typename RepType, int Mass, int Distance, int Time>
> > struct Unit
> > {
> > RepType value;
> > explicit Unit(value) : value(value) { }
> > Unit operator+(Unit other)
> > { return Unit(value + other.value); }
> > Unit operator-(Unit other)
> > { return Unit(value - other.value); }
> > };
> [snip]
> 
> Didn't someone post an Ada units package similar to
> this a while back (> 1 year)?..

Yes, there are several similar Ada packages. But, all the Ada packages
either have run-time overhead (the Mass, Distance, Time values are
stored in the type, and computed and checked at run-time), or suffer
from combinatoric explosion of types.

The C++ template solution apparently computes and checks the Mass,
Distance, and Time values at _compile_ time, so there is no runtime
overhead. There is, in effect, the same combinatoric explosion of
types (actually operators in this case), but it is handled
automatically by the compiler, thru implicit instantiation (is that
the right term?). And only those operators that are actually used are
ever declared, and the _user_ only has to write the templates, not
the instantiations.

This is pretty neat. One area where C++ templates are superior to Ada
generics (as others have been saying all along :). 

-- 
-- Stephe

Re: Announce: Grace project site operational

[Darren New]

Stephen Leake wrote:
> or suffer
> from combinatoric explosion of types.

Can someone explain why a combinatoric explosion of types is bad in this
case? I mean, considering that you only have to declare them once? I can
even see a preprocessor generating the Ada declarations from some simple
description of what to call the different combinations (such as
area=length*length).

I mean, is it inherently bad that Ada represents a combinatoric
explosion of types in the real world with a combinatoric explosion of
declarations? And if so, why is it bad? Is it just the compilation
overhead?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Announce: Grace project site operational

[Hyman Rosen]

Darren New wrote:
> Can someone explain why a combinatoric explosion of types is bad

Several reasons. First of all, someone has to write them. Second,
the set of possible units is infinite, so declaring all of the
types and operations is impossible; you can only declare the
subset that you think anyone will ever need, and if you're wrong,
the extra ones will have to be done by the users. Third, it feels
inelegant to have to do this - in the real world, units systems
such as SI consist only of a small number of fundamental units
and all the rest are composed of those. One would hope that this
could be captured by the programming.

Re: Announce: Grace project site operational

[Darren New]

Hyman Rosen wrote:
> 
> Darren New wrote:
> > Can someone explain why a combinatoric explosion of types is bad
> 
> Several reasons. First of all, someone has to write them. Second,
> the set of possible units is infinite, so declaring all of the
> types and operations is impossible; you can only declare the
> subset that you think anyone will ever need, and if you're wrong,
> the extra ones will have to be done by the users. Third, it feels
> inelegant to have to do this - in the real world, units systems
> such as SI consist only of a small number of fundamental units
> and all the rest are composed of those. One would hope that this
> could be captured by the programming.

Well, it does just seem to me pretty trivial to write a program that
takes something like

=distance
=time
velocity=distance/time
area=distance*distance
volume=distance*distance*distance

and turn such a file into the appropriate set of Ada type and function
declarations, whether it's 50 lines or 5000 lines, that when "with"ed
and "used" could make for safe unit conversions. You need another unit?
Add it to the file and regenerate the Ada. I mean, basically, isn't this
what the C++ compiler is doing with the templates, except only creating
those combinations you use?

Of course, it could be made much more sophisticated too. 

Or don't Ada people do things like that? :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Announce: Grace project site operational

[Hyman Rosen]

Darren New wrote:
 > I mean, basically, isn't this what the C++ compiler is doing with
 > the templates, except only creating those combinations you use?

Except that templates are an integral part of the C++ language,
while your generator is making up for a deficiency in Ada.

Re: Announce: Grace project site operational

[Darren New]

Hyman Rosen wrote:
> 
> Darren New wrote:
>  > I mean, basically, isn't this what the C++ compiler is doing with
>  > the templates, except only creating those combinations you use?
> 
> Except that templates are an integral part of the C++ language,
> while your generator is making up for a deficiency in Ada.

Yes? So? This *is* comp.lang.ada, isn't it?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Announce: Grace project site operational

[Brian Rogoff]

On Thu, 16 May 2002, Darren New wrote:
> Hyman Rosen wrote:
> >
> > Darren New wrote:
> >  > I mean, basically, isn't this what the C++ compiler is doing with
> >  > the templates, except only creating those combinations you use?
> >
> > Except that templates are an integral part of the C++ language,
> > while your generator is making up for a deficiency in Ada.
>
> Yes? So? This *is* comp.lang.ada, isn't it?

Of course, but in general the Ada community is supposed to frown on the
use of macros and generator is just a fancy word for macro system in this
context.

I think it's fair to discuss the C++ way, and perceived deficiencies of
the Ada way, since one can imagine a future Ada derived language with some
form of automatic instantiation. I'd certainly find such a language
attractive, as one of the biggest annoyances IMO with highly generic
libraries is the instantiation overhead. Of course, I'm even more biased
on this topic than I was a few years ago, as my current pet language
(*not* C++! :) provides a fair amount of type inference and I like it.

-- Brian

Re: Announce: Grace project site operational

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Well, it does just seem to me pretty trivial to write a program that
> takes something like
> 
> =distance
> =time
> velocity=distance/time
> area=distance*distance
> volume=distance*distance*distance
> 
> and turn such a file into the appropriate set of Ada type and function
> declarations, whether it's 50 lines or 5000 lines, that when "with"ed
> and "used" could make for safe unit conversions. 

I agree, it could be done. Please do it! 

> You need another unit? Add it to the file and regenerate the Ada. I
> mean, basically, isn't this what the C++ compiler is doing with the
> templates, 

Yes.

> except only creating those combinations you use?

I think this is critical. In a complex system, the Ada code you
generate will be huge, and could have an impact on compilation time.
GNAT's 'pragma Elaborate' and 'gnatelim' could be used to trim the
Units package after the system is built. It would be useful to do the
experiment and find out if this is worth it.

However, my personal belief is that units should be checked at
algorithm design time, which I prefer to do in Macsyma or Mathematica
for any moderately complex system. So I don't need the Ada code to
also check the units.

I guess if I had the 'Auto_Unit_Package', I might skip the Macsyma
step for more programs. Hmm.

> Of course, it could be made much more sophisticated too.

In what way?

> Or don't Ada people do things like that? :-)

Well, I have done something sort of like that, with Auto_Text_IO
(http://users.erols.com/leakstan/Stephe/Ada/auto_text_io.html). This
package automatically generates Text_IO Put and Get for record and
array types; something that is tedious to do by hand, but useful for
unit testing, and therefore a good candidate for automation.

Also, I believe parts of the GNAT compiler are tool-generated.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Darren New]

Stephen Leake wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > Well, it does just seem to me pretty trivial to write a program that
> > takes something like
> >
> > =distance
> > =time
> > velocity=distance/time
> > area=distance*distance
> > volume=distance*distance*distance
> >
> > and turn such a file into the appropriate set of Ada type and function
> > declarations, whether it's 50 lines or 5000 lines, that when "with"ed
> > and "used" could make for safe unit conversions.
> 
> I agree, it could be done. Please do it!

I don't think I know Ada well enough, actually. There's probably all
kinds of subtleties I'd miss in what's needed.  Maybe if nobody does it
by the time I'm done my current contract work, I'll take a shot at it.
I'll bring it up again when I'm free and ask for suggestions.

> > except only creating those combinations you use?
> 
> I think this is critical. In a complex system, the Ada code you
> generate will be huge, and could have an impact on compilation time.

Fair enough. It would seem odd to me that a template (which you're
basically going to recompile every time you compile any C++ code, isn't
that how it works?) is going to compile faster than simply "with"ing
something you've already compiled. Of course, if you add a unit, then
you're going to wind up recompiling a bunch of Ada stuff you probably
don't really need to compile. So it's not obvious to me at least that on
average it's such a loss.

I would certainly think a sufficiently sophisticated compiler *could*
eliminate all the overhead in the final code. Indeed, I could imagine a
tool that builds two bodies, one where all the units are properly
organized, and another where they're all the same type.

> I guess if I had the 'Auto_Unit_Package', I might skip the Macsyma
> step for more programs. Hmm.

Sure. It might not be appropriate for really big programs, but if the
point of Grace is to make simple packages to get people more interested
in the power of Ada, a units package like this could be good.
 
> > Of course, it could be made much more sophisticated too. 
> In what way?

Adding scaling, like "kilo" and "centi" and such, just as an example. 

Dealing with things like "area=length*length*length" as another example.

> > Or don't Ada people do things like that? :-)
> Well, I have done something sort of like that, with Auto_Text_IO
> Also, I believe parts of the GNAT compiler are tool-generated.

And much of the GUI work is code-generated, isn't it?

(As you can tell, I haven't used Ada enough to have done any largish
program in it. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Announce: Grace project site operational

[Hyman Rosen]

Darren New wrote:
> Fair enough. It would seem odd to me that a template (which you're
> basically going to recompile every time you compile any C++ code, isn't
> that how it works?) is going to compile faster than simply "with"ing
> something you've already compiled.

For some compilers, "with"ing a package means reading the source
of the package specification, which is no different than C++
reading the template definition.

Re: Announce: Grace project site operational

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > 
> > Darren New <dnew@san.rr.com> writes:
> > > Of course, it could be made much more sophisticated too. 
> > In what way?
> 
> Adding scaling, like "kilo" and "centi" and such, just as an example. 

That's just another unit, although I suppose some automated support
for it might be nice.

> Dealing with things like "area=length*length*length" as another
> example.

Yes, we'd want to define secondary types in terms of primary types.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Darren New]

Stephen Leake wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > Stephen Leake wrote:
> > >
> > > Darren New <dnew@san.rr.com> writes:
> > > > Of course, it could be made much more sophisticated too.
> > > In what way?
> >
> > Adding scaling, like "kilo" and "centi" and such, just as an example.
> 
> That's just another unit, although I suppose some automated support
> for it might be nice.

I was thinking more like saying
kilo=1000
and automatically getting kilograms, kilometers, kilomiles, etc.

Also
foot=0.3*meter
or some such, and then automatically getting foot/second from meter/second.

> > Dealing with things like "area=length*length*length" as another
> > example.
> 
> Yes, we'd want to define secondary types in terms of primary types.

area=length*length is easy. volume=length*length*length is harder, because
you would need to automatically generate the intermediate type involved in
the volume. I.e., if "area" weren't defined, how would you define operator
"*"(l,r : length)?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Announce: Grace project site operational

[Fraser Wilson]

Darren New <dnew@san.rr.com> writes:

> area=length*length is easy. volume=length*length*length is harder, because
> you would need to automatically generate the intermediate type involved in
> the volume. I.e., if "area" weren't defined, how would you define operator
> "*"(l,r : length)?

The short answer is that you make sure you do define area.  I restrict
new dimensions to a maximum of two base dimensions; though you can
have more than one way of constructing them; e.g.

    Energy in Joules is Force * Length or Power * Time;

but you can't say Acceleration is Length / Time / Time, for the reason
you mention above.

Here's why I love Ada: given definitions for length, area in terms of
length and volume in terms of length and area, you can multiply three
lengths together and automagically have a volume return type.  I
suspect that much more of this sort of carrying on will make the
compiler run noticeably slower though.

Fraser.

Re: Announce: Grace project site operational

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> I was thinking more like saying
> kilo=1000
> and automatically getting kilograms, kilometers, kilomiles, etc.

hmm. I'd stick to explicitly requested types. The point of the
autogenerated package is to keep it as small as possible.

> Also foot=0.3*meter or some such, and then automatically getting
> foot/second from meter/second.

No non-SI please :). Actually, there's no reason for the Auto_Unit
tool to restrict the names of the types in any way.

I don't think I'd use something like 'foot = 0.3 * meter', but I can
see some applications might want it.

> > > Dealing with things like "area=length*length*length" as another
> > > example.
> > 
> > Yes, we'd want to define secondary types in terms of primary types.
> 
> area=length*length is easy. volume=length*length*length is harder, because
> you would need to automatically generate the intermediate type involved in
> the volume. I.e., if "area" weren't defined, how would you define operator
> "*"(l,r : length)?

Good point. I would have automatically generated type names like
"Meters_Squared", and define "Area" as a subtype of Meters_Squared.
Then Volume is a subtype of Meters_Cubed. That way, you get the user's
secondary units defined in terms of the user's primary units.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Marin David Condic]

Is it time for someone to put together a draft spec expressing at least a
small handful of units, etc as a proposal for Grace.SI_Units? I'd be curious
as to what some of these ideas would look like in an actual implementation -
it might get another branch of the Grace project rolling...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ulmai24cx.fsf@gsfc.nasa.gov...
>
> Yes, we'd want to define secondary types in terms of primary types.
>

Re: Announce: Grace project site operational

[Fraser Wilson]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Darren New <dnew@san.rr.com> writes:
> 
> > Well, it does just seem to me pretty trivial to write a program that
> > takes something like
> > 
> > =distance
> > =time
> > velocity=distance/time
> > area=distance*distance
> > volume=distance*distance*distance
> > 
> > and turn such a file into the appropriate set of Ada type and function
> > declarations, whether it's 50 lines or 5000 lines, that when "with"ed
> > and "used" could make for safe unit conversions. 
> 
> I agree, it could be done. Please do it! 

Well, I happened to have some tools lying around that make writing
this sort of thing really easy, so I knocked together a prototype this
afternoon.  It takes definitions like "unit Length in Metres",
"Velocity is Length / Time" and "Force in Newtons is Mass *
Acceleration".  The result is an Ada package with a bunch of type X is
new Float declarations and all the given operations implemented (using
pragma Inline; maybe Intrinsic works too).

Unfortunately, there's a wee problem with magnitude changes; say I add
the following:

   function "*" (Left : Float; Right : Metres) return Metres;

Then for M : Metres, M := 2.0 * M is ambiguous, because of Standard."*"

What's more, Standard."*" has no meaning in this domain, but there's
no way (as far as I know) of getting rid of it.

If I don't define a magnitude changing function, then M := 2.0 * M
works, but M := F * M doesn't (for F : Float).

The way to fix all this would be to make the types private, and supply
conversion functions.  I've always found that ugly though.

Fraser.

Re: Announce: Grace project site operational

[Stephen Leake]

Fraser Wilson <newsfraser@blancolioni.org> writes:

> Well, I happened to have some tools lying around that make writing
> this sort of thing really easy, so I knocked together a prototype this
> afternoon.  It takes definitions like "unit Length in Metres",
> "Velocity is Length / Time" and "Force in Newtons is Mass *
> Acceleration".  The result is an Ada package with a bunch of type X is
> new Float declarations and all the given operations implemented (using
> pragma Inline; maybe Intrinsic works too).

Great! I'd like to see it. Are your tools (or at least the final tool)
open source?

> Unfortunately, there's a wee problem with magnitude changes; say I
> add the following:
> 
>    function "*" (Left : Float; Right : Metres) return Metres;

Don't use Float. Make the base float type a generic, so I can
instantiate it with my own float type. That allows me to choose single
or double precision, etc.

And 'Metres' is spelled 'Meter'
(http://physics.nist.gov/cuu/Units/units.html).

Hmm, not sure whether I like the plural here or not. And my personal
standard would require 'Meter_Type', but I'm willing to relax that for
this package.

> Then for M : Metres, M := 2.0 * M is ambiguous, because of
> Standard."*"
> 
> What's more, Standard."*" has no meaning in this domain, but there's
> no way (as far as I know) of getting rid of it.

You are correct that we need these "scaling" operators. I remember
this problem now (I did start down this road once, a long time ago :).
However, I don't mind saying

M := Float_Type'(2.0) * M;

The whole point is to be clear about units; bare numbers need to be
qualified with the appropriate unit type, even if it is unitless.

> If I don't define a magnitude changing function, then M := 2.0 * M
> works, but M := F * M doesn't (for F : Float).

Right, not good.

> The way to fix all this would be to make the types private, and
> supply conversion functions. I've always found that ugly though.

Right, even worse! You lose literals for all the types.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Fraser Wilson]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Great! I'd like to see it. Are your tools (or at least the final tool)
> open source?

No, they're Free software. ;-)

> Don't use Float. Make the base float type a generic, so I can
> instantiate it with my own float type. That allows me to choose single
> or double precision, etc.

The final output will of couse be generics; there's a reason why the 
examples aren't but it's not interesting enough to talk about.

> And 'Metres' is spelled 'Meter'
> (http://physics.nist.gov/cuu/Units/units.html).

It's true, but I've been engaged in a one-person rearguard action against 
the official spelling of 'sulphur' for, oh, fifteen years now; I'd feel
silly if I gave up on metres.

In any case, the definition file is short and straightforward and easy
to change.

> Hmm, not sure whether I like the plural here or not. And my personal
> standard would require 'Meter_Type', but I'm willing to relax that for
> this package.

Meter_Type is also good.  It's easy to adjust the specification file.
My personal preference is to avoid the use of the word "type" in
types, but I'm certainly not religious.

I'll try to make something available over the weekend.

Fraser.

Re: Announce: Grace project site operational

[Stephen Leake]

Fraser Wilson <newsfraser@blancolioni.org> writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> > Great! I'd like to see it. Are your tools (or at least the final tool)
> > open source?
> 
> No, they're Free software. ;-)

Hmm. I guess you mean I can get the executables but not the source? Or
maybe I'm reading too much into this ...

> > Don't use Float. Make the base float type a generic, so I can
> > instantiate it with my own float type. That allows me to choose
> > single or double precision, etc.
> 
> The final output will of couse be generics; there's a reason why the 
> examples aren't but it's not interesting enough to talk about.

Ok, using Float for playing around with tool design is fine.

> > And 'Metres' is spelled 'Meter'
> > (http://physics.nist.gov/cuu/Units/units.html).
> 
> It's true, but I've been engaged in a one-person rearguard action against 
> the official spelling of 'sulphur' for, oh, fifteen years now; I'd feel
> silly if I gave up on metres.
> 
> In any case, the definition file is short and straightforward and easy
> to change.

Right. I just realized that the tool should allow me to use any unit I
want, so this discussion is moot.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Simon Wright]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> And 'Metres' is spelled 'Meter'
> (http://physics.nist.gov/cuu/Units/units.html).

Maybe in America (well, probably that should be USA). Even so I
suspect you would spell 'Metres' as 'Meters' :-)

A google search finds loads of reasonably authoritative-sounding
references, eg http://www.nwml.gov.uk/consumer/si.asp -- and even some
US ones too, http://grumpy.as.arizona.edu/~gschwarz/unitstandards.html

Re: Announce: Grace project site operational

[Mark Biggar]

Fraser Wilson wrote:
 
> Unfortunately, there's a wee problem with magnitude changes; say I add
> the following:
> 
>    function "*" (Left : Float; Right : Metres) return Metres;
> 
> Then for M : Metres, M := 2.0 * M is ambiguous, because of Standard."*"
> 
> What's more, Standard."*" has no meaning in this domain, but there's
> no way (as far as I know) of getting rid of it.
> 
> If I don't define a magnitude changing function, then M := 2.0 * M
> works, but M := F * M doesn't (for F : Float).
> 
> The way to fix all this would be to make the types private, and supply
> conversion functions.  I've always found that ugly though.

No, your problem is not with Standard."*", it is with the implicit
definition of 'function "*"(Left, Right: Metres) return Metres' that
you get when you defined the type Metres.  Ada 95 provides a way to
turn off such implicit definitions like so:

type Metres is new Float;
-- kill unwanted ops
function "*"(Left, Right: Metres) return Metres is abstract;
function "/"(Left, Right: Meters) return Metres is abstract;
-- define wanted ops
function "*"(Left, Right: Metres) return Area;
function "*"(Left: Float, Right: Metres) return Metres;
-- ...

--
Mark Biggar
mark.a.biggar@attbi.com

Re: Announce: Grace project site operational

[Fraser Wilson]

Mark Biggar <mark.a.biggar@attbi.com> writes:

> No, your problem is not with Standard."*", it is with the implicit
> definition of 'function "*"(Left, Right: Metres) return Metres' that
> you get when you defined the type Metres.

My bad; sloppy terminology.

> Ada 95 provides a way to
> turn off such implicit definitions like so:
> 
> type Metres is new Float;
> -- kill unwanted ops
> function "*"(Left, Right: Metres) return Metres is abstract;
> function "/"(Left, Right: Meters) return Metres is abstract;
> -- define wanted ops
> function "*"(Left, Right: Metres) return Area;
> function "*"(Left: Float, Right: Metres) return Metres;

This doesn't resolve the ambiguity of

   X : Metres;
   X := 2.0 * X;

... it just prevents you from compiling a program that makes an 
unambiguous call to the unwanted operations.

Fraser.

Re: Announce: Grace project site operational

[Stephen Leake]

Fraser Wilson <newsfraser@blancolioni.org> writes:

> Mark Biggar <mark.a.biggar@attbi.com> writes:
> 
> > Ada 95 provides a way to
> > turn off such implicit definitions like so:
> > 
> > type Metres is new Float;
> > -- kill unwanted ops
> > function "*"(Left, Right: Metres) return Metres is abstract;
> > function "/"(Left, Right: Meters) return Metres is abstract;
> > -- define wanted ops
> > function "*"(Left, Right: Metres) return Area;
> > function "*"(Left: Float, Right: Metres) return Metres;
> 
> This doesn't resolve the ambiguity of
> 
>    X : Metres;
>    X := 2.0 * X;
> 
> ... it just prevents you from compiling a program that makes an 
> unambiguous call to the unwanted operations.

Which is essential, so the tool should declare these abstract
operations. 

-- 
-- Stephe

Re: Announce: Grace project site operational

[Mark Biggar]

Fraser Wilson wrote:
> 
> Mark Biggar <mark.a.biggar@attbi.com> writes:
> 
> > No, your problem is not with Standard."*", it is with the implicit
> > definition of 'function "*"(Left, Right: Metres) return Metres' that
> > you get when you defined the type Metres.
> 
> My bad; sloppy terminology.
> 
> > Ada 95 provides a way to
> > turn off such implicit definitions like so:
> >
> > type Metres is new Float;
> > -- kill unwanted ops
> > function "*"(Left, Right: Metres) return Metres is abstract;
> > function "/"(Left, Right: Meters) return Metres is abstract;
> > -- define wanted ops
> > function "*"(Left, Right: Metres) return Area;
> > function "*"(Left: Float, Right: Metres) return Metres;
> 
> This doesn't resolve the ambiguity of
> 
>    X : Metres;
>    X := 2.0 * X;
> 
> ... it just prevents you from compiling a program that makes an
> unambiguous call to the unwanted operations.

Yes it does.  The above is ambiguous because it can't decide between

(1) function "*"(L,R: Metres) return Metres;

and

(2) function "*"(L: Float, R: Metres) return Metres;

But a abstract function in not callable and the overloading
resolution in the compiler will therefor not consider it a valid
option and thus pick (2) of the above functions.  The whole
reason why Ada 95 allows direct declarations of abstract functions
of non-tagged types is to provide a way to kill off unwanted operations
like (1) above.  See the discussion in the Rational.


--
Mark Biggar
mark.a.biggar@attbi.com

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On 17 May 2002 17:03:39 +0200, Fraser Wilson
<newsfraser@blancolioni.org> wrote:

>Unfortunately, there's a wee problem with magnitude changes; say I add
>the following:
>
>   function "*" (Left : Float; Right : Metres) return Metres;
>
>Then for M : Metres, M := 2.0 * M is ambiguous, because of Standard."*"
>
>What's more, Standard."*" has no meaning in this domain, but there's
>no way (as far as I know) of getting rid of it.

Override it with abstract. It is possible for non-tagged types. Here
is how it is made in my implementation of units:

with Interfaces;

package Units is
   pragma Pure (Units);
   subtype UnitPower is Interfaces.Unsigned_32;
   type Unit is new UnitPower;

   function "**" (Left : Unit; Right : Integer) return Unit;
   function "*"  (Left, Right : Unit) return Unit;
   function "/"  (Left, Right : Unit) return Unit;
   function Sqrt (X : Unit) return Unit;
   pragma Inline ("**", "*", "/", Sqrt);
   function Image
            (  Value  : Unit;
               Latin1 : Boolean := True
            )  return String;
   --
   -- The following operations are disallowed.
   --
   function "abs" (      Right : Unit) return Unit is abstract;
   function "and" (Left, Right : Unit) return Unit is abstract;
   function "mod" (Left, Right : Unit) return Unit is abstract;
   function "not" (      Right : Unit) return Unit is abstract;
   function "or"  (Left, Right : Unit) return Unit is abstract;
   function "rem" (Left, Right : Unit) return Unit is abstract;
   function "xor" (Left, Right : Unit) return Unit is abstract;

   function "+" (Right : Unit) return Unit is abstract;
   function "-" (Right : Unit) return Unit is abstract;

   function "+" (Left, Right : Unit) return Unit is abstract;
   function "-" (Left, Right : Unit) return Unit is abstract;

private
   PowerBits    : constant := (UnitPower'Size - 1) / 7;
   Current      : constant := 2**(PowerBits*0);
   Luminescence : constant := 2**(PowerBits*1);
   Temperature  : constant := 2**(PowerBits*2);
   Mass         : constant := 2**(PowerBits*3);
   Length       : constant := 2**(PowerBits*4);
   Quantity     : constant := 2**(PowerBits*5);
   Time         : constant := 2**(PowerBits*6);
   Unitless     : constant := 0;
end Units;

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Hyman Rosen]

Stephen Leake wrote:
> The C++ template solution apparently computes and checks the Mass,
> Distance, and Time values at _compile_ time, so there is no runtime
> overhead. There is, in effect, the same combinatoric explosion of
> types (actually operators in this case), but it is handled
> automatically by the compiler, thru implicit instantiation (is that
> the right term?). And only those operators that are actually used are
> ever declared, and the _user_ only has to write the templates, not
> the instantiations.

Correct, in all respects. Furthermore, because the operations
are so simple and can be declared inline, the explosion is only
within the compiler (and perhaps the symbol table). The actual
code will contain only simple arithmetic, just as if there were
no units at all.

In a real implementation, there would also be operators to
allow multiplication and division by scalars, and scaled units
are just handled by multiplication:

typedef Unit<double, 1, 0, 0> Mass;
const Mass gram = Mass(1);
const Mass kilogram = 1000 * gram;
const Mass pound = 2.2 * kilogram;

Other posters have been mentioning fractional units. The C++
approach could accomodate this either by having the base unit
be the least common multiple of all the roots (i.e., if you
need meter^1/2 and meter^1/3 you could work in meter^1/6 and
use powers of that) or by using rationals for the powers (so
instead of Unit<Mass> you can have Unit<MassN,MassD>; the
arithmetic can all still be done in the compiler, not at
runtime).

Re: Announce: Grace project site operational

[tmoran]

> template<typename RepType, int Mass, int Distance, int Time>
> ...
  The attempt below is is not as nice as "type Velocity is new Float
dimension Distance/Time;" and it needs parenthesization, but it works in
Ada 95.  Each new unit requires a "type unit is <real type>" and each
legal pair needs two lines:  a generic instantiation and a "use".

generic
  type left is digits <>;
  type right is digits <>;
  type result is digits <>;
package multiply is
  function "*"(a : left; b : right) return result;
  function "*"(a : right; b : left) return result;
end multiply;
package body multiply is
  function "*"(a : left; b : right) return result is
  begin return result(float(a)*float(b));end "*";
  function "*"(a : right; b : left) return result is
  begin return result(float(a)*float(b));end "*";
end multiply;

generic
  type left is digits <>;
  type right is digits <>;
  type result is digits <>;
package ratio is
  function "/"(a : left; b : right) return result;
end ratio;
package body ratio is
  function "/"(a : left; b : right) return result is
  begin return result(float(a)/float(b));end "/";
end ratio;

with Multiply,Ratio;
procedure try_d is

  type Seconds is new Float;
  type Centimeters is new Float;
  type Grams is digits 4;

  type Velocity is new Float;
  package Centimeters_per_Second is new Ratio(Centimeters, Seconds, Velocity);
  use Centimeters_per_Second;

  type Acceleration is new Float;
  package Velocity_per_Second is new Ratio(Velocity, Seconds, Acceleration);
  use Velocity_per_Second;

  type Dynes is new Float;
  package Grams_Acceleration is new Multiply(Grams, Acceleration, Dynes);
  use Grams_Acceleration;

  t : Seconds;
  d : Centimeters range 0.0 .. 100.0;
  v : Velocity;
  m : Grams;
  a : Acceleration;
  f : Dynes;
  x,y,z : Float;

begin
  v := d/t;
  a := v/t;
  f := m*a;
  f := m*(v/t);
  x := float(d)*float(t);
  y := d*t;                    -- line 35, erroneous
  z := float(d*t);             -- line 36, erroneous
end try_d;

gnatchop/gnatmake gives:
gcc -c try_d.adb
try_d.adb:35:09: invalid operand types for operator "*"
try_d.adb:35:09: left operand has subtype of "centimeters" defined at line 22
try_d.adb:35:09: right operand has type "Seconds" defined at line 5
try_d.adb:36:15: invalid operand types for operator "*"
try_d.adb:36:15: left operand has subtype of "centimeters" defined at line 22
try_d.adb:36:15: right operand has type "Seconds" defined at line 5
gnatmake: "try_d.adb" compilation error

Re: Announce: Grace project site operational

[Stephen Leake]

tmoran@acm.org writes:

> > template<typename RepType, int Mass, int Distance, int Time>
> > ...
>   The attempt below is is not as nice as "type Velocity is new Float
> dimension Distance/Time;" and it needs parenthesization, but it works in
> Ada 95.  Each new unit requires a "type unit is <real type>" and each
> legal pair needs two lines:  a generic instantiation and a "use".

You left out the "pragma Inline". We don't want code bloat from this :).

The error messages look fairly nice.

Next time I do a physics-based system, I think I'll try the
automatically generated Units package approach. Could be some time
next year, given my current schedule.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Martin Dowie]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uu1p8ciey.fsf@gsfc.nasa.gov...
> You left out the "pragma Inline". We don't want code bloat from this :).

what about "pragma Import (Intrinsic, ...);"! :-)

Re: Announce: Grace project site operational

[tmoran]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

> > Constant = (C1*C2)/(C3^0.5)  = mol�/mol^0.5 = mol^(3/2)
>
> oops forgot to say that Constant is alway unitless as one divides by the
  You would certainly still be able to do explicit type conversions
in the normal way for cases where "dimension ..." doesn't work.
  I would imagine an implementation where "type t ... dimension a * b" would
create a data structure (a_power=>1, b_power=>1, others=>0) so a real type
without a "dimension" part would be (others=>0) implicitly.  As to
fractional powers, how common are arbitrary fractions?  Would it be
reasonable to do:
  type root_mol is ...
  type mol is ... dimension root_mol * root_mol;

>    CO2 (g)  = CO2 (aq)
>
>    Constant = atm/(mol/l)
  As a former math major who thought chemists mathematical barbarians,
I confess ignorance of what you mean here. ;)

Re: Announce: Grace project site operational

[Preben Randhol]

On Tue, 14 May 2002 19:10:13 GMT, tmoran@acm.org wrote:

>I said: 
>>    CO2 (g)  = CO2 (aq)
>>
>>    Constant = atm/(mol/l)

Oops wrong way should be (mol/l)/atm or bar.

>   As a former math major who thought chemists mathematical barbarians,
> I confess ignorance of what you mean here. ;)

K = C(CO2(aq))/P(CO2(g))

hrmf, you chemistry babarian ;-))

Preben

Re: Announce: Grace project site operational

[Jeffrey Carter]

Marin David Condic wrote:
> 
> Been there. Done that. Got the t-shirt. The problem is coming up with a
> guideline or some other sort of rule of thumb that offers constructive
> advice (especially to the beginner) as to when creating more types isn't
> really helpful. It really is a kind of an "art".

This is part of design, and design should not be performed by beginners.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: Announce: Grace project site operational

[Preben Randhol]

On Sat, 11 May 2002 19:42:09 GMT, Jeffrey Carter wrote:
> Marin David Condic wrote:
>> 
>> Been there. Done that. Got the t-shirt. The problem is coming up with a
>> guideline or some other sort of rule of thumb that offers constructive
>> advice (especially to the beginner) as to when creating more types isn't
>> really helpful. It really is a kind of an "art".
> 
> This is part of design, and design should not be performed by beginners.

Oh, yes I know this. I have rewritten parts of my program several times
as I learn more and more about Ada. But how much you learn by doing
mistakes :-). At least one rule I have found very useful is to write the
.ads files first as much as possible as this forces you to think through
the specs. Of course this is quite obvious, but some much more
motivating to do when one have learned the hard way. ;-)

Preben
-- 

Re: Announce: Grace project site operational

[Jeffrey Carter]

I've taken a look at the unbounded list package, and think there should
be a couple of changes:

The imported type Element should have the "=" operation imported for it.

The "=" operations for types List and Iterator should be visible to
clients of the package.

I was interested in seeing the implementation of the "safe" positions
(type Iterator) and was surprised to find that the Remove operation in
the sample implementation does not check for other positions designating
the same node in the list. I see no point in the extra complexity if
it's not used.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: Announce: Grace project site operational

[Ted Dennison]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CDD75C7.36C6ADCF@acm.org>...
> The imported type Element should have the "=" operation imported for it.
> 
> The "=" operations for types List and Iterator should be visible to
> clients of the package.

I'd like to see more discussion on this point. The way I remember it,
we didn't want to add a lot of generic parameters that >%99 of the
time would not be used. I can't remember overloading "=" myself, ever.
This goes back to the "default generic parameters" issue, but I
digress. However, I seem to remember some folks saying that not
importing "=" this way causes the built-in equality to reassert itself
even after its been overridden. Am I remembering this correctly?

> I was interested in seeing the implementation of the "safe" positions
> (type Iterator) and was surprised to find that the Remove operation in
> the sample implementation does not check for other positions designating
> the same node in the list. I see no point in the extra complexity if
> it's not used.

I haven't looked at it lately, but that sounds like something that it
should be doing. The information required to do it is certianly there.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Marin David Condic]

I'd like to think that the Lists package should be considered basically done
(from a specification point of view.) It needs an implementation and test
procedures and then some possible review in light of experience to decide if
the interface should be revisited for minor tweaks. From this point, there
ought to be some kind of prototyping/discussion about a Maps package.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205130744.2602e251@posting.google.com...
>
> I'd like to see more discussion on this point. The way I remember it,
> we didn't want to add a lot of generic parameters that >%99 of the
> time would not be used. I can't remember overloading "=" myself, ever.
> This goes back to the "default generic parameters" issue, but I
> digress. However, I seem to remember some folks saying that not
> importing "=" this way causes the built-in equality to reassert itself
> even after its been overridden. Am I remembering this correctly?
>

Re: Announce: Grace project site operational

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Jeffrey Carter <jrcarter@acm.org> wrote in message
> news:<3CDD75C7.36C6ADCF@acm.org>...
> > The imported type Element should have the "=" operation imported for it.
> > 
> > The "=" operations for types List and Iterator should be visible to
> > clients of the package.
> 
> I'd like to see more discussion on this point. 

Before we have more discussion, I'd like to make sure there is a
mechanism for capturing the resultant decision and rationale in a
useful way, so we don't have to do it again next year :).

For example, a design and rational document for Grace would be good.

Now I'll start another controversy; do it in LaTeX :).

Actually, I think texinfo is good for Gnu projects. Some seem to be
using DocBook, which I've never used.

Of course, flat ASCII isn't bad!

-- 
-- Stephe

Re: Announce: Grace project site operational

[Preben Randhol]

On 13 May 2002 13:10:12 -0400, Stephen Leake wrote:
> 
> Now I'll start another controversy; do it in LaTeX :).

LaTeX is good yes. DocBook isn't good enough (for me at least) as it
lacks support for equations.

If you use Linux you can also use LyX to writeh LaTeX documents with:

   http://www.lyx.org

> Actually, I think texinfo is good for Gnu projects. Some seem to be
> using DocBook, which I've never used.

I like texinfo too as it is so nice to be able to search through a whole
document using info.

Preben

Re: Announce: Grace project site operational

[Marin David Condic]

ASCII is a wonderful thing. It captures all the information you need (unless
you need some kind of graphics) and it is easily transformed into anything
you like. I'd suggest that if anything is captured, it just be kept in plain
text until things settle out enough to decide it needs a more sophisticated
format. Otherwise, the whole thing could get bogged down in superficial
format issues when the important part is just capturing the information.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uznz4nfd7.fsf@gsfc.nasa.gov...
>
> Of course, flat ASCII isn't bad!
>

Re: Announce: Grace project site operational

[Ted Dennison]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uznz4nfd7.fsf@gsfc.nasa.gov>...
> Before we have more discussion, I'd like to make sure there is a
> mechanism for capturing the resultant decision and rationale in a
> useful way, so we don't have to do it again next year :).

Dang, that makes good sense. It needs to be up on the website
somewhere to, so we can point people who want to reopen old wounds to
it.

> For example, a design and rational document for Grace would be good
                            ^^^^^^^^
                            rationale.
I'm the worst person in here to be dissin' on someone else's spelling,
but this one always rubs me the wrong way. Sorry.

> Now I'll start another controversy; do it in LaTeX :).
> 
> Actually, I think texinfo is good for Gnu projects. Some seem to be
> using DocBook, which I've never used.

From what I understand about it, I'd be inclined to pick texinfo
(which I understand is a flavor of TeX) out of the choices you have
above. It is the official Gnu doc system, so that's what all the Gnu
tools are set up to use. Also, it provides for producing both HTML and
typeset versions. Apparently it can be processed by TeX proceesors
too.

Note that no-one would deal with the texinfo documentation "sources"
directly, unless they are updating them. Readers would use either the
generated HTML versions, or some ready-for-printing format like
Postscript or Acrobat.

> Of course, flat ASCII isn't bad!
I'd go for HTML before that, just to get a little formatting.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Announce: Grace project site operational

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:<uznz4nfd7.fsf@gsfc.nasa.gov>...
> 
> > For example, a design and rational document for Grace would be good
>                             ^^^^^^^^
>                             rationale.
> I'm the worst person in here to be dissin' on someone else's spelling,
> but this one always rubs me the wrong way. Sorry.

It bugs me too :). But I don't run a spell checker on email or news
(wouldn't have caught this anyway). And I try to tone down my personal
checker, since I know I make mistakes too. Life is too short ...

> > Now I'll start another controversy; do it in LaTeX :).
> > 
> > Actually, I think texinfo is good for Gnu projects. Some seem to be
> > using DocBook, which I've never used.
> 
> From what I understand about it, I'd be inclined to pick texinfo
> (which I understand is a flavor of TeX) out of the choices you have
> above. It is the official Gnu doc system, 

Apparently that's true: http://www.gnu.org/prep/standards.html#SEC33
I had not realized that before.

> so that's what all the Gnu tools are set up to use. Also, it
> provides for producing both HTML and typeset versions. Apparently it
> can be processed by TeX proceesors too.

Using the Gnu program 'makeinfo', you can produce html, info, or TeX
output. If you produce TeX, you can then use the 'tex' program to
produce PDF, PS, or other 'hardcopy' formats. 'info' is an old
hyperlinked format (oldest I'm aware of); the best reader for it is
Emacs. 

> Note that no-one would deal with the texinfo documentation "sources"
> directly, unless they are updating them. Readers would use either
> the generated HTML versions, or some ready-for-printing format like
> Postscript or Acrobat.

Yes. I recommend PDF; the latest version has 'bookmarks', which are
like an always-visible, interactive table of contents.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Preben Randhol]

On 14 May 2002 12:00:06 -0400, Stephen Leake wrote:
> Using the Gnu program 'makeinfo', you can produce html, info, or TeX
> output. If you produce TeX, you can then use the 'tex' program to
> produce PDF, PS, or other 'hardcopy' formats. 'info' is an old
> hyperlinked format (oldest I'm aware of); the best reader for it is
> Emacs. 

Or plain info which has improved a lot over old horrible versions.

Preben

-- 
"Jeg tror nordmenn har glemt hvordan de tilbreder fisk. De er mest
 opptatt av firkantet fisk."
  --  Kristian Kristiansen, yrkesfisker, aftenposten.no 19/04/02

Re: Announce: Grace project site operational

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CDD75C7.36C6ADCF@acm.org>...
> > The imported type Element should have the "=" operation imported for it.
> >
> > The "=" operations for types List and Iterator should be visible to
> > clients of the package.
> 
> I'd like to see more discussion on this point. The way I remember it,
> we didn't want to add a lot of generic parameters that >%99 of the
> time would not be used. I can't remember overloading "=" myself, ever.
> This goes back to the "default generic parameters" issue, but I
> digress. However, I seem to remember some folks saying that not
> importing "=" this way causes the built-in equality to reassert itself
> even after its been overridden. Am I remembering this correctly?

Yes. For this to be a general-purpose package, it should work correctly
if the client has a user-defined "=" for the actual type used for
Element. Since the package does use "=" for this type (in "=" for List),
it must be imported to work properly.

Luckily, we can default subprograms ("is <>"), so this adds no
additional burden to the instantiation for most users.

Since types List and Iterator are private, we are telling the client
that "=" for these types is meaningful. Since the predefined "="s for
these types are not meaningful, that means the client must have
visibility to the package-defined versions. Currently these versions are
declared in the private part of the package, so the client does not have
visibility to them. They should be moved to the visible part of the
specification so the client may call them.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Announce: Grace project site operational

[Simon Wright]

dennison@telepath.com (Ted Dennison) writes:

> Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CDD75C7.36C6ADCF@acm.org>...
> > The imported type Element should have the "=" operation imported for it.
> > 
> > The "=" operations for types List and Iterator should be visible to
> > clients of the package.
> 
> I'd like to see more discussion on this point. The way I remember it,
> we didn't want to add a lot of generic parameters that >%99 of the
> time would not be used. I can't remember overloading "=" myself, ever.
> This goes back to the "default generic parameters" issue, but I
> digress. However, I seem to remember some folks saying that not
> importing "=" this way causes the built-in equality to reassert itself
> even after its been overridden. Am I remembering this correctly?

I'm not so sure about "=" for Iterator. However, the BCs have users
who require Element to have overridden equality (and yes, you do need
to import, or default equality does reemerge).

The specific example was where equality only depended on some of the
fields (you could change other fields without affecting equality).

The same user wanted to be able to refefine equality for map Keys.

Re: Announce: Grace project site operational

[Richard Riehle]

Larry Hazel wrote:

> I remember starting in the middle of an Ada 83 project.  There was a separate
> type defined for everything.  An old Elvis song kept going through my head.  But
> instead of "girl happy", I was substituting "type happy".

I remember a project where the integer types were defined,

          type Int_8 is range -2**7..2**7-1;
          for Int_8'Size use 8;
          type Int_16 ...
          for Int_16'Size ...
          type Int_32 ...
          for Int_32'Size ...

Richard Riehle

Re: Announce: Grace project site operational

[Marc A. Criley]

Richard Riehle wrote:
> 
> I remember a project where the integer types were defined,
> 
>           type Int_8 is range -2**7..2**7-1;
>           for Int_8'Size use 8;
>           type Int_16 ...
>           for Int_16'Size ...
>           type Int_32 ...
>           for Int_32'Size ...

Remember?  They're still here.  And not only the above, but virtually
every integer type in the system is declared as a subtype of one of
these.

Sorta misses the point, eh?

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: Announce: Grace project site operational

[Hyman Rosen]

Ted Dennison wrote:
> I'm not sure I understand either the question or the suppossed problem. 
> The only way you could possibly get different types back for a size 
> operation would be if there *were* such a generic parameter.

In one of those long philosophy threads (I think it's the strong
typing one), someone said that one of Ada's strengths is that you
can have separate types for counting separate things, so that you
cannot accidentally mix up the counts. He referred to counting
apples and counting apple cart pushers. So if this is considered
important, then the container generics ought to have a count type
parameter for counting how many members they have. Otherwise, if
they just return a generic integer, and you have an AppleCounter,
you would have to convert the result. But then you could as easily
convert the count of an AppleCartPusherList to an AppleCounter, so
you would lose that automatic safety. So I was wondering if the
GRACE lists had such a parameter.

The original poster also said that C++ programmers tend to dismiss
things like this as not useful enough to bother with, even though
they can put together classes that could simulate such separate
integer types. I'm a C++ programmer, and I agree with that, so I
thought I would just strew some more complication into the path of
the GRACE lists for the Ada programmers who do care :-)

Re: Announce: Grace project site operational

[Larry Kilgallen]

In article <3CD94E63.3050607@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:

> The original poster also said that C++ programmers tend to dismiss
> things like this as not useful enough to bother with, even though
> they can put together classes that could simulate such separate
> integer types. I'm a C++ programmer, and I agree with that, so I
> thought I would just strew some more complication into the path of
> the GRACE lists for the Ada programmers who do care :-)

And as an Ada programmer, I thank you for that diligence.
I have a lot of "count" types in a program I am working on
currently, and I would appreciate it if packages provided
that, in the spirit of Ada.

And I understand that the spirit of C++ might be different.

Re: Announce: Grace project site operational

[Marin David Condic]

I see the usefulness of different numeric types coming into play with items
that have very distinct usages. For example, if I get data from a pressure
transducer and a temperature sensor and an RPM sensor and they were all 16
bit integers, I would want to make sure I didn't accidentally mix them up
because they all represent very different things with different units, etc.
There, I'd want separate types. But for a counter or index where typically
all I want to do is "for X in 1..Data_Structure_Size loop" I don't see a lot
of food value to be had by making all those unique types.

I'd be hard pressed to come up with a rule as to when it requires a separate
type and when it can use one of the predefined types. It sort of feels like
"art" to me. I'd suggest that it gains importance as the numbers in question
get closer to modeling something in the "real world". The closer it gets to
"internal housekeeping", the less interest I have in creating unique types
for it.

Of course strong typing has more to do than just avoiding the mixing of
numeric types. Think of arrays and records as well as parameter passing,
etc., where you get considerable protection from the type system against
mixing things up that shouldn't get confused.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:TP7CiYvFfPBT@eisner.encompasserve.org...
> In article <3CD94E63.3050607@mail.com>, Hyman Rosen <hyrosen@mail.com>
writes:
>
> And as an Ada programmer, I thank you for that diligence.
> I have a lot of "count" types in a program I am working on
> currently, and I would appreciate it if packages provided
> that, in the spirit of Ada.
>
> And I understand that the spirit of C++ might be different.

Re: Announce: Grace project site operational

[Larry Kilgallen]

In article <abbmhs$e39$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> I see the usefulness of different numeric types coming into play with items
> that have very distinct usages. For example, if I get data from a pressure
> transducer and a temperature sensor and an RPM sensor and they were all 16
> bit integers, I would want to make sure I didn't accidentally mix them up
> because they all represent very different things with different units, etc.
> There, I'd want separate types. But for a counter or index where typically
> all I want to do is "for X in 1..Data_Structure_Size loop" I don't see a lot
> of food value to be had by making all those unique types.
> 
> I'd be hard pressed to come up with a rule as to when it requires a separate
> type and when it can use one of the predefined types. It sort of feels like
> "art" to me. I'd suggest that it gains importance as the numbers in question
> get closer to modeling something in the "real world". The closer it gets to
> "internal housekeeping", the less interest I have in creating unique types
> for it.

Is there no way a generic type parameter can have a default value ?

Re: Announce: Grace project site operational

[Marin David Condic]

The only way I know of doing it is: "type Some_Type is range <> ;" It sure
would be handy to be able to say "Unless otherwise directed, make it
Natural..." in which case there is no problem. You get Natural unless you
need it to be something else. (Actually, I'd like to be able to have generic
parameters that let you imply that the actual was going to be ordinal or
scalar so you could assume it would have relational operators or
mathematical operators and thus not have to bring in all the operators or
have separate packages for things like floating point, fixed point, decimal,
integer, modular, enumerated... But that's another complaint. :-)

My reason for not wanting to parameterize that aspect is that you then have
to ask "Where do we stop?" Couldn't there be all sorts of other aspects of
the package that might possibly benefit from having special types? Maybe not
with lists, but then you've got maps and whatever else comes along next.
Once you let the toothpaste out of the tube, its awful hard to get it back
in.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:w1dYrjaH4ynM@eisner.encompasserve.org...
>
> Is there no way a generic type parameter can have a default value ?

Re: Announce: Grace project site operational

[Ted Dennison]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<w1dYrjaH4ynM@eisner.encompasserve.org>...
> Is there no way a generic type parameter can have a default value ?

Not a *type* parameter, no. Perhaps this is something that should be
looked at for the next Ada revision?

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

RE: Announce: Grace project site operational

[Mário Amado Alves]

"Is there no way a generic type parameter can have a default value ?"
(LK)

"Not a *type* parameter, no. Perhaps this is something that should be
looked at for the next Ada revision?" (TED)

Hmmm... This is the essence of a previous thread initiated by myself on
'types as objects', which, if I remember correctly, lead to reflexion
with an example from an ASIS application. The subject dropped silently
then, so I should guess no, it will not make it into the next Ada
revision.

--MAA

Re: Announce: Grace project site operational

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

M�rio Amado Alves wrote in message ...
>"Is there no way a generic type parameter can have a default value ?"
>(LK)
>
>"Not a *type* parameter, no. Perhaps this is something that should be
>looked at for the next Ada revision?" (TED)
>
>Hmmm... This is the essence of a previous thread initiated by myself on
>'types as objects', which, if I remember correctly, lead to reflexion
>with an example from an ASIS application. The subject dropped silently
>then, so I should guess no, it will not make it into the next Ada
>revision.

Supporting default parameters for generic types would be (I think) a
whole lot simpler than 'types as objects'. Ada has default parameters
for generic subprogram parameters, why not types?

Something like:

    type Count is (<>) use Natural;

seems like it would work. Probably worth thinking about a bit. (Warning:
I have made no effort to think about the ramifications of this idea!!)

            Randy.

Re: Announce: Grace project site operational

[Marin David Condic]

That's O.K. Its a trial baloon. If nobody ever floats a new idea for fear of
being called stupid or because they have not worked out every possible
detail, then not many ideas will get floated. Tossing it out there might
stimulate some other creative souls to come up with even better ideas. If
nothing else, you can find out if anyone likes the idea.

Would you want to use something more like:

type Count is range <> use Natural ;

.... thus insisting that the formal and the default have the same
characteristics? Although, I'd probably want to also be able to supply any
default type that minimally satisfied the requirements of the formal, so
maybe it needs a lot of syntax variations.

How about:

type defining_identifier [discriminant] is formal_type_definition [=>
default_type] ;

As in:

type Count is range <> => Natural ;

That is a little more like the formal => actual association you can have at
the instantiation.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:udllen75oc322b@corp.supernews.com...
>
> Something like:
>
>     type Count is (<>) use Natural;
>
> seems like it would work. Probably worth thinking about a bit. (Warning:
> I have made no effort to think about the ramifications of this idea!!)
>

Re: Announce: Grace project site operational

[Hyman Rosen]

Once again, I begin with a caveat that I am a C++ and
not an Ada programmer, so forgive me if I'm talking
through my hat.

I am thinking that it would also be useful to allow generic
formal packages to have a default value, and moreover, to
allow this default value to be a new instantiation of a
generic, most likely using preceding generic parameters.
It seems to me that this would incorporate a flavor of C++'s
template style of traits classes and automatic instantiation
while still preserving the actual Ada style of explicit
generic instantiation.

Re: Announce: Grace project site operational

[Preben Randhol]

On Fri, 10 May 2002 09:06:43 -0400, Hyman Rosen wrote:
> Once again, I begin with a caveat that I am a C++ and
> not an Ada programmer, so forgive me if I'm talking
> through my hat.
> 
> I am thinking that it would also be useful to allow generic
> formal packages to have a default value, and moreover, to
> allow this default value to be a new instantiation of a
> generic, most likely using preceding generic parameters.
> It seems to me that this would incorporate a flavor of C++'s
> template style of traits classes and automatic instantiation
> while still preserving the actual Ada style of explicit
> generic instantiation.
> 

I don't see what you gain by this?

-- 
"Jeg tror nordmenn har glemt hvordan de tilbreder fisk. De er mest
 opptatt av firkantet fisk."
  --  Kristian Kristiansen, yrkesfisker, aftenposten.no 19/04/02

Re: Announce: Grace project site operational

[Hyman Rosen]

Preben Randhol wrote:
> I don't see what you gain by this?

If the instantiated package which is passed as the generic
formal package is usually but not always instantiated with
a subset of the arguments used to instantiate the generic
itself, it could be useful to allow the generic formal to
default to a new instantiation of the usual case.

In C++, for example, the standard containers all take an
allocator class as a generic parameter, and this allocator
class is usually, but not always, an instantiation of a
standard generic allocator class on the type of the object
the container will hold. It looks something like this -

template< typename ElementType,
	  typename Allocator = DefaultAllocator< ElementType >
	 >
class Vector { /* ... */ };

Most of the time, you just use Vector<mytype> and let the
allocator default, and sometimes you provide your own special
purpose one.

Re: Announce: Grace project site operational

[Randy Brukardt]

Marin David Condic wrote in message ...
>That's O.K. Its a trial baloon. If nobody ever floats a new idea for
fear of
>being called stupid or because they have not worked out every possible
>detail, then not many ideas will get floated. Tossing it out there
might
>stimulate some other creative souls to come up with even better ideas.
If
>nothing else, you can find out if anyone likes the idea.

I'm not shy about trial ballons. However, given this is a public forum,
and I'm the editor of the Amendment to Ada 95, I have to be careful
about making the implication that something will be in Ada 0y. Or that
this is a good idea. I don't want people depending on my trial ballons.

                Randy.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Thu, 9 May 2002 15:02:47 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>Supporting default parameters for generic types would be (I think) a
>whole lot simpler than 'types as objects'. Ada has default parameters
>for generic subprogram parameters, why not types?
>
>Something like:
>
>    type Count is (<>) use Natural;
>
>seems like it would work. Probably worth thinking about a bit. (Warning:
>I have made no effort to think about the ramifications of this idea!!)

We already have two different words for IS: "is" and ":=", "use" would
be a third one. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Randy Brukardt]

Dmitry A. Kazakov wrote in message ...
>On Thu, 9 May 2002 15:02:47 -0500, "Randy Brukardt"
><randy@rrsoftware.com> wrote:
>
>>Supporting default parameters for generic types would be (I think) a
>>whole lot simpler than 'types as objects'. Ada has default parameters
>>for generic subprogram parameters, why not types?
>>
>>Something like:
>>
>>    type Count is (<>) use Natural;
>>
>>seems like it would work. Probably worth thinking about a bit.
(Warning:
>>I have made no effort to think about the ramifications of this idea!!)
>
>We already have two different words for IS: "is" and ":=", "use" would
>be a third one. (:-))

I know from past discussions that the ARG really does not want repeated
reserved words in the syntax. So,

    type Count is (<>) is Natural;

is out. ":=" applies to objects, not types, and I don't think we want to
make types look like objects. "use" is used to mean "is" in
representation clauses already, so it seems to be the logical candidate.
But there may be a better syntax.

            Randy.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Fri, 10 May 2002 14:00:50 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>Dmitry A. Kazakov wrote in message ...
>>On Thu, 9 May 2002 15:02:47 -0500, "Randy Brukardt"
>><randy@rrsoftware.com> wrote:
>>
>>>Supporting default parameters for generic types would be (I think) a
>>>whole lot simpler than 'types as objects'. Ada has default parameters
>>>for generic subprogram parameters, why not types?
>>>
>>>Something like:
>>>
>>>    type Count is (<>) use Natural;
>>>
>>>seems like it would work. Probably worth thinking about a bit.
>(Warning:
>>>I have made no effort to think about the ramifications of this idea!!)
>>
>>We already have two different words for IS: "is" and ":=", "use" would
>>be a third one. (:-))
>
>I know from past discussions that the ARG really does not want repeated
>reserved words in the syntax. So,
>
>    type Count is (<>) is Natural;
>
>is out. ":=" applies to objects, not types, and I don't think we want to
>make types look like objects.

I am not so sure. I think that "type Count is (<>);" is logically
flawed. Here (<>) is a class of types, so Count is an object of this
"type type".Thus it would be natural to have:

Count : (<>) := Natural;

A similar thing could be done with subprograms. And of course, we
should have subprogram types! At least to reduce use of nasty
access-to-subprogram objects.

> "use" is used to mean "is" in
>representation clauses already, so it seems to be the logical candidate.
>But there may be a better syntax.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Ted Dennison]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<gc1ndukgsts9ake0le6q9ot8s4a3l1l2hn@4ax.com>...

> We already have two different words for IS: "is" and ":=", "use" would
> be a third one. (:-))

I always thought of ":=" as "gets" rather than "is". If it were "is",
then

 A := 2;
 B := 10;
 A := B;


Ought to pull some kind of exception. Perhaps something like
"non_euclidian_geometry". :-)

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On 10 May 2002 12:35:45 -0700, dennison@telepath.com (Ted Dennison)
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<gc1ndukgsts9ake0le6q9ot8s4a3l1l2hn@4ax.com>...
>
>> We already have two different words for IS: "is" and ":=", "use" would
>> be a third one. (:-))
>
>I always thought of ":=" as "gets" rather than "is". If it were "is",
>then
>
> A := 2;
> B := 10;
> A := B;
>
>Ought to pull some kind of exception. Perhaps something like
>"non_euclidian_geometry". :-)

Actually I didn't mean assignment. I thought about initialization:

X : constant Integer := 2;

which is an equivalent [alas, incomplete with regard of tagged types
(:-()] to

function X return Integer is
begin
   return 2;
end X;

That could be:

X : constant function return Integer :=
begin
   return 2;
end X;

(:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

RE: Announce: Grace project site operational

[Mário Amado Alves]

"Supporting default parameters for generic types would be (I think) a
whole lot simpler than 'types as objects'."

Probably simpler w.r.t. Ada evolution strictly, yes. I stand corrected.

--MAA

Re: Announce: Grace project site operational

[Simon Wright]

dennison@telepath.com (Ted Dennison) writes:

> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<w1dYrjaH4ynM@eisner.encompasserve.org>...
> > Is there no way a generic type parameter can have a default value ?
> 
> Not a *type* parameter, no. Perhaps this is something that should be
> looked at for the next Ada revision?

Nor a variable in-out object parameter: I wanted to supply a default
object of type Root_Storage_Pool'Class -- no way I could see.

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On 9 May 2002 06:54:09 -0700, dennison@telepath.com (Ted Dennison)
wrote:

>Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<w1dYrjaH4ynM@eisner.encompasserve.org>...
>> Is there no way a generic type parameter can have a default value ?
>
>Not a *type* parameter, no. Perhaps this is something that should be
>looked at for the next Ada revision?

Talking about next revisions and default values, there is another
problem with them. How to make a default value private? Let I have
some value declared in the private part and I don't want to expose it
in the public part. Then there will be no way to use it as a default
value in any public thing.

Another problem is that there is no way to publicly instantiate
generics with some private object as the actual parameter. [Of course
the generic shall refer the corresponding formal parameter in the
private part and the body only.] It would be nice to have some sort of
incomplete generic instantiation, completed in the private part.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[John English]

"Dmitry A. Kazakov" wrote:
> 
> Talking about next revisions and default values, there is another
> problem with them. How to make a default value private? Let I have
> some value declared in the private part and I don't want to expose it
> in the public part. Then there will be no way to use it as a default
> value in any public thing.

Can't you use a deferred constant for your default value?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Tue, 14 May 2002 16:03:52 +0100, John English <je@brighton.ac.uk>
wrote:

>"Dmitry A. Kazakov" wrote:
>> 
>> Talking about next revisions and default values, there is another
>> problem with them. How to make a default value private? Let I have
>> some value declared in the private part and I don't want to expose it
>> in the public part. Then there will be no way to use it as a default
>> value in any public thing.
>
>Can't you use a deferred constant for your default value?

It will be visible then! I want not only hide the implementation, but
the very fact that such object exists. Let I have a type with some
reserved values which no user-declared variable or parameter may have.
Like "null" for pointers. Yet some subroutines could have these secret
values as defaults for some parameters. A simple work-around is just
to make several overloaded subroutines from them, which is clumsy.

However, the main argument is not how often one would require that,
but that the information hidding principle is not fully supported for
default values of all sorts [parameters, discriminants].

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[John English]

"Dmitry A. Kazakov" wrote:
> 
> On Tue, 14 May 2002 16:03:52 +0100, John English <je@brighton.ac.uk>
> wrote:
> 
> >"Dmitry A. Kazakov" wrote:
> >>
> >> Talking about next revisions and default values, there is another
> >> problem with them. How to make a default value private? Let I have
> >> some value declared in the private part and I don't want to expose it
> >> in the public part. Then there will be no way to use it as a default
> >> value in any public thing.
> >
> >Can't you use a deferred constant for your default value?
> 
> It will be visible then! I want not only hide the implementation, but
> the very fact that such object exists. Let I have a type with some
> reserved values which no user-declared variable or parameter may have.
> Like "null" for pointers. Yet some subroutines could have these secret
> values as defaults for some parameters. A simple work-around is just
> to make several overloaded subroutines from them, which is clumsy.

Hmm, if I understand what you're saying, you don't want people to
know there is a default at all (i.e. you don't want to mention it
in the visible spec). What is really wrong with something like:

  type Magic_Type is private;
  Default_Value : constant Magic_Type;
  procedure Foo (Magic : Magic_Type := Default_Value);

which tells you that the parameter can be omitted because there's
a default, but you have no idea what the default actually is?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Announce: Grace project site operational

[Dmitry A. Kazakov]

On Wed, 15 May 2002 11:38:39 +0100, John English <je@brighton.ac.uk>
wrote:

>"Dmitry A. Kazakov" wrote:
>> 
>> On Tue, 14 May 2002 16:03:52 +0100, John English <je@brighton.ac.uk>
>> wrote:
>> 
>> >"Dmitry A. Kazakov" wrote:
>> >>
>> >> Talking about next revisions and default values, there is another
>> >> problem with them. How to make a default value private? Let I have
>> >> some value declared in the private part and I don't want to expose it
>> >> in the public part. Then there will be no way to use it as a default
>> >> value in any public thing.
>> >
>> >Can't you use a deferred constant for your default value?
>> 
>> It will be visible then! I want not only hide the implementation, but
>> the very fact that such object exists. Let I have a type with some
>> reserved values which no user-declared variable or parameter may have.
>> Like "null" for pointers. Yet some subroutines could have these secret
>> values as defaults for some parameters. A simple work-around is just
>> to make several overloaded subroutines from them, which is clumsy.
>
>Hmm, if I understand what you're saying, you don't want people to
>know there is a default at all (i.e. you don't want to mention it
>in the visible spec). What is really wrong with something like:
>
>  type Magic_Type is private;
>  Default_Value : constant Magic_Type;
>  procedure Foo (Magic : Magic_Type := Default_Value);
>
>which tells you that the parameter can be omitted because there's
>a default, but you have no idea what the default actually is?

Consider:

   type Graph_Node is private;
   No_Node : constant Graph_Node; -- Deferred, but visible
   function Get_Next_Child
      (Parent : Graph_Node; Child : Graph_Node := No_Node)
         return Graph_Node;

Here I exposed No_Node, which then can be abused like:

   Get_Next_Child (No_Node);

A solution could be some sort of incomplete declaration for
subprograms:

   type Graph_Node is private;
   function Get_Next_Child
      (Parent : Graph_Node; Child : Graph_Node := <>)
         return Graph_Node;

private
   type Graph_Node is ...;
   No_Node : constant Graph_Node := ...;
   function Get_Next_Child
      (Parent : Graph_Node; Child : Graph_Node := No_Node)
         return Graph_Node;

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Announce: Grace project site operational

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> Consider:
> 
>    type Graph_Node is private;
>    No_Node : constant Graph_Node; -- Deferred, but visible
>    function Get_Next_Child
>       (Parent : Graph_Node; Child : Graph_Node := No_Node)
>          return Graph_Node;
> 
> Here I exposed No_Node, which then can be abused like:
> 
>    Get_Next_Child (No_Node);

Ok. Presumably they'd get an exception, but you'd like all error
checking to be done at compile time; that makes sense.

> A solution could be some sort of incomplete declaration for
> subprograms:
> 
>    type Graph_Node is private;
>    function Get_Next_Child
>       (Parent : Graph_Node; Child : Graph_Node := <>)
>          return Graph_Node;
> 
> private
>    type Graph_Node is ...;
>    No_Node : constant Graph_Node := ...;
>    function Get_Next_Child
>       (Parent : Graph_Node; Child : Graph_Node := No_Node)
>          return Graph_Node;

This is interesting. You'll have problems with instantiating generics
with incomplete program declarations, and probably other things :).

Since you _can_ get the same effect with overloaded subprograms in
current Ada, I think you'll just have to live with that.

-- 
-- Stephe

Re: Announce: Grace project site operational

[Wes Groleau]

> There, I'd want separate types. But for a counter or index where typically
> all I want to do is "for X in 1..Data_Structure_Size loop" I don't see a lot
> of food value to be had by making all those unique types.

And actually, in this one case you can't: the
loop control variable is  implicitly declared
by the loop statement and its type implied by
the rest of the statement.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Announce: Grace project site operational

[Marin David Condic]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CDA81B3.9BAC8C8D@despammed.com...
>
> And actually, in this one case you can't: the
> loop control variable is  implicitly declared
> by the loop statement and its type implied by
> the rest of the statement.
>
Good point! I always forget that one spot where Ada does implicit
declaration of an object.

Anyway, I think you can see what I mean by not having a lot of food value to
create a special type for every counter or index or flag that might be used
in coding-up some operation. I'd rather use strong typing for reflecting
things in the real world or where its important in creating an abstraction
of the problem. Insisting on providing a type for the count of the number of
elements in a list is likely to make it unpopular with users who are
thinking "Look, all I want is a list of the couple of hundred records I'm
piling up and I want to know how many of them I've got and I don't want to
have to keep telling you "Natural" at every instance that I need a list..."
I could be persuaded otherwise, but I'd have to see how it might make some
big difference in practical usage to make it worth the extra effort.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Announce: Grace project site operational

[William C. Brennan]

On Wed, 8 May 2002 12:31:44 -0400, Larry Kilgallen wrote
(in message <TP7CiYvFfPBT@eisner.encompasserve.org>):

> In article <3CD94E63.3050607@mail.com>, Hyman Rosen <hyrosen@mail.com> 
> writes:
> 
> And as an Ada programmer, I thank you for that diligence.
> I have a lot of "count" types in a program I am working on
> currently, and I would appreciate it if packages provided
> that, in the spirit of Ada.
> 

For my own personal preference, I have to weigh in with Larry here.  
In the "spirit of Ada" (oh, it feels good to wrap one's self in the flag ;-)) I use a 
unique type for whatever I'm counting: electrons, meters, apple-pushcarts, apples, 
or "items".  In fact, it still disappoints me (slightly) that the Ada 83 language 
team failed to create String indexed by its own Character_Index type.

I'm a little surprised to hear, at least as sampled in this tiny forum, that so many
Ada fans are quick to give up the same benefits for counting objects 
as they are for counting things with more traditionally defined units.  It has always 
given me a nice fuzzy feeling that I know I can't accidentally substitue number_of_apple_
carts for number_of_apples in exactly the same way I feel secure that I can't subsititute 
seconds for hours.  It never felt like "overkill" to me, and I don't think this philosophy
leads to an explosion of unique types.  Using Integer (and its sisters Natural and
Positive) just absolutely reeks of C's int, and I avoid it whenever I can.  Of course,
I use Strings, so I can't avoid it as much as I would like. ;-)
It's my style - no not just mine... it's the Ada style. ;-)  (So have I shamed the 
rest of you into it yet?)

So, anyway, it would be nice if the container packages didn't force me to use Natural to
count my apple_carts when I don't wouldn't use this type myself.  It would be a *small* 
inconvenience to specify the counting type as the actual generic parameter.


-- 
Bill Brennan
brennan@netaxs.com

Re: Announce: Grace project site operational

[Ted Dennison]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CD94E63.3050607@mail.com>...
> In one of those long philosophy threads (I think it's the strong
> typing one), someone said that one of Ada's strengths is that you

That completly explains why I missed it. :-)

> can have separate types for counting separate things, so that you
> cannot accidentally mix up the counts. He referred to counting
> apples and counting apple cart pushers. So if this is considered

OK.

> important, then the container generics ought to have a count type
> parameter for counting how many members they have. Otherwise, if

I'd say that's a bit of a stretch. In my code I find "count types"
most useful as array indices (something you *really* don't want to
mix). With the list package there's no direct indexing (currently), so
I really couldn't see myself ever making good use of such a
complication.

About the best place for this argument is with the array types that
the lists are convertable into. I think that argument had been made by
someone, but making the array index types a generic parameter was
deemed a bit too heavy for improving something that is almost
anticillary to the package already. But this issue could be always
revisited.

Take a look at the package spec in CVS and see what you think. I may
add some AdaBrowse - generated pages to the website somtime later,
time permitting.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Announce: Grace project site operational

[Hyman Rosen]

Ted Dennison wrote:
> Take a look at the package spec in CVS and see what you think.

I'm not sure that I'm qualified to comment on Ada code, but what
the heck; on the internet no one knows you're a dog :-)

Does Ada let you specify default values for generic parameters?
If it did, you could allow a count type and have it default to
Natural, which is what you use now. Otherwise, not being an Ada
programmer, I wouldn't presume to recommend a style.

By the way, I saw that you commented out the concatenator that
takes two elements and returns a list because "this might conflict".
Doesn't Ada's use of overloading by return type let you get away
with this without worrying too much? Presumably the context of the
concatenation would pick the right function. (Pardon me if I'm
rehashing an old argument; I didn't read the entire design discussion
the first time around.)

Re: Announce: Grace project site operational

[Wes Groleau]

> I'd say that's a bit of a stretch. In my code I find "count types"
> most useful as array indices (something you *really* don't want to
> mix). With the list package there's no direct indexing (currently), so

Strong typing fanatics might claim (I don't)
that indexing and counting are independent
and should have separate types.

I can remember seeing folks make the mistake
of confusing a change in temperature with
the temperature itself.  Usually, for convenience,
both have the same type.  (I have also seen
a lot of proctalgia in coding to cope with
the computations involved in making them different.

Note that Ada made the separate types choice
for the analogous situation of Duration & Time.

I once read a booklet by a person who claimed
to have been an electrical engineer at NASA.

I didn't believe it when I read how he took
"one -10" (a drop in temperature of ten degrees)
and turned it into "the other -10" (ten degrees
below freezing).

I'm rambling, but my point is that such a separation
is nearly painless if the appropriate operations
are correctly defined and transparent to the client,
but that correctly defining the operations is
difficult for many people.  Even seeing the need
for such operations is beyond the capability of
a few folks.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Announce: Grace project site operational

[Robert I. Eachus]

Wes Groleau wrote:

 
> I didn't believe it when I read how he took
> "one -10" (a drop in temperature of ten degrees)
> and turned it into "the other -10" (ten degrees
> below freezing).


The worst case resulted in the Apollo fire that killed three astronauts. 
  Two tests were combined.  One that required operation in 3 psi oxygen, 
and another that required pressurization of the command module to 3 psi 
(above the surrounding pressure) for leak testing.  The medical doctor 
who signed off on the combined test did so because all of the medical 
documentation read 3 psi oxygen, which is about the partial pressure of 
oxygen in the atmosphere.  Forget for a moment that pressurizing the 
capsule with 18 psi oxygen made it a bomb, ask your doctor what would 
happen to your lungs on 18 psi oxygen, 0% CO2, 0% H2O, 0% N2, for that 
matter 0% anything else.

In scuba diving, the partial pressure of O2 can get that high in 
"technical" diving (below 150 feet), but the usual for technical diving 
is to use a helium/oxygen mix, and keep the oxygen partial pressure to 
reasonable levels.  "Oxygen tents" in hospitals seldom go above 7 or 8 
psi oxygen partial pressure, in other words a 50/50 mix of oxygen and 
air. Mountain climbers use pure oxygen above around 20,000 feet, but 
again the absolute O2 pressure is below 3 or 4 psi.

One of the changes made subsequent to the Apollo fire was to a 50/50 
He/O2 mix.  This allowed the command capsule to be filled with the mix 
at atmospheric pressure before launch, then reduce to 5 psi (2.5 psi O2 
pp) on orbit.

Incidently I always thought that the most frightening part of the early 
spacecraft flights was taking off in a container with a hole in it to 
let the air out and hoping that the hole would close properly.  Once the 
rockets stopped firing you could do something about it, but you would 
probably be out of oxygen by then.  This is one of the things the Space 
Shuttle fixed--no venting required during the boost phase.  Along with a 
max-Q where you could do something other than holding on until the 
shaking stopped.

Yes, the astronauts are strapped in, but I mean it literally.  In 
Mercury, Gemini, and Apollo, if you didn't hold on to keep your hands 
from uncontrollably banging around at max-Q, you could damage your 
hands--and the spacecraft.  Add the pogo effect, see Apollo 6, and you 
were just glad to survive the ride. (The pogo effect resulted from 
resonances between the Saturn I structure and the pipes bringing fuel to 
the engines.  This resulted in the momentary g-forces banging back and 
forth between 0 and 10 gs or so.  On Apollo 6 it was so bad that parts 
of the lunar module adapter, which contained the LM and connected the 
command/service module to the Saturn booster fell off. The cure was to 
fill parts of the Saturn with helium before launch to change the 
resonant frequencies.)

Re: Announce: Grace project site operational

[Stephen Leake]

Ted Dennison <dennison@telepath.com> writes:

> I'm pleased to announce that the Grace project is now operational. The
> homepage is at http://www.freesoftware.fsf.org/Grace/Grace_Home.html ,
> and the main project page on the Gnu Savannah is at
> http://savannah.gnu.org/projects/grace/ .

Great! Thanks for taking the time to set this up.

> Currently, the only thing in the CVS tree is the first version of
> our Unbounded Lists package, and a reference implementation of it. 

I wrote a partial implementation of Lists.Unbounded based on SAL.
Should we find a way to get that into the Grace CVS? Or maybe just a
link to it, since we probably don't want all or part of SAL in the
Grace CVS.

There was some discussion of test code for the Lists.Unbounded
package. I strongly recommend including test code with the library, so
users that implement their own, or use it on a new platform or new
compiler have some way of knowing that it works. The test code also
serves as a more precise definition of the semantics of the package. I
can contribute the test code I have.

> I have set up a project for a Maps package, but the tasks are
> currently unassigned. Anyone who wants to help is encouraged to
> participate in the mailing lists, get a Savannah account and become
> a developer, or just hang out here and participate in the
> discussions.

I signed up on the Grace lists a couple weeks ago :).

-- 
-- Stephe

Re: Announce: Grace project site operational

[Ted Dennison]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<upu06677e.fsf@gsfc.nasa.gov>...
> I wrote a partial implementation of Lists.Unbounded based on SAL.
> Should we find a way to get that into the Grace CVS? Or maybe just a
> link to it, since we probably don't want all or part of SAL in the
> Grace CVS.

A link is probably a much better idea (in fact, it would be a pretty
good idea on its own).

I'd suggest mentioning this (with a proper URL to link to) on the
website mailing list, just to make sure the request doesn't get lost.

> There was some discussion of test code for the Lists.Unbounded
> package. I strongly recommend including test code with the library, so
> users that implement their own, or use it on a new platform or new
> compiler have some way of knowing that it works. The test code also
> serves as a more precise definition of the semantics of the package. I
> can contribute the test code I have.

There is indeed a test harness for the Lists package. The fact that it
isn't in there right now is no more than an oversight.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Announce: Grace project site operational

[fraser]

Ted Dennison <dennison@telepath.com> writes:

> I'm pleased to announce that the Grace project is now operational. The 
> homepage is at http://www.freesoftware.fsf.org/Grace/Grace_Home.html , 
> and the main project page on the Gnu Savannah is at 
> http://savannah.gnu.org/projects/grace/ .

Looks great.  Just a minor comment: I wonder if type Element_Array
wouldn't be better as an array over Positive instead of Natural.  It
fits in better with the first element going to position 1, etc.

Fraser.

Re: Announce: Grace project site operational

[Ted Dennison]

fraser@blancolioni.org wrote in message news:<ug010fnqn.fsf@FWILSON.i-did-not-set--mail-host-address--so-shoot-me>...
> Ted Dennison <dennison@telepath.com> writes:
> 
> > I'm pleased to announce that the Grace project is now operational. The 
> > homepage is at http://www.freesoftware.fsf.org/Grace/Grace_Home.html , 
> > and the main project page on the Gnu Savannah is at 
> > http://savannah.gnu.org/projects/grace/ .
> 
> Looks great.  Just a minor comment: I wonder if type Element_Array
> wouldn't be better as an array over Positive instead of Natural.  It
> fits in better with the first element going to position 1, etc.

Arg! I think I had agreed to make just that change already. If you
could submit a patch (preferably via the "patch manager") doing that,
it would help me get it done sooner. Otherwise, I'll just try to
remember to get to it this time. :-)

Another option on your part would just be to submit it as a request
via the tech support manager. That would at least make it tougher for
it to be forgotten again.

Of course I'd like to just do all the work myself. But I have other
projects, as well as 3 kids including a new baby. So the more work I
have to do on it, the longer it will probably take to get done.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html