* Disallowing Pre-Defined Operations @ 2000-03-10 0:00 Charles H. Sampson 2000-03-09 0:00 ` Keith Thompson ` (5 more replies) 0 siblings, 6 replies; 66+ messages in thread From: Charles H. Sampson @ 2000-03-10 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson @ 2000-03-09 0:00 ` Keith Thompson 2000-03-09 0:00 ` Samuel T. Harris ` (4 subsequent siblings) 5 siblings, 0 replies; 66+ messages in thread From: Keith Thompson @ 2000-03-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson 2000-03-09 0:00 ` Keith Thompson @ 2000-03-09 0:00 ` Samuel T. Harris 2000-03-12 0:00 ` Steven Hovater 2000-03-10 0:00 ` mark_biggar ` (3 subsequent siblings) 5 siblings, 1 reply; 66+ messages in thread From: Samuel T. Harris @ 2000-03-09 0:00 UTC (permalink / raw) "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!" ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-09 0:00 ` Samuel T. Harris @ 2000-03-12 0:00 ` Steven Hovater 0 siblings, 0 replies; 66+ messages in thread From: Steven Hovater @ 2000-03-12 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson 2000-03-09 0:00 ` Keith Thompson 2000-03-09 0:00 ` Samuel T. Harris @ 2000-03-10 0:00 ` mark_biggar 2000-03-10 0:00 ` Jean-Pierre Rosen ` (2 subsequent siblings) 5 siblings, 0 replies; 66+ messages in thread From: mark_biggar @ 2000-03-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson ` (2 preceding siblings ...) 2000-03-10 0:00 ` mark_biggar @ 2000-03-10 0:00 ` Jean-Pierre Rosen 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen 2000-03-12 0:00 ` claveman 2000-03-14 0:00 ` Nick Roberts 2000-03-17 0:00 ` William A Whitaker 5 siblings, 2 replies; 66+ messages in thread From: Jean-Pierre Rosen @ 2000-03-10 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 ` Jean-Pierre Rosen @ 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen 2000-03-11 0:00 ` James S. Rogers ` (3 more replies) 2000-03-12 0:00 ` claveman 1 sibling, 4 replies; 66+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-03-11 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen @ 2000-03-11 0:00 ` James S. Rogers 2000-03-13 0:00 ` Tarjei T. Jensen 2000-03-13 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 1 reply; 66+ messages in thread From: James S. Rogers @ 2000-03-11 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-11 0:00 ` James S. Rogers @ 2000-03-13 0:00 ` Tarjei T. Jensen 0 siblings, 0 replies; 66+ messages in thread From: Tarjei T. Jensen @ 2000-03-13 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen 2000-03-11 0:00 ` James S. Rogers @ 2000-03-13 0:00 ` Robert Dewar 2000-03-13 0:00 ` Keith Thompson 2000-03-13 0:00 ` dmitry6243 2000-03-15 0:00 ` Charles H. Sampson 3 siblings, 1 reply; 66+ messages in thread From: Robert Dewar @ 2000-03-13 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-13 0:00 ` Robert Dewar @ 2000-03-13 0:00 ` Keith Thompson 2000-03-15 0:00 ` Robert Dewar 0 siblings, 1 reply; 66+ messages in thread From: Keith Thompson @ 2000-03-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-13 0:00 ` Keith Thompson @ 2000-03-15 0:00 ` Robert Dewar 0 siblings, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen 2000-03-11 0:00 ` James S. Rogers 2000-03-13 0:00 ` Robert Dewar @ 2000-03-13 0:00 ` dmitry6243 2000-03-15 0:00 ` Charles H. Sampson 3 siblings, 0 replies; 66+ messages in thread From: dmitry6243 @ 2000-03-13 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen ` (2 preceding siblings ...) 2000-03-13 0:00 ` dmitry6243 @ 2000-03-15 0:00 ` Charles H. Sampson 2000-03-15 0:00 ` Robert Dewar 3 siblings, 1 reply; 66+ messages in thread From: Charles H. Sampson @ 2000-03-15 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Charles H. Sampson @ 2000-03-15 0:00 ` Robert Dewar 2000-03-21 0:00 ` Charles H. Sampson 0 siblings, 1 reply; 66+ messages in thread From: Robert Dewar @ 2000-03-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Robert Dewar @ 2000-03-21 0:00 ` Charles H. Sampson 2000-03-21 0:00 ` Robert A Duff 2000-03-21 0:00 ` Robert Dewar 0 siblings, 2 replies; 66+ messages in thread From: Charles H. Sampson @ 2000-03-21 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-21 0:00 ` Charles H. Sampson @ 2000-03-21 0:00 ` Robert A Duff 2000-03-21 0:00 ` Robert Dewar 1 sibling, 0 replies; 66+ messages in thread From: Robert A Duff @ 2000-03-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-21 0:00 ` Charles H. Sampson 2000-03-21 0:00 ` Robert A Duff @ 2000-03-21 0:00 ` Robert Dewar 1 sibling, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 ` Jean-Pierre Rosen 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen @ 2000-03-12 0:00 ` claveman 2000-03-12 0:00 ` Robert A Duff 2000-03-13 0:00 ` Ted Dennison 1 sibling, 2 replies; 66+ messages in thread From: claveman @ 2000-03-12 0:00 UTC (permalink / raw) [-- 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". ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-12 0:00 ` claveman @ 2000-03-12 0:00 ` Robert A Duff 2000-03-13 0:00 ` Tarjei T. Jensen 2000-03-15 0:00 ` Charles H. Sampson 2000-03-13 0:00 ` Ted Dennison 1 sibling, 2 replies; 66+ messages in thread From: Robert A Duff @ 2000-03-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-12 0:00 ` Robert A Duff @ 2000-03-13 0:00 ` Tarjei T. Jensen 2000-03-13 0:00 ` Robert A Duff 2000-03-13 0:00 ` Robert Dewar 2000-03-15 0:00 ` Charles H. Sampson 1 sibling, 2 replies; 66+ messages in thread From: Tarjei T. Jensen @ 2000-03-13 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-13 0:00 ` Tarjei T. Jensen @ 2000-03-13 0:00 ` Robert A Duff 2000-03-13 0:00 ` Robert Dewar 1 sibling, 0 replies; 66+ messages in thread From: Robert A Duff @ 2000-03-13 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-13 0:00 ` Tarjei T. Jensen 2000-03-13 0:00 ` Robert A Duff @ 2000-03-13 0:00 ` Robert Dewar 1 sibling, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-12 0:00 ` Robert A Duff 2000-03-13 0:00 ` Tarjei T. Jensen @ 2000-03-15 0:00 ` Charles H. Sampson 2000-03-15 0:00 ` Tucker Taft 2000-03-17 0:00 ` Robert A Duff 1 sibling, 2 replies; 66+ messages in thread From: Charles H. Sampson @ 2000-03-15 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Charles H. Sampson @ 2000-03-15 0:00 ` Tucker Taft 2000-03-15 0:00 ` Paul Graham ` (2 more replies) 2000-03-17 0:00 ` Robert A Duff 1 sibling, 3 replies; 66+ messages in thread From: Tucker Taft @ 2000-03-15 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Tucker Taft @ 2000-03-15 0:00 ` Paul Graham 2000-03-16 0:00 ` Charles Hixson 2000-03-16 0:00 ` Robert Dewar 2000-03-16 0:00 ` Tarjei T. Jensen 2000-03-16 0:00 ` Bryce Bardin 2 siblings, 2 replies; 66+ messages in thread From: Paul Graham @ 2000-03-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Paul Graham @ 2000-03-16 0:00 ` Charles Hixson 2000-03-17 0:00 ` Paul Graham 2000-03-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 66+ messages in thread From: Charles Hixson @ 2000-03-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-16 0:00 ` Charles Hixson @ 2000-03-17 0:00 ` Paul Graham 2000-03-17 0:00 ` Charles Hixson 0 siblings, 1 reply; 66+ messages in thread From: Paul Graham @ 2000-03-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-17 0:00 ` Paul Graham @ 2000-03-17 0:00 ` Charles Hixson 2000-03-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 66+ messages in thread From: Charles Hixson @ 2000-03-17 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-17 0:00 ` Charles Hixson @ 2000-03-18 0:00 ` Robert Dewar 2000-03-20 0:00 ` Charles Hixson 0 siblings, 1 reply; 66+ messages in thread From: Robert Dewar @ 2000-03-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-18 0:00 ` Robert Dewar @ 2000-03-20 0:00 ` Charles Hixson 2000-03-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 66+ messages in thread From: Charles Hixson @ 2000-03-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-20 0:00 ` Charles Hixson @ 2000-03-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Paul Graham 2000-03-16 0:00 ` Charles Hixson @ 2000-03-16 0:00 ` Robert Dewar 1 sibling, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Tucker Taft 2000-03-15 0:00 ` Paul Graham @ 2000-03-16 0:00 ` Tarjei T. Jensen 2000-03-16 0:00 ` Dale Stanbrough 2000-03-16 0:00 ` mark_biggar 2000-03-16 0:00 ` Bryce Bardin 2 siblings, 2 replies; 66+ messages in thread From: Tarjei T. Jensen @ 2000-03-16 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-16 0:00 ` Tarjei T. Jensen @ 2000-03-16 0:00 ` Dale Stanbrough 2000-03-16 0:00 ` mark_biggar 1 sibling, 0 replies; 66+ messages in thread From: Dale Stanbrough @ 2000-03-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-16 0:00 ` Tarjei T. Jensen 2000-03-16 0:00 ` Dale Stanbrough @ 2000-03-16 0:00 ` mark_biggar 1 sibling, 0 replies; 66+ messages in thread From: mark_biggar @ 2000-03-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Tucker Taft 2000-03-15 0:00 ` Paul Graham 2000-03-16 0:00 ` Tarjei T. Jensen @ 2000-03-16 0:00 ` Bryce Bardin 2 siblings, 0 replies; 66+ messages in thread From: Bryce Bardin @ 2000-03-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-15 0:00 ` Charles H. Sampson 2000-03-15 0:00 ` Tucker Taft @ 2000-03-17 0:00 ` Robert A Duff 1 sibling, 0 replies; 66+ messages in thread From: Robert A Duff @ 2000-03-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-12 0:00 ` claveman 2000-03-12 0:00 ` Robert A Duff @ 2000-03-13 0:00 ` Ted Dennison 1 sibling, 0 replies; 66+ messages in thread From: Ted Dennison @ 2000-03-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson ` (3 preceding siblings ...) 2000-03-10 0:00 ` Jean-Pierre Rosen @ 2000-03-14 0:00 ` Nick Roberts 2000-03-15 0:00 ` Robert Dewar 2000-03-17 0:00 ` William A Whitaker 5 siblings, 1 reply; 66+ messages in thread From: Nick Roberts @ 2000-03-14 0:00 UTC (permalink / raw) 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? > ... ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-14 0:00 ` Nick Roberts @ 2000-03-15 0:00 ` Robert Dewar 0 siblings, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson ` (4 preceding siblings ...) 2000-03-14 0:00 ` Nick Roberts @ 2000-03-17 0:00 ` William A Whitaker 2000-03-18 0:00 ` Robert Dewar ` (2 more replies) 5 siblings, 3 replies; 66+ messages in thread From: William A Whitaker @ 2000-03-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-17 0:00 ` William A Whitaker @ 2000-03-18 0:00 ` Robert Dewar 2000-03-18 0:00 ` Robert Dewar 2000-03-18 0:00 ` Robert Dewar 2 siblings, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-17 0:00 ` William A Whitaker 2000-03-18 0:00 ` Robert Dewar @ 2000-03-18 0:00 ` Robert Dewar 2000-03-18 0:00 ` Robert Dewar 2 siblings, 0 replies; 66+ messages in thread From: Robert Dewar @ 2000-03-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-17 0:00 ` William A Whitaker 2000-03-18 0:00 ` Robert Dewar 2000-03-18 0:00 ` Robert Dewar @ 2000-03-18 0:00 ` Robert Dewar 2000-03-22 0:00 ` William A Whitaker 2 siblings, 1 reply; 66+ messages in thread From: Robert Dewar @ 2000-03-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-18 0:00 ` Robert Dewar @ 2000-03-22 0:00 ` William A Whitaker 2000-03-23 0:00 ` Robert Dewar 0 siblings, 1 reply; 66+ messages in thread From: William A Whitaker @ 2000-03-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-22 0:00 ` William A Whitaker @ 2000-03-23 0:00 ` Robert Dewar 2000-04-06 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 66+ messages in thread From: Robert Dewar @ 2000-03-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-03-23 0:00 ` Robert Dewar @ 2000-04-06 0:00 ` Robert I. Eachus 2000-04-05 0:00 ` Marin D. Condic 0 siblings, 1 reply; 66+ messages in thread From: Robert I. Eachus @ 2000-04-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-06 0:00 ` Robert I. Eachus @ 2000-04-05 0:00 ` Marin D. Condic 2000-04-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 66+ messages in thread From: Marin D. Condic @ 2000-04-05 0:00 UTC (permalink / raw) 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. ============================================================= ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-05 0:00 ` Marin D. Condic @ 2000-04-06 0:00 ` Robert Dewar 2000-04-06 0:00 ` Marin D. Condic 2000-04-09 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 66+ messages in thread From: Robert Dewar @ 2000-04-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-06 0:00 ` Robert Dewar @ 2000-04-06 0:00 ` Marin D. Condic 2000-04-07 0:00 ` dale 2000-04-07 0:00 ` Robert Dewar 2000-04-09 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 66+ messages in thread From: Marin D. Condic @ 2000-04-06 0:00 UTC (permalink / raw) 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. ============================================================= ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-06 0:00 ` Marin D. Condic @ 2000-04-07 0:00 ` dale 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` Robert Dewar 1 sibling, 1 reply; 66+ messages in thread From: dale @ 2000-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` dale @ 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` Tarjei T. Jensen 0 siblings, 1 reply; 66+ messages in thread From: Marin D. Condic @ 2000-04-07 0:00 UTC (permalink / raw) 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] ============================================================= ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic @ 2000-04-07 0:00 ` Tarjei T. Jensen 2000-04-07 0:00 ` Marin D. Condic 0 siblings, 1 reply; 66+ messages in thread From: Tarjei T. Jensen @ 2000-04-07 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Tarjei T. Jensen @ 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` tmoran ` (3 more replies) 0 siblings, 4 replies; 66+ messages in thread From: Marin D. Condic @ 2000-04-07 0:00 UTC (permalink / raw) 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] ============================================================= ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic @ 2000-04-07 0:00 ` tmoran 2000-04-07 0:00 ` Marin D. Condic 2000-04-08 0:00 ` Dale Stanbrough ` (2 subsequent siblings) 3 siblings, 1 reply; 66+ messages in thread From: tmoran @ 2000-04-07 0:00 UTC (permalink / raw) >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? ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` tmoran @ 2000-04-07 0:00 ` Marin D. Condic 2000-04-08 0:00 ` Vladimir Olensky 2000-04-08 0:00 ` Vladimir Olensky 0 siblings, 2 replies; 66+ messages in thread From: Marin D. Condic @ 2000-04-07 0:00 UTC (permalink / raw) 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] ============================================================= ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic @ 2000-04-08 0:00 ` Vladimir Olensky 2000-04-08 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 66+ messages in thread From: Vladimir Olensky @ 2000-04-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic 2000-04-08 0:00 ` Vladimir Olensky @ 2000-04-08 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 66+ messages in thread From: Vladimir Olensky @ 2000-04-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` tmoran @ 2000-04-08 0:00 ` Dale Stanbrough 2000-04-10 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Niklas Holsti 3 siblings, 0 replies; 66+ messages in thread From: Dale Stanbrough @ 2000-04-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` tmoran 2000-04-08 0:00 ` Dale Stanbrough @ 2000-04-10 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Niklas Holsti 3 siblings, 0 replies; 66+ messages in thread From: Tarjei T. Jensen @ 2000-04-10 0:00 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Marin D. Condic ` (2 preceding siblings ...) 2000-04-10 0:00 ` Tarjei T. Jensen @ 2000-04-15 0:00 ` Niklas Holsti 2000-04-15 0:00 ` Marin D. Condic 3 siblings, 1 reply; 66+ messages in thread From: Niklas Holsti @ 2000-04-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-15 0:00 ` Niklas Holsti @ 2000-04-15 0:00 ` Marin D. Condic 0 siblings, 0 replies; 66+ messages in thread From: Marin D. Condic @ 2000-04-15 0:00 UTC (permalink / raw) 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] ====================================================================== ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-06 0:00 ` Marin D. Condic 2000-04-07 0:00 ` dale @ 2000-04-07 0:00 ` Robert Dewar 2000-04-07 0:00 ` Marin D. Condic 1 sibling, 1 reply; 66+ messages in thread From: Robert Dewar @ 2000-04-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-07 0:00 ` Robert Dewar @ 2000-04-07 0:00 ` Marin D. Condic 0 siblings, 0 replies; 66+ messages in thread From: Marin D. Condic @ 2000-04-07 0:00 UTC (permalink / raw) 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] ============================================================= ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Disallowing Pre-Defined Operations 2000-04-06 0:00 ` Robert Dewar 2000-04-06 0:00 ` Marin D. Condic @ 2000-04-09 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 66+ messages in thread From: Robert I. Eachus @ 2000-04-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2000-04-15 0:00 UTC | newest] Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-10 0:00 Disallowing Pre-Defined Operations Charles H. Sampson 2000-03-09 0:00 ` Keith Thompson 2000-03-09 0:00 ` Samuel T. Harris 2000-03-12 0:00 ` Steven Hovater 2000-03-10 0:00 ` mark_biggar 2000-03-10 0:00 ` Jean-Pierre Rosen 2000-03-11 0:00 ` Tarjei Tj�stheim Jensen 2000-03-11 0:00 ` James S. Rogers 2000-03-13 0:00 ` Tarjei T. Jensen 2000-03-13 0:00 ` Robert Dewar 2000-03-13 0:00 ` Keith Thompson 2000-03-15 0:00 ` Robert Dewar 2000-03-13 0:00 ` dmitry6243 2000-03-15 0:00 ` Charles H. Sampson 2000-03-15 0:00 ` Robert Dewar 2000-03-21 0:00 ` Charles H. Sampson 2000-03-21 0:00 ` Robert A Duff 2000-03-21 0:00 ` Robert Dewar 2000-03-12 0:00 ` claveman 2000-03-12 0:00 ` Robert A Duff 2000-03-13 0:00 ` Tarjei T. Jensen 2000-03-13 0:00 ` Robert A Duff 2000-03-13 0:00 ` Robert Dewar 2000-03-15 0:00 ` Charles H. Sampson 2000-03-15 0:00 ` Tucker Taft 2000-03-15 0:00 ` Paul Graham 2000-03-16 0:00 ` Charles Hixson 2000-03-17 0:00 ` Paul Graham 2000-03-17 0:00 ` Charles Hixson 2000-03-18 0:00 ` Robert Dewar 2000-03-20 0:00 ` Charles Hixson 2000-03-20 0:00 ` Robert Dewar 2000-03-16 0:00 ` Robert Dewar 2000-03-16 0:00 ` Tarjei T. Jensen 2000-03-16 0:00 ` Dale Stanbrough 2000-03-16 0:00 ` mark_biggar 2000-03-16 0:00 ` Bryce Bardin 2000-03-17 0:00 ` Robert A Duff 2000-03-13 0:00 ` Ted Dennison 2000-03-14 0:00 ` Nick Roberts 2000-03-15 0:00 ` Robert Dewar 2000-03-17 0:00 ` William A Whitaker 2000-03-18 0:00 ` Robert Dewar 2000-03-18 0:00 ` Robert Dewar 2000-03-18 0:00 ` Robert Dewar 2000-03-22 0:00 ` William A Whitaker 2000-03-23 0:00 ` Robert Dewar 2000-04-06 0:00 ` Robert I. Eachus 2000-04-05 0:00 ` Marin D. Condic 2000-04-06 0:00 ` Robert Dewar 2000-04-06 0:00 ` Marin D. Condic 2000-04-07 0:00 ` dale 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` Tarjei T. Jensen 2000-04-07 0:00 ` Marin D. Condic 2000-04-07 0:00 ` tmoran 2000-04-07 0:00 ` Marin D. Condic 2000-04-08 0:00 ` Vladimir Olensky 2000-04-08 0:00 ` Vladimir Olensky 2000-04-08 0:00 ` Dale Stanbrough 2000-04-10 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Niklas Holsti 2000-04-15 0:00 ` Marin D. Condic 2000-04-07 0:00 ` Robert Dewar 2000-04-07 0:00 ` Marin D. Condic 2000-04-09 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox