Disallowing Pre-Defined Operations

Disallowing Pre-Defined Operations

[Charles H. Sampson]

     During the deliberations that led to Ada 95, was a mechanism for 
disallowing the pre-defined operations of a type considered?  By "disal-
lowing" I mean some way of informing the compiler that an attempt to use 
a certain pre-defined operation is a compile-time error.  Did anyone 
even ask for it?  (Obviously I didn't, even though I've thought since 
the mid-eighties that it would be a useful capability to have.)

     As an example of what I'm talking about, consider a package that 
implements three distinct floating-points types for measuring length, 
area, and volume.  The pre-defined "+" and "-" are acceptable and there 
are obvious redefinitions of "*" and "/" in some cases.  However, the 
pre-defined "/" for operands of the same type don't make sense and it 
would be nice to get a compile-time warning if one of them is used.  
Yes, a redefinition that raises an exception can be written, but that's
not the same thing.

     In the case that's bothering me at the moment, my project has a 
type called Time_Type.  (We can't be assured that Ada's built-in time 
types are adequate for our purposes.)  We've already had one fairly dif-
ficult bug because a variable of this type was used to hold the differ-
ence between two values of the type, known in our environment as a 
delta-time.  Now defining a new type Delta_Time_Type and the set of Cal- endar-like operations is no big deal, but I have no way of telling the 
compiler to flag such things as the pre-defined

          function "-" (L, R : Time_Type) return Time_Type;

and the "*", "/", and "**" operations on values of these types.

     Declaring the types as private doesn't work.  The types are inher-
ently (and obviously) numeric and nobody on my project would want to 
lose the ability to use numeric literals when appropriate.  (Every time 
this issue has popped up for me over the last 15+ years, it's been in 
the context of numeric types.)  Whenever time I come up with a way of
pluging one hole, it opens another.  For example, overloading "-" as

    function "-" (L : Time_Type; R : Float) return Delta_Time_Type;

would allow any value of type Float to be subtracted, not just literals.

     Does it tell you something about my project when I say that if the 
above definition of "-" were used, I'm sure somebody would discover the 
hole and figure out some "clever" way of exploiting it?

				Charlie

--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Disallowing Pre-Defined Operations

[Samuel T. Harris]

"Charles H. Sampson" wrote:
> 
>      During the deliberations that led to Ada 95, was a mechanism for
> disallowing the pre-defined operations of a type considered?  By "disal-
> lowing" I mean some way of informing the compiler that an attempt to use
> a certain pre-defined operation is a compile-time error.  Did anyone
> even ask for it?  (Obviously I didn't, even though I've thought since
> the mid-eighties that it would be a useful capability to have.)
> 

One could use a derived type and overload the undesired operators
to simply raise some appropriate exception. Perhaps Operation_Error.
That will give you runtime checks on "improper" usage.

As to compile time checks, one can develop an ASIS program
which hunts for the offending operators. You can even
create you own pragma to denote which operators are not
to be referenced. Other compilers may complain about
an unsupported or unrecognized pragma, but they should
allow compilation. The ASIS program can recognize such
pragmas and use them to key in on which operators
should not be used.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Disallowing Pre-Defined Operations

[Steven Hovater]

And if you're using Apex, this kind of checking is already in the tool.
It's called the "code rule checker", and is online, with source, and
can be end-user (e.g. customer)configured.

It's not automatic,however; the code rule checker would have to be
explicitly invoked, and is similar to what Mr. Harris describes.

Steve
--
Steven Hovater
svh@rational.com
Technical Representative
Phone/fax:781-676-2565/2500
Rational Software
Pager: 888-906-2209
83 Hartwell Ave, Lexington, MA
Amateur radio: AA1YH


"Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote in message
news:38C851B6.4AB3878E@Raytheon.com...
> "Charles H. Sampson" wrote:
> >
> >      During the deliberations that led to Ada 95, was a mechanism for
> > disallowing the pre-defined operations of a type considered?  By "disal-
> > lowing" I mean some way of informing the compiler that an attempt to use
> > a certain pre-defined operation is a compile-time error.  Did anyone
> > even ask for it?  (Obviously I didn't, even though I've thought since
> > the mid-eighties that it would be a useful capability to have.)
> >
>
> One could use a derived type and overload the undesired operators
> to simply raise some appropriate exception. Perhaps Operation_Error.
> That will give you runtime checks on "improper" usage.
>
> As to compile time checks, one can develop an ASIS program
> which hunts for the offending operators. You can even
> create you own pragma to denote which operators are not
> to be referenced. Other compilers may complain about
> an unsupported or unrecognized pragma, but they should
> allow compilation. The ASIS program can recognize such
> pragmas and use them to key in on which operators
> should not be used.
>
> --
> Samuel T. Harris, Principal Engineer
> Raytheon, Aerospace Engineering Services
> "If you can make it, We can fake it!"

Re: Disallowing Pre-Defined Operations

[Keith Thompson]

claveman@cod.nosc.mil (Charles H. Sampson) writes:
>      During the deliberations that led to Ada 95, was a mechanism for 
> disallowing the pre-defined operations of a type considered?  By "disal-
> lowing" I mean some way of informing the compiler that an attempt to use 
> a certain pre-defined operation is a compile-time error.  Did anyone 
> even ask for it?  (Obviously I didn't, even though I've thought since 
> the mid-eighties that it would be a useful capability to have.)

That seems like a good idea, but it would cause problems for generics.
If you forbid "*" on a floating-point type, you can't use it to
instantiate a generic that takes a floating-point formal type.  This
includes Float_IO (which very likely uses "*" and/or "/" internally).
It also introduces some conceptual problems with the built-in
attributes like 'Image and 'Value, though I suppose the language
definition could just ignore these problems.

It's too bad you can't define literals for a private type, but you can
come close by overload the unary "+" operator.  For example:

    type Time_Type is private;
    type Delta_Time_Type is private;
    function "-"(Left: Time_Type; Right: Time_Type) return Delta_Time_Type;
    function "-"(Left: Time_Type; Right: Delta_Time_Type) return Time_Type;
    -- other appropriate operations
    
    function "+"(Right: Float) return Time_Type;
    function "+"(Right: Float) return Delta_Time_Type;

You can then use:

    T : Time_Type := +123.45; -- or whatever
    T_Minus_1 : Time_Type := T - (+1.0);
    
I haven't tried compiling this, so I'm not certain it will actually
work, and I may be missing some obvious flaw.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Disallowing Pre-Defined Operations

[mark_biggar]

In article <8a9eeg$qtv$1@newpoisson.nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
>      During the deliberations that led to Ada 95, was a mechanism for
> disallowing the pre-defined operations of a type considered?
By "disal-
> lowing" I mean some way of informing the compiler that an attempt to
use
> a certain pre-defined operation is a compile-time error.  Did anyone
> even ask for it?  (Obviously I didn't, even though I've thought since
> the mid-eighties that it would be a useful capability to have.)
>
>      As an example of what I'm talking about, consider a package that
> implements three distinct floating-points types for measuring length,
> area, and volume.  The pre-defined "+" and "-" are acceptable and
there
> are obvious redefinitions of "*" and "/" in some cases.  However, the
> pre-defined "/" for operands of the same type don't make sense and it
> would be nice to get a compile-time warning if one of them is used.
> Yes, a redefinition that raises an exception can be written, but
that's
> not the same thing.
>
>      In the case that's bothering me at the moment, my project has a
> type called Time_Type.  (We can't be assured that Ada's built-in time
> types are adequate for our purposes.)  We've already had one fairly
dif-
> ficult bug because a variable of this type was used to hold the
differ-
> ence between two values of the type, known in our environment as a
> delta-time.  Now defining a new type Delta_Time_Type and the set of
Cal- endar-like operations is no big deal, but I have no way of telling
the
> compiler to flag such things as the pre-defined
>
>           function "-" (L, R : Time_Type) return Time_Type;
>
> and the "*", "/", and "**" operations on values of these types.
>
>      Declaring the types as private doesn't work.  The types are
inher-
> ently (and obviously) numeric and nobody on my project would want to
> lose the ability to use numeric literals when appropriate.  (Every
time
> this issue has popped up for me over the last 15+ years, it's been in
> the context of numeric types.)  Whenever time I come up with a way of
> pluging one hole, it opens another.  For example, overloading "-" as
>
>     function "-" (L : Time_Type; R : Float) return Delta_Time_Type;
>
> would allow any value of type Float to be subtracted, not just
literals.
>
>      Does it tell you something about my project when I say that if
the
> above definition of "-" were used, I'm sure somebody would discover
the
> hole and figure out some "clever" way of exploiting it?

Easy: just define the operator as abstract.  E.g.,:

type Length is new Integer;

function "*"(Left,Right: Length) return Length is abstract;
function "/"(Left,Right: Length) return Length is abstract;

-- now we define what we really want

function "/"(left,Right: Length) return Integer;

type Area is new Integer;

function "*"(Left,Right: Length) return Area;

-- etc.

--
Mark Biggar
mark@biggar.org


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Jean-Pierre Rosen]

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


Charles H. Sampson <claveman@cod.nosc.mil> a �crit dans le message :
8a9eeg$qtv$1@newpoisson.nosc.mil...
>      During the deliberations that led to Ada 95, was a mechanism for
> disallowing the pre-defined operations of a type considered?  By "disal-
> lowing" I mean some way of informing the compiler that an attempt to use
> a certain pre-defined operation is a compile-time error.  Did anyone
> even ask for it?  (Obviously I didn't, even though I've thought since
> the mid-eighties that it would be a useful capability to have.)

Not only was it considered - it's there.

>      As an example of what I'm talking about, consider a package that
> implements three distinct floating-points types for measuring length,
> area, and volume.  The pre-defined "+" and "-" are acceptable and there
> are obvious redefinitions of "*" and "/" in some cases.  However, the
> pre-defined "/" for operands of the same type don't make sense and it
> would be nice to get a compile-time warning if one of them is used.

function "/" (L, R : Length) return length is abstract;

(but yes, the predefined one may reappear in generics, but that's a good
thing; it allows you to use predefined math libs for example).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Disallowing Pre-Defined Operations

[Tarjei Tj�stheim Jensen]

Jean-Pierre Rosen wrote:

> Charles H. Sampson wrote:
> >      During the deliberations that led to Ada 95, was a mechanism for
> > disallowing the pre-defined operations of a type considered?  By "disal-
> > lowing" I mean some way of informing the compiler that an attempt to use
> > a certain pre-defined operation is a compile-time error.  Did anyone
> > even ask for it?  (Obviously I didn't, even though I've thought since
> > the mid-eighties that it would be a useful capability to have.)
>
> Not only was it considered - it's there.

[snip]

> function "/" (L, R : Length) return length is abstract;

That is really a workaround. I think both he and I would have preferred
something like

pragma disallow_predefined(operator => "/", a_type, a_type);
pragma disallow_predefined(operator => all, all, a_type);
pragma allow_predefined(operator => "+", a_type, a_type);
pragma map_predefined_result(result_type => integer, operator => "/", a_type,
a_type);

I think that would be more readable and a lot less work. It will of course not
work very well with a nonconforming compiler.

Greetings,

Re: Disallowing Pre-Defined Operations

[James S. Rogers]

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

Tarjei Tj�stheim Jensen wrote in message <38CA05AF.7E77790D@online.no>...
>That is really a workaround. I think both he and I would have preferred
>something like
>
>pragma disallow_predefined(operator => "/", a_type, a_type);
>pragma disallow_predefined(operator => all, all, a_type);
>pragma allow_predefined(operator => "+", a_type, a_type);
>pragma map_predefined_result(result_type => integer, operator => "/",
a_type,
>a_type);


Why not simply declare the type private or limited private, then provide
your
own versions for all the required operators?

Jim Rogers
Colorado Springs, Colorado

Re: Disallowing Pre-Defined Operations

[Tarjei T. Jensen]

James S. Rogers wrote 
>Why not simply declare the type private or limited private, then provide
>your
>own versions for all the required operators?


More work.


Greetings,

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

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

In article <38CA05AF.7E77790D@online.no>,
  "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote:

> > function "/" (L, R : Length) return length is abstract;
>
> That is really a workaround. I think both he and I would have
> preferred something like
>
> pragma disallow_predefined(operator => "/", a_type, a_type);

YECH! a pragma that makes the program illegal. Yes, it is true
there are some such pragmas, but only in very specialized
circumstances.

Note that the pragma you give is obviously incomplete, since
you have to give the full profile.

The abstract declaration is quite direct and consistent,
entirely intuitive, since it is consistent with the way
abstract works, and less typing than your horrible pragma.

I don't see why you call this a work around. It is a carefully
designed part of the language designed to achieve EXACTLY what
is being asked for, and in a manner entirely consistent with
the rest of the language design.

THe pragma would be redundant, odd, and inconsistent


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Keith Thompson]

Robert Dewar <robert_dewar@my-deja.com> writes:
[...]
> The abstract declaration is quite direct and consistent,
> entirely intuitive, since it is consistent with the way
> abstract works, and less typing than your horrible pragma.

I'm not convinced of that.  RM95-3.9.3(1) says:

    An abstract subprogram is a subprogram that has no body, but is
    intended to be overridden at some point when inherited.

What we're talking about here is a subprogram that is *not* intended
to be overridden.  The usage is guaranteed to work, but judging from
the wording in the RM I don't believe it's consistent with the
original intent.  (I'm not saying I have a better idea.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <yec4saah40n.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> The usage is guaranteed to work, but judging from
> the wording in the RM I don't believe it's consistent with the
> original intent.  (I'm not saying I have a better idea.)

It may be more reliable to judge by being there :-)

The usage for restricting use of operations as discussed in
this thread, was definitely intended!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[dmitry6243]

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

In article <38CA05AF.7E77790D@online.no>,
  "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote:
>
>
> That is really a workaround. I think both he and I would have
preferred
> something like
>
> pragma disallow_predefined(operator => "/", a_type, a_type);
> pragma disallow_predefined(operator => all, all, a_type);
> pragma allow_predefined(operator => "+", a_type, a_type);
> pragma map_predefined_result(result_type => integer, operator => "/",
a_type,
> a_type);
>
> I think that would be more readable and a lot less work. It will of
course not
> work very well with a nonconforming compiler.

I do not think that using pragmas (there are already too many of them)
is a right way. Anyway a more general solution is required. Some time
ago I proposed explicit operation hiding, something like:

package Unordered_Numbers is
   type Unordered is new Integer;

   function ">"  (Left, Right : Unordered) return Boolean is null;
   function ">=" (Left, Right : Unordered) return Boolean is null;
   function "<"  (Left, Right : Unordered) return Boolean is null;
   function "<=" (Left, Right : Unordered) return Boolean is null;
end Unordered_Numbers;

It was considered too complex to implement.

Regards,
Dmitry


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Charles H. Sampson]

James S. Rogers wrote:
>Why not simply declare the type private or limited private, then provide
>your
>own versions for all the required operators?
     
     Because, as I said in my original post, the types are inherently
numeric and I don't want to lose the ability to use numeric literals.

				Charlie



--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <8ang7v$peo$1@newpoisson.nosc.mil>,
  claveman@fern.com (Charles H. Sampson) wrote:
> James S. Rogers wrote:
> >Why not simply declare the type private or limited private,
then provide
> >your
> >own versions for all the required operators?
>
>      Because, as I said in my original post, the types are
inherently
> numeric and I don't want to lose the ability to use numeric
literals.


Exactly! quite reasonable, and that is why the easy to use
and understand ABSTRACT feature has been provided to exactly
meet your needs here.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Charles H. Sampson]

In article <8ao2mm$ib7$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <8ang7v$peo$1@newpoisson.nosc.mil>,
>  claveman@fern.com (Charles H. Sampson) wrote:
>> James S. Rogers wrote:
>> >Why not simply declare the type private or limited private,
>then provide
>> >your
>> >own versions for all the required operators?
>>
>>      Because, as I said in my original post, the types are
>inherently
>> numeric and I don't want to lose the ability to use numeric
>literals.
>
>
>Exactly! quite reasonable, and that is why the easy to use
>and understand ABSTRACT feature has been provided to exactly
>meet your needs here.

     But it doesn't exactly meet my needs, Robert.  I don't even think 
it's correct to say that it comes close to meeting my needs.  It does 
come close in the sense that if I try to use an abstract operation, most 
of the time I'll get a close to meaningful error message at compile 
time.  However it fails to exactly meet my needs by a long shot when it 
comes to concept.

     To summarize, I want some way to say that a pre-defined operation 
doesn't exist, that any attempt to write the operation is an error, just 
like attempting to write Float ** Float.  The problem with the ABSTRACT 
approach is that it actually defines the operation, making it exist, but 
declares that it is not callable.  That can give rise to ambiguities, as 
I illustrated in another post in this thread.  For what I want, there 
can't be such ambiguities because one of the two operations that play a 
role when an abstract declaration is used doesn't exist.  I want a 
situation where any user would be as puzzled as I briefly was, where he 
would say, "How can that be ambiguous?  Time_Type - Time_Type can only 
produce a Delta_Time_Type value." 

     For all I know, the abstract approach can cause problems other than 
ambiguities as well.

     The behavior of generics is even further away from what I want.  I 
haven't verified it myself yet, but several people in this thread have 
said that an abstract operation reverts to non-abstract in a generic 
instantiation.  For an operation that has been disallowed, there is 
nothing to revert to.  The programmer has told the compiler that the 
operation has no meaning.  To give it a meaning as a side effect of an 
instantiation makes no sense conceptually. 

     It might be that the units proposal that has been mentioned in this 
thread would satisfy me.  I'm going to try to check it out today.  At 
present, however, Ada is logically deficient and has been since the be-
ginning.  We are allowed to override pre-defined operations for our nu-
meric types, we are allowed to define meanings for operations that have 
no meaning, but we are not allowed to do the last logical step, to say 
that a pre-defined operation has no meaning.

				Charlie

--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <8b6gr3$5a6$1@newpoisson.nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:

> That can give rise to ambiguities, as
> I illustrated in another post in this thread.

It is possible to create such examples, but in general
I think that is a bit of a bogus argument.

For a given operation, either you want it, in which case
you define it to do what you want, overriding the default
version if it is not what you want, or you define it as
abstract to make it illegal. I have seen this approach used
many times and used it myself, and it works out just fine.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Robert A Duff]

claveman@cod.nosc.mil (Charles H. Sampson) writes:

>      But it doesn't exactly meet my needs, Robert.  I don't even think 
> it's correct to say that it comes close to meeting my needs.

Not having a certain "*" operator seems very close indeed to having it,
but not being allowed to call it.  Yes, it's different in certain cases
that cause ambiguity, but I can't get excited about these rather rare
cases.

>      For all I know, the abstract approach can cause problems other than 
> ambiguities as well.

Well, you have to admit, *that's* a pretty weak argument.  ;-)

>      The behavior of generics is even further away from what I want.

The issue with generics is the same, whether abstract works the way it
does, or the way you would like it to, and whether you spell it
"abstract" or "disllowed" or whatever.  The problem is that inside the
generic, we have this numeric type, and we legally call "*".  Now what
should that do in an instance where there is no "*" (or where there is a
"*" but it's supposed to be illegal to call it)?  Do you have a proposed
solution to that?  I agree that the current Ada solution is less than
satisfactory.

>...  I 
> haven't verified it myself yet, but several people in this thread have 
> said that an abstract operation reverts to non-abstract in a generic 
> instantiation.  For an operation that has been disallowed, there is 
> nothing to revert to.

So what does it do, in your proposal?  You have to give run-time
semantics, or invent some way to make it illegal.

- Bob

Re: Disallowing Pre-Defined Operations

[claveman]

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

In article <8ababr$c3u$1@wanadoo.fr>,
Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:
>
>Charles H. Sampson <claveman@cod.nosc.mil> a �crit dans le message :
>8a9eeg$qtv$1@newpoisson.nosc.mil...
>>      During the deliberations that led to Ada 95, was a mechanism for
>> disallowing the pre-defined operations of a type considered?  By "disal-
>> lowing" I mean some way of informing the compiler that an attempt to use
>> a certain pre-defined operation is a compile-time error.  Did anyone
>> even ask for it?  (Obviously I didn't, even though I've thought since
>> the mid-eighties that it would be a useful capability to have.)
>
>Not only was it considered - it's there.
>
>>      As an example of what I'm talking about, consider a package that
>> implements three distinct floating-points types for measuring length,
>> area, and volume.  The pre-defined "+" and "-" are acceptable and there
>> are obvious redefinitions of "*" and "/" in some cases.  However, the
>> pre-defined "/" for operands of the same type don't make sense and it
>> would be nice to get a compile-time warning if one of them is used.
>
>function "/" (L, R : Length) return length is abstract;
>
     Wow, that was a surprise!  I'm quite familiar with the concepts of
abstract types and abstract subprograms in the object-oriented context.
I've even given presentations on Ada's special approach to OO.  Maybe
that familiarity led me astray.  Reading too fast, I didn't catch that
an abstract subprogram doesn't have to be an operation of an abstract,
or even a tagged, type.

     I've been lovingly fondling the LRM the last couple of days and I'm
still not certain what's going on here.  Whatever it is, it appears not
to work.  The only test I've run so far has been with the Green Hills
compiler and it doesn't like this use of abstract for this purpose.
Making educated guesses, it appears that the reason is this: Defining
the type as abstract makes the operation illegal to call but it doesn't
hide it.  Extracting from my particular case, if I have the two declara-
tions

     function "-" (L, R : Time_Type) return Delta_Time_Type;
     function "-" (L, R : Time_Type) return Time_Type is abstract;

and I later have the subexpression TT1 - TT2, where the two values are
both of type Time_Type, and this subexpression is part of an appropri-
ately constructed expression, then the Green Hills compiler complains of
an ambiguity.  As I see it, it's saying, "I can't tell if you're refer-
ring to the o. k. "-" that returns a value of type Delta_Time_Type or if
you're referring to the other one, which would be illegal if that's what
you meant."

     Even if M. Rosen is right and Green Hills is wrong, this approach
still doesn't work for me because the problem with literals (mentioned
in my original post) still remains.  To restate it, if I could use this
technique to rule out

     function "*" (L, R : Delta_Time_Type) return Delta_Time_Type;

then I would have also ruled out multiplying a delta time by a real lit-
eral.

     Even if this worked (works), I find it lacking in esthetics.  A
point I always make when arguing in favor of Ada is that it usually al-
lows us to say what we mean in a fairly direct fashion.  When we want to
say that a type or a subprogram is abstract, we don't have to use some
totally non-intuitive notation such as might be found in a more popular
language.  We simply say "is abstract".  If the feature that I want were
available, I'd really like to see something like

     function "-" (L, R : Time_Type) return Time_Type is disallowed;

(Since there is a strong aversion to adding reserved words to Ada, we
could probably get by with "is not".  ;-))

     Another responder mentioned that disallowing operations would have
an impact on generics.  That's true, and a point that I have never con-
sidered.  I'll consider it as soon as I have this abstract subprogram
stuff straightened out.  At the very least, the contract model would
have to become much more elaborate and I doubt that many people have the
stomach for working on that.

     Finally, one responder has mentioned that it could be handled by a
non-standard pragma.  Maybe so, but there's that problem with generics
to contend with.  In any case, non-standard pragmas are not worth a lot
to somebody who is interested in portable code, like me.

				Charlie



--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Disallowing Pre-Defined Operations

[Robert A Duff]

claveman@fern.com writes:

>      I've been lovingly fondling the LRM the last couple of days and I'm
> still not certain what's going on here.  Whatever it is, it appears not
> to work.  The only test I've run so far has been with the Green Hills
> compiler and it doesn't like this use of abstract for this purpose.
> Making educated guesses, it appears that the reason is this: Defining
> the type as abstract makes the operation illegal to call but it doesn't
> hide it.  Extracting from my particular case, if I have the two declara-
> tions
> 
>      function "-" (L, R : Time_Type) return Delta_Time_Type;
>      function "-" (L, R : Time_Type) return Time_Type is abstract;
> 
> and I later have the subexpression TT1 - TT2, where the two values are
> both of type Time_Type, and this subexpression is part of an appropri-
> ately constructed expression, then the Green Hills compiler complains of
> an ambiguity.  As I see it, it's saying, "I can't tell if you're refer-
> ring to the o. k. "-" that returns a value of type Delta_Time_Type or if
> you're referring to the other one, which would be illegal if that's what
> you meant."

You'll have to post the exact code if we're to understand what's going
on there (all of the ops declared, and the supposedly ambiguous
statement).  And the error message.

You should be able to do TT1 - TT2, so long as the context determines
the type.  Eg, "X := TT1 - TT2;" will work, if X is a variable of type
Delta_Time_Type.  And "Delta_Time_Type'(TT1 - TT2)" will work no matter
what the context.

>      Even if M. Rosen is right and Green Hills is wrong, this approach
> still doesn't work for me because the problem with literals (mentioned
> in my original post) still remains.  To restate it, if I could use this
> technique to rule out
> 
>      function "*" (L, R : Delta_Time_Type) return Delta_Time_Type;
> 
> then I would have also ruled out multiplying a delta time by a real lit-
> eral.

You could define another type specifically for numeric literals.  After
all, in "X * 2.5", 2.5 is not a time, it's conceptually a dimensionless
quantity.  You presumably want to allow multiplication by a named
number, as well.

>      Even if this worked (works), I find it lacking in esthetics.

An abstract subprogram is exactly a subprogram that can't be called.
That's true for both tagged and untagged, although the rules that ensure
this property are more complicated in the tagged case, because they need
to account for dispatching calls.

It does seem a bit backwards, perhaps: you might like to declare the
operations that *do* exist, not the ones that don't.  Most of the time,
most programmers don't bother with all this stuff, presumably for that
reason.

Note that you don't want to make these *types* abstract -- just some of
the operations.  There is no such thing as an abstract untagged type.

>...A
> point I always make when arguing in favor of Ada is that it usually al-
> lows us to say what we mean in a fairly direct fashion.  When we want to
> say that a type or a subprogram is abstract, we don't have to use some
> totally non-intuitive notation such as might be found in a more popular
> language.  We simply say "is abstract".  If the feature that I want were
> available, I'd really like to see something like
> 
>      function "-" (L, R : Time_Type) return Time_Type is disallowed;

And how would this differ from the concept of an abstract subprogram?
Is it allowed for tagged types?  Does it have all the same rules about
overriding as abstract subprograms do?

> (Since there is a strong aversion to adding reserved words to Ada, we
> could probably get by with "is not".  ;-))

Various suggestions along those lines were made during the Ada 9X
project.  Norm Cohen was particularly good at coming up with this sort
of thing, and I think he suggested "is abs" instead of "is abstract",
since "abs" was already reserved in Ada 83.  I was never quite sure if
he was joking or not -- certainly "is abs" looks pretty ugly to my eyes.

>      Another responder mentioned that disallowing operations would have
> an impact on generics.  That's true, and a point that I have never con-
> sidered.  I'll consider it as soon as I have this abstract subprogram
> stuff straightened out.  At the very least, the contract model would
> have to become much more elaborate and I doubt that many people have the
> stomach for working on that.

Actually, in an instance, all the operations revert to the predefined
ones anayway, so I don't see a problem (although many people think that
reversion is itself a language flaw).

>      Finally, one responder has mentioned that it could be handled by a
> non-standard pragma.  Maybe so, but there's that problem with generics
> to contend with.  In any case, non-standard pragmas are not worth a lot
> to somebody who is interested in portable code, like me.

Such a pragma (whether language-defined or implementation-defined) would
be in extremely bad taste, IMHO.  Pragmas should not have a strong
effect on the high-level semantics of the language.

- Bob

Re: Disallowing Pre-Defined Operations

[Tarjei T. Jensen]

Robert A Duff wrote:
>Such a pragma (whether language-defined or implementation-defined) would
>be in extremely bad taste, IMHO.  Pragmas should not have a strong
>effect on the high-level semantics of the language.


I would think that pragmas would be an ideal way to explore such a
functionality. If they were useful, then it would be apropriate to extend the
language.


Greetings,

Re: Disallowing Pre-Defined Operations

[Robert A Duff]

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:

> I would think that pragmas would be an ideal way to explore such a
> functionality.

Why?  If you want to explore language extensions, why not properly
design and implement whatever feature it is you think you want, and try
it out?  I don't see any way in which making it a pragma would help.
In fact, it probably makes things slightly harder.

>... If they were useful, then it would be apropriate to extend the
> language.

How about, "if they were useful enough to outweigh the added
complexity..."?  No language feature comes for free.

- Bob

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <8aia0k$csf6@ftp.kvaerner.com>,
  "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
> I would think that pragmas would be an ideal way to explore
such a
> functionality. If they were useful, then it would be
apropriate to extend the
> language.


Not in a case where

a) it is entirely redundant, since it duplicates a feature
already in the language.

b) it significantly violates the design viewpoint of pragmas
which is that they should NOT affect illegality.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Charles H. Sampson]

Robert Duff wrote:
>claveman@fern.com (me) writes:
>
>>      I've been lovingly fondling the LRM the last couple of days and I'm
>> still not certain what's going on here.  Whatever it is, it appears not
>> to work.  The only test I've run so far has been with the Green Hills
>> compiler and it doesn't like this use of abstract for this purpose.
>> Making educated guesses, it appears that the reason is this: Defining
>> the type as abstract makes the operation illegal to call but it doesn't
>> hide it.  Extracting from my particular case, if I have the two declara-
>> tions
>>
>>      function "-" (L, R : Time_Type) return Delta_Time_Type;
>>      function "-" (L, R : Time_Type) return Time_Type is abstract;
>>
>> and I later have the subexpression TT1 - TT2, where the two values are
>> both of type Time_Type, and this subexpression is part of an appropri-
>> ately constructed expression, then the Green Hills compiler complains of
>> an ambiguity.  As I see it, it's saying, "I can't tell if you're refer-
>> ring to the o. k. "-" that returns a value of type Delta_Time_Type or if
>> you're referring to the other one, which would be illegal if that's what
>> you meant."
>
>You'll have to post the exact code if we're to understand what's going
>on there (all of the ops declared, and the supposedly ambiguous
>statement).  And the error message.

     O. K., here's an example.  It's not meant to meaningful, just to
show the problem, although I hope that the name for the integer variable
suggests how it could be used meaningfully.  This example has been
tested on GNAT.  The exact error messages depend on the compiler, but
both GNAT and Green Hills 1.8.9a both complain about the ambiguity.

     procedure Disallow is
     
        type Time_Type is new Float;
        type Delta_Time_Type is new Float;
        
        function "-" (L, R: Time_Type) return Delta_Time_Type;
        function "-" (L, R: Time_Type) return Time_Type is abstract;
        
        TT1, TT2 : Time_Type;
        Elapsed_Seconds : Integer;
     
     begin
        Elapsed_Seconds := Integer (TT1 - TT2);
     end Disallow;

>You should be able to do TT1 - TT2, so long as the context determines
>the type.  Eg, "X := TT1 - TT2;" will work, if X is a variable of type
>Delta_Time_Type.  And "Delta_Time_Type'(TT1 - TT2)" will work no matter
>what the context.

     Certainly the qualified expression would remove any ambiguity, but
the point of my original post was to be allowed to restrict pre-defined
operations in such a manner that there is no ambiguity to begin with.

>>      Even if M. Rosen is right and Green Hills is wrong, this approach
>> still doesn't work for me because the problem with literals (mentioned
>> in my original post) still remains.  To restate it, if I could use this
>> technique to rule out
>>
>>      function "*" (L, R : Delta_Time_Type) return Delta_Time_Type;
>>
>> then I would have also ruled out multiplying a delta time by a real lit-
>> eral.
>
>You could define another type specifically for numeric literals.  After
>all, in "X * 2.5", 2.5 is not a time, it's conceptually a dimensionless
>quantity.  You presumably want to allow multiplication by a named
>number, as well.

     Again, as I said in my original post, if you use another type to
define what multiplication by a real literal means, you open yourself up
to multiplication by any value of that type, not just literals.  I also
referred to "use[ing] numeric literals when appropriate" so, yes, that
includes named numbers.

>>      Even if this worked (works), I find it lacking in esthetics.
>
>An abstract subprogram is exactly a subprogram that can't be called.
>That's true for both tagged and untagged, although the rules that ensure
>this property are more complicated in the tagged case, because they need
>to account for dispatching calls.

     Yes, an abstract subprogram can't be called, but it is declared.
What I want is one that can't be written, that gets an "undefined" error
message out of the compiler.

>It does seem a bit backwards, perhaps: you might like to declare the
>operations that *do* exist, not the ones that don't.  Most of the time,
>most programmers don't bother with all this stuff, presumably for that
>reason.

     Fine.  Then rephrase my question to being about the ability to de-
fine exactly the operations that exist for a type.  Unfortunately, I
seem to be inheriting ones that I don't want.

> ...

>>...A
>> point I always make when arguing in favor of Ada is that it usually al-
>> lows us to say what we mean in a fairly direct fashion.  When we want to
>> say that a type or a subprogram is abstract, we don't have to use some
>> totally non-intuitive notation such as might be found in a more popular
>> language.  We simply say "is abstract".  If the feature that I want were
>> available, I'd really like to see something like
>>
>>      function "-" (L, R : Time_Type) return Time_Type is disallowed;
>
>And how would this differ from the concept of an abstract subprogram?
>Is it allowed for tagged types?  Does it have all the same rules about
>overriding as abstract subprograms do?

     I hope that some of the above clarifies how a disallowed operation
would differ from an abstract operation.  As to the other two questions,
remember, my original question was whether this subject had been consid-
ered during the Ada 95 deliberations, although I obviously have an in-
choate proposal in mind if it wasn't.  With that background, I think I
know what I want in answer to the other two questions.  At the point of
the declaration, the operation ceases to exist.  For the second ques-
tion, I see no reason why the mechanism shouldn't apply to tagged types.
(I don't have a feel for the utility of the idea in this case.)  For the
third question, it seems like the usual scope rules should apply. There-
fore, using the usual mechanisms of the language, it should be possible
to add a definition later in the scope, although this wouldn't be over-
riding since there is nothing to override.

> ...

>>      Another responder mentioned that disallowing operations would have
>> an impact on generics.  That's true, and a point that I have never con-
>> sidered.  I'll consider it as soon as I have this abstract subprogram
>> stuff straightened out.  At the very least, the contract model would
>> have to become much more elaborate and I doubt that many people have the
>> stomach for working on that.
>
>Actually, in an instance, all the operations revert to the predefined
>ones anayway, so I don't see a problem (although many people think that
>reversion is itself a language flaw).

     For the idea I have in mind, however ill-formed it might be, rever-
sion to the pre-defined operations would indeed be a flaw, because the
disallowed pre-defined operation would simply not exist.  It seems like
one thing for an existing operation to lose its abstractness in generics
but it's quite another for a conceptually non-existent operation to come
into being.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Disallowing Pre-Defined Operations

[Tucker Taft]

"Charles H. Sampson" wrote:
> ...
> >You'll have to post the exact code if we're to understand what's going
> >on there (all of the ops declared, and the supposedly ambiguous
> >statement).  And the error message.
> 
>      O. K., here's an example.  It's not meant to meaningful, just to
> show the problem, although I hope that the name for the integer variable
> suggests how it could be used meaningfully.  This example has been
> tested on GNAT.  The exact error messages depend on the compiler, but
> both GNAT and Green Hills 1.8.9a both complain about the ambiguity.
> 
>      procedure Disallow is
> 
>         type Time_Type is new Float;
>         type Delta_Time_Type is new Float;
> 
>         function "-" (L, R: Time_Type) return Delta_Time_Type;
>         function "-" (L, R: Time_Type) return Time_Type is abstract;
> 
>         TT1, TT2 : Time_Type;
>         Elapsed_Seconds : Integer;
> 
>      begin
>         Elapsed_Seconds := Integer (TT1 - TT2);
>      end Disallow;
> 
> >You should be able to do TT1 - TT2, so long as the context determines
> >the type.  Eg, "X := TT1 - TT2;" will work, if X is a variable of type
> >Delta_Time_Type.  And "Delta_Time_Type'(TT1 - TT2)" will work no matter
> >what the context.
> 
>      Certainly the qualified expression would remove any ambiguity, but
> the point of my original post was to be allowed to restrict pre-defined
> operations in such a manner that there is no ambiguity to begin with.

It is true that "abstract" operations are not removed from
consideration by overload resolution.  They are still there, but
they are illegal to call.

The problem you have is the explicit conversion to Integer.
The operand of a conversion must be unambiguous without using
any additional context.  If you assigned "TT1-TT2" to an object
of type Delta_Time_Type, then the compiler would resolve the call
to your non-abstract operator.  As you wrote it here, it is ambiguous,
even though the second possible interpretation is abstract.

So you are correct that "abstract" does not accomplish all that you
might like, because it does not remove the operator from consideration
by overloading.  We considered having abstract operations completely
invisible, but that was not done for some good reason that I can
no longer remember ;-).

> ...
>      I hope that some of the above clarifies how a disallowed operation
> would differ from an abstract operation.  As to the other two questions,
> remember, my original question was whether this subject had been consid-
> ered during the Ada 95 deliberations, although I obviously have an in-
> choate proposal in mind if it wasn't.  With that background, I think I
> know what I want in answer to the other two questions.  At the point of
> the declaration, the operation ceases to exist.  For the second ques-
> tion, I see no reason why the mechanism shouldn't apply to tagged types.
> (I don't have a feel for the utility of the idea in this case.)  For the
> third question, it seems like the usual scope rules should apply. There-
> fore, using the usual mechanisms of the language, it should be possible
> to add a definition later in the scope, although this wouldn't be over-
> riding since there is nothing to override.

We did think about this a bit in the Ada 9X process.  It couldn't apply
to tagged types, because operations can be reached via dispatching,
so you can't remove operations upon inheritance.  It could work for
untagged types, but I suspect that it was a desire for consistency
between tagged and untagged types that kept us from having abstract
operations of an untagged type "disappear" completely.

I understand your goal, and it is reasonable.  The usual question is
whether it is worth the cost.  There are so many great ideas that
are possible, but only so many can be accommodated in a single
language.  What you really want are a small number of very powerful
and flexible concepts that allow you to solve all the
interesting problems elegantly and safely.  Personally, I would like a full-up
"units" capability, where generally A * A => A is not defined, since
that doesn't balance from a units point of view.  I have some ideas
how to get there, and would be interested in opinions from others.
The techniques using discriminants are unsatisfactory in my view,
and too "heavy."  VHDL has the notion of "units" built into the language,
and its approach should probably be evaluated.
> ...
>                                 Charlie
> --
> ******
> 
>      For an email response, my user name is "sampson" and my host
> is "spawar.navy.mil".

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Disallowing Pre-Defined Operations

[Paul Graham]

Tucker Taft wrote:
> 
> "Charles H. Sampson" wrote:
> > ...
> > >You'll have to post the exact code if we're to understand what's going
> > >on there (all of the ops declared, and the supposedly ambiguous
> > >statement).  And the error message.
> >
> >      O. K., here's an example.  It's not meant to meaningful, just to
> > show the problem, although I hope that the name for the integer variable
> > suggests how it could be used meaningfully.  This example has been
> The techniques using discriminants are unsatisfactory in my view,
> and too "heavy."  VHDL has the notion of "units" built into the language,
> and its approach should probably be evaluated.

In VHDL units are mainly used for type TIME.  Things get complicated
when you
try to map the physical world onto unit data types.  For instance:

    type time is ...
    type distance is ...
    type velocity is ...
    type acceleration is ...
    type mass is ...

    function "/"(x : distance; y : time) return velocity;
    function "/"(x : velocity; y : time) return acceleration;
    function "*"(x : mass; y : acceleration) return force;
    function "*"(x : force; y : distance) return work;
    ...

Anyway, you can see that the set of units and possible operations
between units
grows very quickly.  I wonder how big a complete physical types package
would
be (complete enough to represent all the equations in a physics or
electonics
textbook for instance)?

Paul

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D013EF.1F431E34@cadence.com>,
  Paul Graham <pgraham@cadence.com> wrote:
> Things get complicated
> when you
> try to map the physical world onto unit data types.  For
instance:
>
>     type time is ...
>     type distance is ...
>     type velocity is ...
>     type acceleration is ...
>     type mass is ...
>
>     function "/"(x : distance; y : time) return velocity;
>     function "/"(x : velocity; y : time) return acceleration;
>     function "*"(x : mass; y : acceleration) return force;
>     function "*"(x : force; y : distance) return work;

This is a very familiar issue. The above approach is only one
of several ways to approach this problem, other approaches
have been discussed in detail in past threads.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Charles Hixson]

Re: Units:
mks? cgs? or English System? (And is a gallon an Imperial Gallon or a US
gallon?)  Are angles measures in degrees, radians, or mils? (etc.)

This feels like a very important issue to me, but if there is a generally
applicable solution, I still don't know it.  The closest I've come it to
defining, say, Meters to be a particular data type descended from (Numeric...
choose the appropriate flavor) that implements a toString feature.
Of course then one doesn't have the operators defined until one does something
like
function "/"(x : Meters; y : Numeric) return Meters;
et-multitudinous-cetera.

Paul Graham wrote:

> Tucker Taft wrote:
> >
> > "Charles H. Sampson" wrote:
> > > ...
> > > >You'll have to post the exact code if we're to understand what's going
> > > >on there (all of the ops declared, and the supposedly ambiguous
> > > >statement).  And the error message.
> > >
> > >      O. K., here's an example.  It's not meant to meaningful, just to
> > > show the problem, although I hope that the name for the integer variable
> > > suggests how it could be used meaningfully.  This example has been
> > The techniques using discriminants are unsatisfactory in my view,
> > and too "heavy."  VHDL has the notion of "units" built into the language,
> > and its approach should probably be evaluated.
>
> In VHDL units are mainly used for type TIME.  Things get complicated
> when you
> try to map the physical world onto unit data types.  For instance:
>
>     type time is ...
>     type distance is ...
>     type velocity is ...
>     type acceleration is ...
>     type mass is ...
>
>     function "/"(x : distance; y : time) return velocity;
>     function "/"(x : velocity; y : time) return acceleration;
>     function "*"(x : mass; y : acceleration) return force;
>     function "*"(x : force; y : distance) return work;
>     ...
>
> Anyway, you can see that the set of units and possible operations
> between units
> grows very quickly.  I wonder how big a complete physical types package
> would
> be (complete enough to represent all the equations in a physics or
> electonics
> textbook for instance)?
>
> Paul

Re: Disallowing Pre-Defined Operations

[Paul Graham]

Charles Hixson wrote:
> 
> Re: Units:
> mks? cgs? or English System? (And is a gallon an Imperial Gallon or a US
> gallon?)  Are angles measures in degrees, radians, or mils? (etc.)

VHDL has a syntax for defining units for a given physical type.  For
instance:

    type distance is range integer'left to integer'right 
	units angstrom;
	nm = 10 angstrom;
	mm = 1000_000 nm;
	inch = 25 mm;
    end units;

Internally a value of a physical type is represented in terms of its
base unit, in this case angstroms.  This representation is obtained from
the 'pos attribute.  To convert from one unit to another (e.g., for
display purposes) you can do:

    variable d : distance;	-- vhdl declaration syntax
    variable d_inches : integer;
    variable d_mm : integer;

    d_inches := distance'pos(d) / distance'pos(1 inch);
    d_mm := distance'pos(d) / distance'pos(1 mm);

It's also possible to combine different units of the same type:

    d := 3 mm + 4 inch + 2 angstrom;

Paul

Re: Disallowing Pre-Defined Operations

[Charles Hixson]

Paul Graham wrote:

> Charles Hixson wrote:
> >
> > Re: Units:
> > mks? cgs? or English System? (And is a gallon an Imperial Gallon or a US
> > gallon?)  Are angles measures in degrees, radians, or mils? (etc.)
>
> VHDL has a syntax for defining units for a given physical type.  For
> instance:
>
>     type distance is range integer'left to integer'right
>         units angstrom;
>         nm = 10 angstrom;
>         mm = 1000_000 nm;
>         inch = 25 mm;
>     end units;
>
> Internally a value of a physical type is represented in terms of its
> base unit, in this case angstroms.  This representation is obtained from
> the 'pos attribute.  To convert from one unit to another (e.g., for
> display purposes) you can do:
>
>     variable d : distance;      -- vhdl declaration syntax
>     variable d_inches : integer;
>     variable d_mm : integer;
>
>     d_inches := distance'pos(d) / distance'pos(1 inch);
>     d_mm := distance'pos(d) / distance'pos(1 mm);
>
> It's also possible to combine different units of the same type:
>
>     d := 3 mm + 4 inch + 2 angstrom;
>
> Paul

That would have saved at least one space probe.  (By that here I mean the
automatic conversion of units.)

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D2ACA9.84FBD9F6@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
>
> That would have saved at least one space probe.  (By that here
> I mean the automatic conversion of units.)


If you are talking about the Mars probe, that is unconvincing.
As you know if you have read the details, the issue was simply
that the value was entered in the wrong units. No feature in
a language could have prevented this. If the programmer had
been alert enough to worry about this happening and use some
kind of typed units aware input, then the entire problem would
not have occured, after all a sufficient fix here would simply
have been to make it super-clear what units were expected.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Charles Hixson]

My understanding was that there were separate modules coded
correctly internally, that were operating on the basis of different
units, and that the problem probably occurred where the two modules
communicated, that their hand-shaking didn't identify the unit in
use (each assuming that its own unit was, of course, the one to
calculate with), so what was passed was an untyped numeric.

Thus the problem was that using units is a LOT of work in just about
every environment, so people tend to avoid it, when it seems
"obviously unnecessary".  A system that allows units to be specified
easily and inter-converted automatically would be both save and
easy.  That's what units were designed for.  Kilometers can convert
to feet, but not to pounds, etc.  Both, however, look just like
numbers if you strip off their units.  And also kilometers look just
like meters.  I'm currently working on an application that displays
dollars rounded off to thousands.  Because of the problem of keeping
the units straight I am actually maintaining a count in cents right
up to the display step, and then dividing in the display.  This
keeps me from mixing up the units (the application is in VB, so you
can guess how easy THAT would be), but it does keep me from even
THINKING about such refinements as bucket rounding.  I.e., it's
nearly adequate for this job, but v. far from ideal.  OTOH, screen
painting and report formatting in VB (MSAccess, actually) is
*!*SO*!* much easier than in Ada.

OTOH, I am operating off of memories of NASA public reports, I
didn't go digging.  I could have the details wrong for this time.
That wouldn't convince me that the general principle was wrong (but
then nearly all of my work has been in a language other than
Ada...perhaps Ada types are already strong enough to easily handle
the problem).

Robert Dewar wrote:

> In article <38D2ACA9.84FBD9F6@earthlink.net>,
>   Charles Hixson <charleshixsn@earthlink.net> wrote:
> >
> > That would have saved at least one space probe.  (By that here
> > I mean the automatic conversion of units.)
>
> If you are talking about the Mars probe, that is unconvincing.
> As you know if you have read the details, the issue was simply
> that the value was entered in the wrong units. No feature in
> a language could have prevented this. If the programmer had
> been alert enough to worry about this happening and use some
> kind of typed units aware input, then the entire problem would
> not have occured, after all a sufficient fix here would simply
> have been to make it super-clear what units were expected.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D6541E.D2D654AB@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> OTOH, I am operating off of memories of NASA public reports, I
> didn't go digging.  I could have the details wrong for this
> time.

It won't take much digging, just go back to the thread on CLA
that discussed this in detail to see why this was not simply
a language issue.

> That wouldn't convince me that the general principle was wrong
> (but then nearly all of my work has been in a language other
> than Ada...perhaps Ada types are already strong enough to
> easily handle the problem).

Well certainly if you are just talking about different units,
e.g. yards and meters, these would simply be different integer
types in an Ada program, and there is no possibility of
accidentally assigning one to another. Any reasonable typing
system should be at least this strong (although certainly there
are popular very weakly typed languages around and in common
use :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Tarjei T. Jensen]

Tucker Taft wrote in
>I understand your goal, and it is reasonable.  The usual question is
>whether it is worth the cost.  There are so many great ideas that
>are possible, but only so many can be accommodated in a single
>language.  What you really want are a small number of very powerful
>and flexible concepts that allow you to solve all the
>interesting problems elegantly and safely.  Personally, I would like a full-up
>"units" capability, where generally A * A => A is not defined, since
>that doesn't balance from a units point of view.  I have some ideas
>how to get there, and would be interested in opinions from others.
>The techniques using discriminants are unsatisfactory in my view,
>and too "heavy."  VHDL has the notion of "units" built into the language,
>and its approach should probably be evaluated.


I think a "units" facility will be very attractive. I would think that it
woulld make Ada more attractive to the people who would ordinarily use Fortran.
I also think that it might be useful for those who create safety or life
critical software.

I think it is long overdue to be able to add oranges and apples and get fruit
as the result.

Whether this is achived by adding keywords or pragmas, I don't care.

Greetings,

Re: Disallowing Pre-Defined Operations

[mark_biggar]

In article <8aqc0e$n851@ftp.kvaerner.com>,
"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
>
> Tucker Taft wrote in
> >I understand your goal, and it is reasonable. The usual question is
> >whether it is worth the cost. There are so many great ideas that
> >are possible, but only so many can be accommodated in a single
> >language. What you really want are a small number of very powerful
> >and flexible concepts that allow you to solve all the
> >interesting problems elegantly and safely. Personally, I would like a
full-up
> >"units" capability, where generally A * A => A is not defined, since
> >that doesn't balance from a units point of view. I have some ideas
> >how to get there, and would be interested in opinions from others.
> >The techniques using discriminants are unsatisfactory in my view,
> >and too "heavy." VHDL has the notion of "units" built into the
language,
> >and its approach should probably be evaluated.
>
> I think a "units" facility will be very attractive. I would think that
it
> woulld make Ada more attractive to the people who would ordinarily use
Fortran.
> I also think that it might be useful for those who create safety or
life
> critical software.
>
> I think it is long overdue to be able to add oranges and apples and
get fruit
> as the result.
>
> Whether this is achived by adding keywords or pragmas, I don't care.


I have always thought that a simple pragma to turn on some compiler
support for the Discriminate record Units implementation, so that
the compiler automatically generated the code for the necessary
discriminate comparisions on "=", "<", "+", "-", etc. and also
generated necessary discriminate recomputation on "*" and "/".
This would allow the compiler to optimize the static cases.  The
user would only have to define the math part fo each operation, the
compiler would generate every thing else.

--
Mark Biggar
mark@biggar.org


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Dale Stanbrough]

Tucker Taft wrote in
>I understand your goal, and it is reasonable.  The usual question is
>whether it is worth the cost.  There are so many great ideas that
>are possible, but only so many can be accommodated in a single
>language.  What you really want are a small number of very powerful
>and flexible concepts that allow you to solve all the
>interesting problems elegantly and safely.  Personally, I would like a full-up
>"units" capability, where generally A * A => A is not defined, since
>that doesn't balance from a units point of view.  I have some ideas
>how to get there, and would be interested in opinions from others.
>The techniques using discriminants are unsatisfactory in my view,
>and too "heavy."  VHDL has the notion of "units" built into the language,
>and its approach should probably be evaluated.



The C++ template model (for units) which was presented here some months
back seemed to me to be pretty damm good. A series of templates which 
took mass, time and weight as parameters, and some typedefs for
common instantiations did all of the work.

No run time overhead, no space overhead as far as I could see.

Looking at it, I don't think Ada could do as good.


Dale

Re: Disallowing Pre-Defined Operations

[Bryce Bardin]

Tucker Taft wrote:
> ... Personally, I would like a full-up
> "units" capability, where generally A * A => A is not defined, since
> that doesn't balance from a units point of view.  I have some ideas
> how to get there, and would be interested in opinions from others.
> The techniques using discriminants are unsatisfactory in my view,
> and too "heavy."  VHDL has the notion of "units" built into the language,
> and its approach should probably be evaluated.

I have always felt that a full-up, type-safe, compile-time-checked, 
units capability is the one potential "killer" capability that has 
the potential to make Ada the language of choice for engineers and 
scientists world-wide.  But it must be *easy* to use (not feel 
cumbersome) and have no run-time cost.
  
I believe that it should be based on the International System of Units 
(SI), but also incorporate units conversion capabilities, so that 
commonly used systems of engineering units can be gracefully 
accommodated.  I don't think that the number of underlying relations 
would be prohibitive; see for instance:
  http://physics.nist.gov/cuu/Units/units.html,
et seq.  

If all units checking is performed in SI and the relationship
to the various systems of engineering units is implicitly known to
the compiler (or processor), dimensional checking is straightforward.  
Mixed units calculations should be forbidden, absent appropriate 
conversions. 

What remains then is to determine how to specify the units on types 
and values, and how to specify unit conversions.  It is not clear to 
me whether the basis of such a capability needs to be supplied within 
the confines of the current language, or whether a "preprocessor" 
acting on annotated source would be adequate.

Bryce Bardin

Re: Disallowing Pre-Defined Operations

[Robert A Duff]

claveman@fern.com (Charles H. Sampson) writes:

>      O. K., here's an example.  It's not meant to meaningful, just to
> show the problem, although I hope that the name for the integer variable
> suggests how it could be used meaningfully.  This example has been
> tested on GNAT.  The exact error messages depend on the compiler, but
> both GNAT and Green Hills 1.8.9a both complain about the ambiguity.
> 
>      procedure Disallow is
>      
>         type Time_Type is new Float;
>         type Delta_Time_Type is new Float;
>         
>         function "-" (L, R: Time_Type) return Delta_Time_Type;
>         function "-" (L, R: Time_Type) return Time_Type is abstract;
>         
>         TT1, TT2 : Time_Type;
>         Elapsed_Seconds : Integer;
>      
>      begin
>         Elapsed_Seconds := Integer (TT1 - TT2);
>      end Disallow;

The problem here, as I'm sure you understand, is the type conversion.
Type conversions don't supply any useful information to resolve the
inner expression.  So yes, you have to add qualification in this case
("Integer(Delta_Time_Type'(TT1 - TT2))").  In *most* cases, there will
be some context that helps resolve something like "TT1 - TT2", so you
won't need a qualified expression.

As I recall, during the Ada 9X design, abstract subprograms were
originally defined to work the way you want: they would disappear
entirely, and not make anything ambiguous.  This was changed primarily
because of implementation difficulty, and also, as I said above, it's no
big deal, because ambiguities won't happen often, and when they do, you
can always qualify.  I don't remember what the implemention difficulty
was; perhaps it was a difficulty for *existing* implementations only.

So I think what you're really asking for is not a new feature, but for
"abstract" to work the way you would like.  That's reasonable, but IMHO
not important enough to (1) change the way "abstract" works, or (2) add
a new feature that is almost the same as "abstract".

>      Certainly the qualified expression would remove any ambiguity, but
> the point of my original post was to be allowed to restrict pre-defined
> operations in such a manner that there is no ambiguity to begin with.

I can't get excited about these ambiguities, because they are so rare.

>      Again, as I said in my original post, if you use another type to
> define what multiplication by a real literal means, you open yourself up
> to multiplication by any value of that type, not just literals.

Why is that bad?  That other type represents the notion of a
dimensionless quantity, so multiplication by any value of that
type makes sense -- not just literals.

>      Fine.  Then rephrase my question to being about the ability to de-
> fine exactly the operations that exist for a type.  Unfortunately, I
> seem to be inheriting ones that I don't want.

Or, you could use a private type, and lose the things you *do* want,
such as literals.  Or, if we were talking about integers, you would lose
thing like array indexing and case statements.  To me, that's the crux
of the problem: Ada allows you to redefine *some* things (like "+" and
"-"), but not other things, like literals and array indexing.  I don't
like that.

>      I hope that some of the above clarifies how a disallowed operation
> would differ from an abstract operation.

Yes, I now understand what you're asking for.

>      For the idea I have in mind, however ill-formed it might be, rever-
> sion to the pre-defined operations would indeed be a flaw, because the
> disallowed pre-defined operation would simply not exist.  It seems like
> one thing for an existing operation to lose its abstractness in generics
> but it's quite another for a conceptually non-existent operation to come
> into being.

Presumably you could invent some way of defining the contract:  You
could define a generic formal integer type that has no "abs" or "**"
operators, and then the actual would be required to have all the
operators that the formal has (the actual would be *allowed* to have
"abs" and/or "**", but not required).  Sounds like a lot of mechanism
for something that isn't even the "right" way to do this sort of thing.
(I think the "right" way involves defining what the operations *are*,
not defining the ones that might have been but I don't want.  Ada almost
gives you that with private types, but the loss of literals et al is
annoying.)

- Bob

Re: Disallowing Pre-Defined Operations

[Ted Dennison]

In article <8afhed$f9v$1@newpoisson.nosc.mil>,
  claveman@fern.com wrote:

> to work.  The only test I've run so far has been with the Green Hills
> compiler and it doesn't like this use of abstract for this purpose.
> Making educated guesses, it appears that the reason is this: Defining

What version of the GreenHills compiler? I know versions earlier than
1.8.9b had trouble with some convoluted but perfectly leagal abstract
operation declarations in the Booch components. I haven't come across
any such trouble in 1.8.9b yet, but of course that doesn't mean none is
there.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Nick Roberts]

I think you've answered your own question: you SHOULD use private types for
Time_Type and Delta_Time_Type. That way, not only do you get the control
over operations that you need, you also get an explicit statement of unit
for all your literals!  E.g., T+15.0 is poor software engineering compared
to T+Seconds(15.0), although you might prefer T+Duration(15.0) at a pinch.

--
Nick Roberts
http://www.adapower.com/lab/adaos

"Charles H. Sampson" <claveman@cod.nosc.mil> wrote in message
news:8a9eeg$qtv$1@newpoisson.nosc.mil...

>      During the deliberations that led to Ada 95, was a mechanism for
> disallowing the pre-defined operations of a type considered?
> ...

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38ce8e44@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> I think you've answered your own question: you SHOULD use
private types for
> Time_Type and Delta_Time_Type. That way, not only do you get
the control
> over operations that you need, you also get an explicit
statement of unit
> for all your literals!

Sure, this is quite familiar (and is in fact Ada 83), but in
practice it is often awfully heavy to use this approach and
lose literals. So it is nice to have an alternative approach.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[William A Whitaker]

I have not been following this thread carefylly.  I had no idea it would
go on so long.  But I would like to toss in a study I did ten years ago
along this line for the units problem.  This is at 

http://www.erols.com/whitaker/metric.sty

A lot of the intermediate code is left out, only a "final" version
given, but discussion is extensive.

The study was a failure in the sense that the answer was that while one
could do such things (including forbidding unwanted operations) it was
completely impractical in a standards situation where one expects lots
of unknowable combinations.  If the problem was just three units and
seven operations, then one could afford this nonsense.

I believe that discriminants are teh only practical way to get close to
the desired result, and I will try to post a paper on that soon.

Of course, the ideal is an Ada recognition of the Units requirement and
implementation at the standard/compiler level.


Whitaker

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D2E598.262D1CD5@erols.com>,
  whitaker@erols.com wrote:
> Of course, the ideal is an Ada recognition of the Units
> requirement and implementation at the standard/compiler level.

I don't see the "of course" here at all. It is not at all clear
that the damage to the language done by the additional
complexity here would be worth the additional functionality.

Given that the discriminants solution works fine, and has an
efficient implementation, that seems good enough to me. If no
compiler vendor has bothered to provide this efficient
implementation, it would tend to indicate that it is simply
not that important.

Certainly we have never had any customers asking for such
a feature, and our customers are not shy when it comes to
asking for enhancements (the long list of features in the
new release of GNAT 3.13a is largely fueled by customer
requests).

Robert Dewar
Ada Core Technologies

P.S. Exploring this more efficient implementation would
certainly make a nice GNAT-based project for someone to
undertake.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D2E598.262D1CD5@erols.com>,
  whitaker@erols.com wrote:
> Of course, the ideal is an Ada recognition of the Units
> requirement and implementation at the standard/compiler level.

I don't see the "of course" here at all. It is not at all clear
that the damage to the language done by the additional
complexity here would be worth the additional functionality.

Given that the discriminants solution works fine, and has an
efficient implementation, that seems good enough to me. If no
compiler vendor has bothered to provide this efficient
implementation, it would tend to indicate that it is simply
not that important.

Certainly we have never had any customers asking for such
a feature, and our customers are not shy when it comes to
asking for enhancements (the long list of features in the
new release of GNAT 3.13a is largely fueled by customer
requests).

Robert Dewar
Ada Core Technologies

P.S. Exploring this more efficient implementation would
certainly make a nice GNAT-based project for someone to
undertake.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D2E598.262D1CD5@erols.com>,
  whitaker@erols.com wrote:
> Of course, the ideal is an Ada recognition of the Units
> requirement and implementation at the standard/compiler level.

I don't see the "of course" here at all. It is not at all clear
that the damage to the language done by the additional
complexity here would be worth the additional functionality.

Given that the discriminants solution works fine, and has an
efficient implementation, that seems good enough to me. If no
compiler vendor has bothered to provide this efficient
implementation, it would tend to indicate that it is simply
not that important.

Certainly we have never had any customers asking for such
a feature, and our customers are not shy when it comes to
asking for enhancements (the long list of features in the
new release of GNAT 3.13a is largely fueled by customer
requests).

Robert Dewar
Ada Core Technologies

P.S. Exploring this more efficient implementation would
certainly make a nice GNAT-based project for someone to
undertake.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[William A Whitaker]

No one asks for built-in units checking.  (Actually I did and several
others have talked to me about it, but apparently not to ACT.)  This may
not be unexpected.  ACT talks to the computer people in a company. 
Computer scientists have no brief for units, they deal with bits, and
maybe GUIs.  They get an algorithm and are supposed to implement it. 
That is software.  The managers do not ask for units, thay just want to
job done and expect that the programmeers will take care of it.  The
only way they would know of the problem is when something goes wrong,
like a Mars probe crashes.  And the knowledge is of little use then
because their next managerial job is at McDolalds.

It was not always so.  The first few generations of computers were
designed and built for physicists, who did their own programming.  And
units were important, but physicists were trained to be particularly
careful with them.  Now days the language/compiler could help those who
are not as careful. 

I suggest that a units checking feature would be a valuable selling
feature in Ada, even though one might have to educate the user.  But it
is a step above any individual implementer.  The suggestion that it
would be an interesting experiment as a modification to GNAT is a good
one.  But I hope such work gets widely circulated so that there is
developed a common method of stating the units in a program, however it
is implemented.  And one might advertize that the units pragma in one
system means the same as in another.

Whitaker

Robert Dewar wrote:
> 
> In article <38D2E598.262D1CD5@erols.com>,
>   whitaker@erols.com wrote:
> > Of course, the ideal is an Ada recognition of the Units
> > requirement and implementation at the standard/compiler level.
> 
> I don't see the "of course" here at all. It is not at all clear
> that the damage to the language done by the additional
> complexity here would be worth the additional functionality.
> 
> Given that the discriminants solution works fine, and has an
> efficient implementation, that seems good enough to me. If no
> compiler vendor has bothered to provide this efficient
> implementation, it would tend to indicate that it is simply
> not that important.
> 
> Certainly we have never had any customers asking for such
> a feature, and our customers are not shy when it comes to
> asking for enhancements (the long list of features in the
> new release of GNAT 3.13a is largely fueled by customer
> requests).
> 
> Robert Dewar
> Ada Core Technologies
> 
> P.S. Exploring this more efficient implementation would
> certainly make a nice GNAT-based project for someone to
> undertake.
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38D9A2E8.F720768@erols.com>,
  whitaker@erols.com wrote:
> No one asks for built-in units checking.  (Actually I did and
several
> others have talked to me about it, but apparently not to ACT.)
This may
> not be unexpected.  ACT talks to the computer people in a
company.
> Computer scientists have no brief for units, they deal with
bits, and
> maybe GUIs.  They get an algorithm and are supposed to
implement it.

Well I can't speak for other vendors, but the above is not
anything like recognizable in terms of our customers and
how we interact and whom we talk to. We definitely talk to
the designers at the top level. It is simply that this
requirement has never arisen.

In wake of the publicity of the Mars mission, even though this
was not a language issue per se, you would think that if anyone
was interested in this issue, it would have come up now.

Note that the derived types in Ada go quite far in the direction
of avoiding junk unintentional mixing of units.

What would be interesting is to gather a catalog of instances
in which units problems *preventable by the kind of feature
being discussed here* have actually occurred and caused trouble.

I see a lot of people hypothesizing that this would be a useful
feature that would sell Ada, but as we all know in CLA, there
is that kind of support for almost any imaginable feature in
Ada. What would be more interesting is specific war stories that
we could analyze to see how an additional feature might have
helped.

Robert Dewar
Ada Core Technologies




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Robert I. Eachus]

Robert Dewar wrote:
  
> I see a lot of people hypothesizing that this would be a useful
> feature that would sell Ada, but as we all know in CLA, there
> is that kind of support for almost any imaginable feature in
> Ada. What would be more interesting is specific war stories that
> we could analyze to see how an additional feature might have
> helped.

   There is a general-purpose feature that could be added to compilers,
and which is already
explicitly allowed for by the Ada 95 standard.  If compilers were to
provide a non-standard
integer and non-standard floating point type with literals, assignment
and, I think, no other operations, then implementors could provide
various packages to provide SI unit checking, unbounded numeric types
with literals and so on.  Hmmm.  The 'SIZE attribute is key, and needs
to be user settable.  Conversion of literals in source code should, in
effect, use the same routines as for the largest integer and float
types.  If hundred-digit values need to be built
at compile time, that could be left to the programmer, but it is a pain
not to be able to use
literals for zero, one, and two.

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

Robert I. Eachus wrote:
>    There is a general-purpose feature that could be added to compilers,
> and which is already
> explicitly allowed for by the Ada 95 standard.  If compilers were to
> provide a non-standard
> integer and non-standard floating point type with literals, assignment
> and, I think, no other operations, then implementors could provide
> various packages to provide SI unit checking, unbounded numeric types
> with literals and so on.  Hmmm.  The 'SIZE attribute is key, and needs

I've voted for it before, but I'll mention it again: Integer and Real
(Fixed & Float) types that saturate on overflow. It may be hard to
implement on some hardware, but it could be very useful. I don't think
we'd need to come up with war stories to argue its usefulness. Its
already done (through a variety of hacks) in lots of embedded systems
that perform control of analog hardware.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38EC160F.E2A13F44@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

> I've voted for it before, but I'll mention it again: Integer
and Real
> (Fixed & Float) types that saturate on overflow.


Why does this need a language feature? This is the sort of thing
that is perfectly easy to program in Ada now. Sure you might
get a little bit more efficient implementation if it was built
in, but compilers could already do that by use of Intrinsic
conventions, I see no reason for a new language feature here.

Does anyone have any experience with saturating numeric types
in existing Ada programs?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

Robert Dewar wrote:
> Why does this need a language feature? This is the sort of thing
> that is perfectly easy to program in Ada now. Sure you might
> get a little bit more efficient implementation if it was built
> in, but compilers could already do that by use of Intrinsic
> conventions, I see no reason for a new language feature here.
> 
In my experience, while one could certainly write source level code to
do the job, this ends up sufficiently inefficient to be not useful in
the kinds of systems that need it most - real time control computers.
You could degenerate to programming it in assembler, but often this gets
clumsy. (typically, you want to do something to trap overflow interrupts
and this can be difficult or problematic if you are not the compiler.
Either that, or you're working with sub-ranges of the word size and you
want a trap similar to Constraint_Error which gets problematic when
you've got lots of sub-ranges.) A solution does exist because I've done
it, but it would be easier - and may have other efficiency & error
checking benefits - if there were direct compiler support for it as an
intrinsic type.

Certainly, it would be easier for your average fresh-out or
inexperienced user to take advantage of it if it were intrinsic. And you
never quite know what sort of uses something like this might get put to
if it was simply right there to use.

> Does anyone have any experience with saturating numeric types
> in existing Ada programs?
> 
Yup. In Ada83 at least. Its not real pretty. Havn't had to do it in
Ada95 yet. Day ain't over, yet! :-)

If its too hard to implement or you just don't think it has enough
interest for ACT to support it, by all means drop the idea on the floor.
The original question was basically "What new features would it benefit
Ada to have?" I don't know about the rest of the world but if Ada had
saturated math data types *I* would have beaten it to death in the
engine control business. I'd suspect that other embedded programmers
would find the feature *very* useful and (here's the good part!) it
doesn't exist (that I am aware of) in the more popular languages for
that market sector. (Product distinction?)

It doesn't sound to me like something that would require some massive
compiler rewrite or some fundamental change in Ada syntax or semantics.
I'm no expert, but it seems fairly small and self-contained such that a
compiler could provide it as an option that could be toggled by
switches. Syntax? Maybe "type T is saturated digits 6 ;" or "type T is
saturated range -128..127 ;" Maybe as a pragma? "pragma Saturate (T) ;"
I personally wouldn't be fussy. :-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: Disallowing Pre-Defined Operations

[Robert Dewar]

In article <38ED3145.BE3CEC68@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> If its too hard to implement or you just don't think it has
> enough interest for ACT to support it

You missed my main point, which is that in the unlikely event
that a compiler DOES want to support this efficiently, no
change to the language is required, since Intrinsic can be
used for this purpose.

> The original question was basically "What new features would
> it benefit Ada to have?"

The fact that your compiler handled the user defined version
inefficiently may say nothing more than that you were using
an inefficient compiler, at least with respect to this
particular issue. There is no guarantee that building a
feature into the language means it will be done more
efficiently on a given compiler.

Indeed the only convincing input here from my point of view
would be some user who programs it themselves, and actually
measures that there is a performance problem.

And if such a situation arose, as I mention above, no language
change is necessary, one would simply improve the efficiency
of the feature (I am quite unconvinced that Intrinsic would
be required, since this seems something that can be programmed
perfectly efficiently in Ada, but Intrinsic is there if needed).

I actually find that very few Ada programmers properly
understand the intrinsic feature of Ada 95, or even know
of its existence. Pity -- because this is really an important
part of the language design.



 I don't know about the rest of the world but if Ada had
> saturated math data types *I* would have beaten it to death in
the
> engine control business. I'd suspect that other embedded
programmers
> would find the feature *very* useful and (here's the good
part!) it
> doesn't exist (that I am aware of) in the more popular
languages for
> that market sector. (Product distinction?)
>
> It doesn't sound to me like something that would require some
massive
> compiler rewrite or some fundamental change in Ada syntax or
semantics.
> I'm no expert, but it seems fairly small and self-contained
such that a
> compiler could provide it as an option that could be toggled
by
> switches. Syntax? Maybe "type T is saturated digits 6 ;" or
"type T is
> saturated range -128..127 ;" Maybe as a pragma? "pragma
Saturate (T) ;"
> I personally wouldn't be fussy. :-)
>
> MDC
> --
> =============================================================
> Marin David Condic   - Quadrus Corporation -   1.800.555.3393
> 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
> http://www.quadruscorp.com/
> m c o n d i c @ q u a d r u s c o r p . c o m
>
> ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***
>
> Visit my web site at:  http://www.mcondic.com/
>
> "Because that's where they keep the money."
>     --  Willie Sutton when asked why he robbed banks.
> =============================================================
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

Robert Dewar wrote:
> 
> In article <38ED3145.BE3CEC68@quadruscorp.com>,
>   "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> > If its too hard to implement or you just don't think it has
> > enough interest for ACT to support it
> 
> You missed my main point, which is that in the unlikely event
> that a compiler DOES want to support this efficiently, no
> change to the language is required, since Intrinsic can be
> used for this purpose.
> 
O.K. I seem to recall somewhere in the past where this issue came up
that you pointed out that the language had mechanisms for doing this. I
can accept that a solution does exist. My only point is that if a
compiler were to come fully equipped with this right out of the box that
it would be a useful feature to have. If it was just right there in
front of you and had an efficient implementation, it would likely get
put to all sorts of new and creative uses. (Keep in mind that there are
thousands of programmers out there to whom "saturated math" is a
complete unknown. We'll probably yet get someone out there posting
"What's saturated math?" - nobody can know everything, eh?)

Think of it this way: When Ada83 was out there, people bemoaned the fact
that there weren't any standard math libraries. The argument against it
was essentially identical to yours: Any competent programmer can go
build his own and it doesn't require a change to the language. Sooner or
later (for a variety of reasons, including efficiency of implementation)
the vendors each started providing their own non-standard math
libraries. Ada95 comes around and (color me astonished! :-) there's a
standard set of math libraries! Life is good and the world is a
wonderful place indeed.

So *if* a vendor were to put such a thing out there - sort of pioneering
an uncharted territory - even if any competent programmer could do it
within the confines of the existing syntax and semantics - it might end
up setting the standard for a future extention to Ada.

And its also an issue that the users of such features may understand how
to use them, but may not be nearly as smart about how to build them.
That's why we hire really smart guys to go write compilers instead of
having every programmer go roll his own.

> Indeed the only convincing input here from my point of view
> would be some user who programs it themselves, and actually
> measures that there is a performance problem.
> 
In hard real time systems where this particular feature is most likely
to be used, you sweat over microseconds. Using instruction X versus
instruction Y because X takes a couple of fewer clock ticks can be a big
deal. I've regularly bagged all the runtime checks, hand optimized
assembly code, reordered events, and pulled all kinds of dirty tricks to
get just a little more room in the cycle. You do it not because it is
good computer science or even particularly safe, but because if you
don't you might as well just pack up and go home because it isn't going
to run.

So if my compiler vendor is smarter than I am about how to get just a
little bit more performance out of some math routines, I want the
compiler to do it directly. Especially since math ops happen with such
frequency. Heck, if I could get the *hardware* to do the saturation, I'd
be ten times as happy! Unfortunately, its a lot harder to change the
silicon than it is to change the compiler.

> 
> I actually find that very few Ada programmers properly
> understand the intrinsic feature of Ada 95, or even know
> of its existence. Pity -- because this is really an important
> part of the language design.
> 
That's why we rely on features and tools provided by the vendors. We
can't all be Ada-Einsteins, can we? :-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
=============================================================

Re: Disallowing Pre-Defined Operations

[dale]

Marin D. Condic" wrote:

> It doesn't sound to me like something that would require some massive
> compiler rewrite or some fundamental change in Ada syntax or semantics.
> I'm no expert, but it seems fairly small and self-contained such that a
> compiler could provide it as an option that could be toggled by
> switches. Syntax? Maybe "type T is saturated digits 6 ;" or "type T is
> saturated range -128..127 ;" Maybe as a pragma? "pragma Saturate (T) ;"
> I personally wouldn't be fussy. :-)


A pragma would not do it, as you would have to deal with generics.
(e.g. the semantics of a multiply operation in a generic would have
to be modified not to raise an exception, but to cap the result).

Dale

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

dale wrote:
> A pragma would not do it, as you would have to deal with generics.
> (e.g. the semantics of a multiply operation in a generic would have
> to be modified not to raise an exception, but to cap the result).
> 
O.K. Point taken. I'm not a compiler writer so I'm glad someone else
does that job. ;-)

I don't like the notion of creating another reserved word if it can be
avoided. Obviously, the less intrusive my pet feature is, the more
likely it would be to end up in someone's compiler as an option. I could
imagine it being provided as a generic package, but my fear there is
that without some sort of "special treatment" by the compiler, the code
would be too slow to be useful in a real time system. Any suggestions?

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
=============================================================

Re: Disallowing Pre-Defined Operations

[Tarjei T. Jensen]

Marin D. Condic wrote
>
>I don't like the notion of creating another reserved word if it can be
>avoided. Obviously, the less intrusive my pet feature is, the more
>likely it would be to end up in someone's compiler as an option. I could
>imagine it being provided as a generic package, but my fear there is
>that without some sort of "special treatment" by the compiler, the code
>would be too slow to be useful in a real time system. Any suggestions?


Why should it be slow??? All (at least most) of the action should be at the
compile stage. That is when the checking is done. The generated code should run
as usual.

All that happens is that there should be fewer run-time errors to discover
since the universe describe all the legal operatons with the various datatypes.
If you try to multiply velocities the compiler will tell you that it is not
legal.

Greetings,

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

Tarjei T. Jensen wrote:
> Why should it be slow??? All (at least most) of the action should be at the
> compile stage. That is when the checking is done. The generated code should run
> as usual.
> 
> All that happens is that there should be fewer run-time errors to discover
> since the universe describe all the legal operatons with the various datatypes.
> If you try to multiply velocities the compiler will tell you that it is not
> legal.
> 
Maybe you missed the point. The checks *must* be at runtime - similar to
Constraint_Error except that no exception gets raised. When the value
exceeds the range, the object is saturated to its max/min value. This is
inherently slow in that you can't just do the math, but have to check
results and saturate at every step of the way. (Unless the hardware has
direct support for it. I've not encountered that anywhere, but that
doesn't mean it doesn't exist.) Given that an application may perform
thousands - or millions - of math operations, adding the extra overhead
can get quite costly. In hard real time situations where saturated math
is quite a common desire, you often need to get the math done in
extremely small amounts of time. So you want code that is as totally
optimized as possible.

MDC

-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
=============================================================

Re: Disallowing Pre-Defined Operations

[tmoran]

>results and saturate at every step of the way. (Unless the hardware has
>direct support for it. I've not encountered that anywhere, but that
  Doesn't Intel MMX do that?

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

tmoran@bix.com wrote:
> 
> >results and saturate at every step of the way. (Unless the hardware has
> >direct support for it. I've not encountered that anywhere, but that
>   Doesn't Intel MMX do that?

It might. Beats the hell out of me. I've never looked the chip over.
Think there's a data book on the web somewhere?

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
=============================================================

Re: Disallowing Pre-Defined Operations

[Vladimir Olensky]

Marin D. Condic wrote in message <38EE7D26.D5DADAEC@quadruscorp.com>...
>tmoran@bix.com wrote:
>>
>> >results and saturate at every step of the way. (Unless the hardware has
>> >direct support for it. I've not encountered that anywhere, but that
>>   Doesn't Intel MMX do that?
>
>It might. Beats the hell out of me. I've never looked the chip over.
>Think there's a data book on the web somewhere?


IA32 MMX does provide saturated arithmetic. All that are in Intel
documentation. I mentioned about that some time  ago in
discussion regarding direct support of MMX extensions by
Ada compileres.

But even without that it is  very easy to write a piece of external
assembler code that uses MMX and import it in Ada spec file.

Regards.

Re: Disallowing Pre-Defined Operations

[Vladimir Olensky]

Marin D. Condic wrote in message <38EE7D26.D5DADAEC@quadruscorp.com>...
>tmoran@bix.com wrote:
>>
>> >results and saturate at every step of the way. (Unless the hardware has
>> >direct support for it. I've not encountered that anywhere, but that
>>   Doesn't Intel MMX do that?
>
>It might. Beats the hell out of me. I've never looked the chip over.
>Think there's a data book on the web somewhere?


IA32 MMX does provide saturated arithmetic. All that are in Intel
documentation. I mentioned about that some time  ago in
discussion regarding direct support of MMX extensions by
Ada compileres.

But even without that it is  very easy to write a piece of external
assembler code that uses MMX and import it in Ada spec file.

Regards.

Re: Disallowing Pre-Defined Operations

[Dale Stanbrough]

Marin D. Condic wrote:

> Unless the hardware has
> direct support for it. I've not encountered that anywhere, but that
> doesn't mean it doesn't exist.

PPC Altivec definately does this, and i'm pretty sure that MMX does
(as someone else noted). This is a "must have" for multimedia to
provide support processing image pixals, where many
algorithms require saturation semantics.


Dale

Re: Disallowing Pre-Defined Operations

[Tarjei T. Jensen]

Marin D. Condic
>Maybe you missed the point. The checks *must* be at runtime - similar to
>Constraint_Error except that no exception gets raised. When the value
>exceeds the range, the object is saturated to its max/min value.

Yep, I missed the point. I forgot that there was more than one thing being
discussed in this thread.


Greetings,

Re: Disallowing Pre-Defined Operations

[Niklas Holsti]

Marin D. Condic wrote:
 ...
> When the value
> exceeds the range, the object is saturated to its max/min value. This is
> inherently slow in that you can't just do the math, but have to check
> results and saturate at every step of the way. (Unless the hardware has
> direct support for it. I've not encountered that anywhere, but that
> doesn't mean it doesn't exist.)

The Analog Devices ADSP-21020 digital signal processor can be put in
a "saturation" mode in which the arithmetic operations are saturating
rather than overflowing. I suppose this holds for the newer "SHARC"
series too.

Since the 21020 is a 32-bit, floating-point DSP, this could be a nice
platform for saturation arithmetic in demanding real-time systems.

Niklas Holsti
Working at but not speaking for Space Systems Finland Ltd.

Re: Disallowing Pre-Defined Operations

[Marin D. Condic]

Niklas Holsti wrote:
> 
> The Analog Devices ADSP-21020 digital signal processor can be put in
> a "saturation" mode in which the arithmetic operations are saturating
> rather than overflowing. I suppose this holds for the newer "SHARC"
> series too.
> 
Cool. I'll put it on my list of things to check out.

> Since the 21020 is a 32-bit, floating-point DSP, this could be a nice
> platform for saturation arithmetic in demanding real-time systems.
> 
There are lots of uses for saturation. One problem though is that you
might need to support user-defined ranges where, AFAIK, there isn't
going to be hardware support. (Maybe someone could come up with some
special range registers on a processor?) For instance, if you have a 10
bit D/A converter, any math you do to drive this you want to saturate
within those 10 bits. 16 bit integer math that saturates isn't likely to
help you much there. So in the end, you still need some compiler
checking capabilities.

Unless you know of some hardware tricks being invented recently?

Thanks for the tip on the DSP.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Disallowing Pre-Defined Operations

[Robert I. Eachus]

Robert Dewar wrote:
> 
> Why does this need a language feature? This is the sort of thing
> that is perfectly easy to program in Ada now. Sure you might
> get a little bit more efficient implementation if it was built
> in, but compilers could already do that by use of Intrinsic
> conventions, I see no reason for a new language feature here.
> 
> Does anyone have any experience with saturating numeric types
> in existing Ada programs?

   Yes, and the non-standard integer type I suggested would neatly
solve the problem.  The two workarounds available are to overload the
predefined "+" and "-", but now you have to have lots of rules to avoid
paasing saturated values to generic operations, 'Pred and 'Succ, etc.

   The preferred alternative is to make the visible type private, and to
overload monadic "+" and "-" as conversions for literals.  This has its
own
disadvantages--including making numeric constants non-static.