Fixed point design error in Ada95

Fixed point design error in Ada95

[Wayne Magor]

I don't follow this newsgroup regularly, so I'm sorry if this topic has
been discussed to death already.

I'd like to know if there is a plan to fix the design error in Ada95 that
prevents user overloading of the "*" and "/" operators for fixed-point
types (it results in an ambiguity on the call)?  The last I heard, the
GNAT compiler did not implement fixed-point correctly (as per the Ada95
spec) so this wasn't a problem for that compiler.  Is that true?  Can
other compilers do the same?

I had heard that this problem was known and was being discussed over a
year ago.  Was there a resolution, or is it being deferred to the next
version of Ada?

Is there a web site that contains Ada language issues such as this?
Also, what is the name of the Ada language maintenance committee?

Thanks,
Wayne.

Re: Fixed point design error in Ada95

[Tucker Taft]

Wayne Magor (wemagor@sym1.cca.rockwell.com_nospam) wrote:

: I don't follow this newsgroup regularly, so I'm sorry if this topic has
: been discussed to death already.

: I'd like to know if there is a plan to fix the design error in Ada95 that
: prevents user overloading of the "*" and "/" operators for fixed-point
: types (it results in an ambiguity on the call)?  

No solution has been defined.  The best workaround is to use names
other than "*" and "/" for user-defined multiply and divide operations 
for fixed-point types.  You can overload the predefined "*" and "/" for 
the type of interest with an "abstract" definition to make it less 
likely they get misused.

: ... The last I heard, the
: GNAT compiler did not implement fixed-point correctly (as per the Ada95
: spec) so this wasn't a problem for that compiler.  Is that true?  Can
: other compilers do the same?

This seems like the wrong solution.  We did discuss various explicit
pragmas to get Ada-83 compatible behavior, but I don't believe
it went anywhere.

: I had heard that this problem was known and was being discussed over a
: year ago.  Was there a resolution, or is it being deferred to the next
: version of Ada?

: Is there a web site that contains Ada language issues such as this?

www.adaic.org has an archive of comments.  If you have your own comments, 
you can send them to ada9x-mrt@inmet.com, where they will get logged, and 
redistributed to all interested parties once a day.  The format for
comments is given in the Reference Manual.  You can also get yourself
added to the "interested parties" list by sending mail to stt@inmet.com.

: Also, what is the name of the Ada language maintenance committee?

The Ada Rapporteur Group, which is part of ISO Working Group 9 (WG9)

: Thanks,
: Wayne.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Fixed point design error in Ada95

[dewarr]

In article <Ez28q4.FJL.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Wayne Magor (wemagor@sym1.cca.rockwell.com_nospam) wrote:
>
> : I don't follow this newsgroup regularly, so I'm sorry if this topic has
> : been discussed to death already.
>
> : I'd like to know if there is a plan to fix the design error in Ada95 that
> : prevents user overloading of the "*" and "/" operators for fixed-point
> : types (it results in an ambiguity on the call)?
>
> No solution has been defined.  The best workaround is to use names
> other than "*" and "/" for user-defined multiply and divide operations
> for fixed-point types.  You can overload the predefined "*" and "/" for
> the type of interest with an "abstract" definition to make it less
> likely they get misused.
>
> : ... The last I heard, the
> : GNAT compiler did not implement fixed-point correctly (as per the Ada95
> : spec) so this wasn't a problem for that compiler.  Is that true?  Can
> : other compilers do the same?
>
> This seems like the wrong solution.  We did discuss various explicit
> pragmas to get Ada-83 compatible behavior, but I don't believe
> it went anywhere.
>
> : I had heard that this problem was known and was being discussed over a
> : year ago.  Was there a resolution, or is it being deferred to the next
> : version of Ada?
>
> : Is there a web site that contains Ada language issues such as this?
>
> www.adaic.org has an archive of comments.  If you have your own comments,
> you can send them to ada9x-mrt@inmet.com, where they will get logged, and
> redistributed to all interested parties once a day.  The format for
> comments is given in the Reference Manual.  You can also get yourself
> added to the "interested parties" list by sending mail to stt@inmet.com.
>
> : Also, what is the name of the Ada language maintenance committee?
>
> The Ada Rapporteur Group, which is part of ISO Working Group 9 (WG9)
>
> : Thanks,
> : Wayne.
>
> --
> -Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
> Intermetrics, Inc.  Burlington, MA  USA
> An AverStar Company
>


The current version of GNAT Professional most certainly
implements fixed-point in a manner consistent with the RM,
and generates the very annoying ambiguities referred to
here. (it is possible that various obsolete versions of
GNAT may have done something else, but for the current
version we do not know of any errors in this area). Note
that if you use -gnat83, then of course the ambiguities
are properly suppressed.

Actually this is to be honest less annoying than you might
think. Unless you are using fixed-point as "poor man's
floating-point" [a dubious proposition now that virtually
all processors do floating-point faster than fixed-point],
it makes little sense to do something like

   function "*" (x,y : dollars_cents) return dollars_cents;

since, as in this case, there is an obvious conceptual
type error in this declaration.

Robert Dewar
Ada Core Technologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Fixed point design error in Ada95

[Wayne Magor]

dewarr@my-dejanews.com writes:

>Actually this is to be honest less annoying than you might
>think. Unless you are using fixed-point as "poor man's
>floating-point" [a dubious proposition now that virtually
>all processors do floating-point faster than fixed-point],
>it makes little sense to do something like
>
>   function "*" (x,y : dollars_cents) return dollars_cents;
>
>since, as in this case, there is an obvious conceptual
>type error in this declaration.


I'll certainly agree with you that there aren't a lot of uses for
fixed-point operator overloading.

We are running host-based simulations of avionics systems which run
on a special avionics processor.  That processor does not have
floating point, but has something called fractional arithmetic.

The fractional arithmetic does not work exactly the same way as
Ada's fixed point.  There is no overflow detection with this
hardware, which is why the operator must be overloaded in order
to properly simulate the way the software will operate in the
target.  The target compiler is an Ada83 compiler, but the host
compiler is an Ada95 compiler.

It is unfortunate that Ada95 is not 100% backward compatible in
this area, even if it has little impact on the user community.

A pragma to give Ada83 operation would be a good solution.

Thanks,
Wayne.

Re: Fixed point design error in Ada95

[dewarr]

In article <6t9dlk$e0t1@onews.collins.rockwell.com>,

> I'll certainly agree with you that there aren't a lot of uses for
> fixed-point operator overloading.
>
> We are running host-based simulations of avionics systems which run
> on a special avionics processor.  That processor does not have
> floating point, but has something called fractional arithmetic.
>
> The fractional arithmetic does not work exactly the same way as
> Ada's fixed point.  There is no overflow detection with this
> hardware, which is why the operator must be overloaded in order
> to properly simulate the way the software will operate in the
> target.  The target compiler is an Ada83 compiler, but the host
> compiler is an Ada95 compiler.
>
> It is unfortunate that Ada95 is not 100% backward compatible in
> this area, even if it has little impact on the user community.
>
> A pragma to give Ada83 operation would be a good solution.
>
> Thanks,
> Wayne.


First, a note, Ada does not require overflow detection for
fixed-point, you seem from the above to think it does, so
that is not a problem with your processor. The provision of
the Machine_Overflows attribute is intended precisely to
take care of this situation.

Second, you obviously don't need operator overloading, there
are perfectly reasonable work arounds here. They are a bit
annoying, but certainly acceptable for new code.

I agree that with legacy code you are in trouble, this is
indeed one of the most severe incompatibilities between
Ada 83 and Ada 95. I shouted around insisting that we should
fix it when it was first noticed (which was rather late), but
it seemed "too-late-at-this-stage" to do anything about it
to most people, and perhaps they were right.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

GNAT Professional ?

[Mats Weber]

dewarr@my-dejanews.com wrote:

> The current version of GNAT Professional most certainly [...]
                              ^^^^^^^^^^^^

A new name ? When will we get Visual GNAT ? :-)

Re: GNAT Professional ?

[dennison]

In article <35F91C48.87202332@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> dewarr@my-dejanews.com wrote:
>
> > The current version of GNAT Professional most certainly [...]
>                               ^^^^^^^^^^^^
>
> A new name ? When will we get Visual GNAT ? :-)
>

I'm holding out for G++   :-)

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: GNAT Professional ?

[dewarr]

In article <35F91C48.87202332@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> dewarr@my-dejanews.com wrote:
>
> > The current version of GNAT Professional most certainly [...]
>                               ^^^^^^^^^^^^
>
> A new name ? When will we get Visual GNAT ? :-)
>


We use the term GNAT Professional to distinguish this fully
supported commercial product from the unsupported
public version of GNAT.

Robert Dewar
Ada Core Technologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: GNAT Professional ?

[Paul Whittington]

What public version?

In two days it'll be one year since the last "public" release of GNAT :(

dewarr@my-dejanews.com wrote:
> 
> In article <35F91C48.87202332@elca-matrix.ch>,
>   Mats.Weber@elca-matrix.ch wrote:
> > dewarr@my-dejanews.com wrote:
> >
> > > The current version of GNAT Professional most certainly [...]
> >                               ^^^^^^^^^^^^
> >
> > A new name ? When will we get Visual GNAT ? :-)
> >
> 
> We use the term GNAT Professional to distinguish this fully
> supported commercial product from the unsupported
> public version of GNAT.
> 
> Robert Dewar
> Ada Core Technologies
> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

-- 
Paul Whittington
GrepNet, Inc.
paul@grep.net

"Even if you're on the right track you'll get
 run over if you stand still."

Will Rodgers

Re: GNAT Professional ?

[Al Christians]

Paul Whittington wrote:
> 
> What public version?
> 
> In two days it'll be one year since the last "public" release of GNAT  

In some discussion of GPL, ACT, etc, last year, here's what Robert Dewar 
explained about this last year, according to deja news:


-----------------------------------Excerpt follows --------------------

Note that people's willingness to abide by the informal ?do not
distribute? rules is based on their perception that the request is
reasonable, and is indeed based on a concern to avoid premature
distribution. If they felt that the request was based on a desire
to hoard software that was in fact ready for wide distribution, they
would not concur, and the redistribution would occur.

There is a huge philosophical difference between seeing distribution
restricted because a group of people agree that it is not a good idea
for the good of the project involved to distribute software prematurely,
and a situation in which distributable software is being hoarded.

---------------------------End of Excerpt -----------------------

Re: GNAT Professional ?

[dewarr]

In article <35FABAEA.BBA81103@grep.net>,
  Paul Whittington <paul@grep.net> wrote:
> What public version?
>
> In two days it'll be one year since the last "public" release of GNAT :(


The current publicly released version of GNAT is 3.10p, which
indeed was released about a year ago. Our general plan is
to make new public releases on approximately a 12 month
schedule.

We are fairly close to on track for that. We expect to
release GNAT Professional 3.11b in the next day or two (we
will announce that release on CLA, with details).

Assuming we have no packaging/installation problems in our
final builds, which we will determine from customer feedback,
then the corresponding 3.11p release will follow. We have had
a 3.11b-beta out for a few weeks so we do not expect any
major suprises. As always we like to be VERY sure that there
are no installation glitches in the public release, since we
know that a LOT of people will be trying to install it without
support, and we want that to be as smooth as possible.

We will make all support announcements on CLA at the
appropriate point.

Robert Dewar
Ada Core Technologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: GNAT Professional ?

[Paul Whittington]

Thanks for the WONDERFUL news Robert :)

I know that you're running a business at ACT and that the demands of
doing so have made it necessary for you to abandon your former
~$1200 per seat per year supported product offering that made GNAT a
reasonable alternative to Delphi, VC++ etc. for us.  

I'm not happy to hear that ACT's plans only include an annual public
release of GNAT :(

We are a small company, and don't need the kind of support ACT provides
in its product offerings; and we can't afford it :(  We considered 
using the public version of GNAT and relying on our own skills, as well
as the support of the wonderfully helpful folks that use GNAT around 
the world, and came to the conclusion that, unlike the Linux folks
for instance, there just wasn't enough bug-fix/enhancement activity
going on with the public release of GNAT.  It sounds like ACT's plans
support our observation :(

I guess you at ACT have surveyed the Open Source landscape and decided
that unlike some of the other products in that space (e.g. GCC, Tcl/Tk)
that provide source upgrades on a frequent basis doing so with GNAT is
not in your best interest.  Its your business, and you have to make the
call.  I do however have a request.

I request that you read the following statements, and those of anyone
else that cares to chime in, and reconsider your decision to release
only once a year or so.  

Changing your policy and releasing more frequently would not damage 
your reputation as a supplier of high-quality supported Open Source
software.  I think that's already been established.  On the contrary, 
it would serve to backup any commitment ACT has to the tradition of
the Open Source community with concrete action consistent with such a
commitment.  Thus improving your standing as an Open Source supplier.
Additionally, it would help to stimulate the development and use of 
Ada in commercial software projects, thus increasing ACT's potential
"supported product" market.  

On that point, it's not the wealthy conservative corporate IT
organizations, for the most part, that are going to be willing to 
take a chance, use Ada, and see if the Ada ROI is real.  Rather its 
the small software developer, representing equally small and aggressive
business clients that are always looking for an edge, that's going to 
be willing to find out if Ada development and maintenance is really 50%
cheaper.  If its true the small developer's clients will benefit
greatly, larger IT organizations will get interested, and the small
developer may become a larger developer who can afford ACT's supported
product offerings :)
 
In our case, we'd love to be developing state-of-the-art corporate MIS
systems with integrated E-Commerce deployed on intranets, extranets, 
and the Internet using Ada's superior software engineering features,
tasking and distributed system capabilities.  The Ada community as a
whole, and ACT specifically, could be benefiting from our work and
success, as well as the work and success of others.  

Finally, I submit that making more frequent releases would be somewhat
of an invitation to folks to get more involved in the development of
GNAT itself, and tools to support the successful use of GNAT in a
variety of domains.  Now I know that there are already many groups and
individuals involved in GNAT related development, and that more 
involvement could be as much of a problem for ACT as a benefit, but 
having played in the Delphi arena for some time now I do think that the
Ada arena could stand some growth along these lines.  I have the highest
respect and admiration for ACT's GNAT team, and more eyes, experiences,
and imaginations couldn't hurt.

TTFN Paul

dewarr@my-dejanews.com wrote:
> 
> In article <35FABAEA.BBA81103@grep.net>,
>   Paul Whittington <paul@grep.net> wrote:
> > What public version?
> >
> > In two days it'll be one year since the last "public" release of GNAT :(
> 
> The current publicly released version of GNAT is 3.10p, which
> indeed was released about a year ago. Our general plan is
> to make new public releases on approximately a 12 month
> schedule.
> 
> We are fairly close to on track for that. We expect to
> release GNAT Professional 3.11b in the next day or two (we
> will announce that release on CLA, with details).
> 
> Assuming we have no packaging/installation problems in our
> final builds, which we will determine from customer feedback,
> then the corresponding 3.11p release will follow. We have had
> a 3.11b-beta out for a few weeks so we do not expect any
> major suprises. As always we like to be VERY sure that there
> are no installation glitches in the public release, since we
> know that a LOT of people will be trying to install it without
> support, and we want that to be as smooth as possible.
> 
> We will make all support announcements on CLA at the
> appropriate point.
> 
> Robert Dewar
> Ada Core Technologies
> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

-- 
Paul Whittington
GrepNet, Inc.
paul@grep.net

"Even if you're on the right track you'll get
 run over if you stand still."

Will Rodgers

Re: GNAT Professional ?

[Markus Kuhn]

Paul Whittington wrote:
> I'm not happy to hear that ACT's plans only include an annual public
> release of GNAT :(
> 
> We considered
> using the public version of GNAT and relying on our own skills, as well
> as the support of the wonderfully helpful folks that use GNAT around
> the world, and came to the conclusion that, unlike the Linux folks
> for instance, there just wasn't enough bug-fix/enhancement activity
> going on with the public release of GNAT.  It sounds like ACT's plans
> support our observation :(

Actually, there are plans to set up a more Linux-like maintained
version of GNAT. We were just waiting on the next public release to
have an up-to-date starting point, because most of the more urgent
problems seem to be already addressed in the expected 3.11p release.

See

  http://www.cl.cam.ac.uk/~mgk25/linux-ada/

for more info and join the mailing list if you are interested to
contribute.

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: GNAT Professional ?

[Peter Hermann]

Paul Whittington <paul@grep.net> wrote:
[snip a lot]
> We are a small company, and don't need the kind of support ACT provides
> in its product offerings; and we can't afford it :(  We considered 
...
> I request that you read the following statements, and those of anyone
> else that cares to chime in, and reconsider your decision to release
> only once a year or so.  
...
> Additionally, it would help to stimulate the development and use of 
> Ada in commercial software projects, thus increasing ACT's potential
> "supported product" market.  
...
> take a chance, use Ada, and see if the Ada ROI is real.  Rather its 
...
> ...  The Ada community as a
> whole, and ACT specifically, could be benefiting from our work and
> success, as well as the work and success of others.  
...
> respect and admiration for ACT's GNAT team, and more eyes, experiences,
> and imaginations couldn't hurt.

Feedback is a precious good. ACT discourages this free income 
in-so-far that non-paying customers can't see the status of their
contributions, like thrown into a black hole. So why reporting?

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: GNAT Professional ?

[dewarr]

In article <6tlo7s$p4r$1@infosun2.rus.uni-stuttgart.de>,
 Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote:

 Feedback is a precious good. ACT discourages this free income
> in-so-far that non-paying customers can't see the status of their
> contributions, like thrown into a black hole. So why reporting?


Well of course Peter is entitled to his opinion, and is free
to make his own decisions, but just to state ACT policy here,
we will receive bug reports from users of the public version
if they are properly formatted and complete with sources, and
they do not go into a black hole, but on the contrary do get
examined sooner or later. Of course they do have rather low
priority compared to problems and questions from our paying
customers.

Providing tracking information for such bugs is not only
time consuming, but we have in the past had many experiences
of people demanding that we hurry up and fix their bug even
though they are not supported customers, in some cases people
have got quite loud and angry. It is surprising what some
people expect for free.

Anyway, we don't have the resources to track reports from
non-supported customers, so we are not able to provide this
service. If you need this kind of tracking, you need to be
a supported customer.

But we certainly thank those users of the public version, who
unlike Peter, find it worth while to take the effort to report
problems, and in the rare cases where these are actually new
bug reports, these problems do get fixed.

Robert Dewar
Ada Core Technologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Fixed point design error in Ada95

[Wayne Magor]

(Tucker Taft) writes:

>www.adaic.org has an archive of comments.  If you have your own comments, 
>you can send them to ada9x-mrt@inmet.com, where they will get logged, and 
>redistributed to all interested parties once a day.


Something is wrong with that website.  I get a site that talks about
registering domains at site.register.com.  When I go to the site the
web address changes to this:

  http://adaic.org/future.shtml

Do you know why it is doing that?  Is it still working for you?


By the way, why did the pragma to give Ada83 operation for fixed point
operators go nowhere?  Not enough interest or was it a more philosophical
reason?  Were there strong objections to adding that pragma?

Thanks,
Wayne.

Re: Fixed point design error in Ada95

[dewarr]

In article <6ta5h2$e0b2@onews.collins.rockwell.com>,
  No@Junk.Mail wrote:
>
> (Tucker Taft) writes:
>
> >www.adaic.org has an archive of comments.  If you have your own comments,
> >you can send them to ada9x-mrt@inmet.com, where they will get logged, and
> >redistributed to all interested parties once a day.
>
> Something is wrong with that website.  I get a site that talks about
> registering domains at site.register.com.  When I go to the site the
> web address changes to this:
>
>   http://adaic.org/future.shtml
>
> Do you know why it is doing that?  Is it still working for you?
>
> By the way, why did the pragma to give Ada83 operation for fixed point
> operators go nowhere?  Not enough interest or was it a more philosophical
> reason?  Were there strong objections to adding that pragma?
>
> Thanks,
> Wayne.
>

A pragma is obviously the wrong solution. It would be a nasty
kludge at best. Pragmas are not supposed to affect the legality
of programs.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Fixed point design error in Ada95

[Robert I. Eachus]

In article <6tb0j5$4rg$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes:

 > A pragma is obviously the wrong solution. It would be a nasty
 > kludge at best. Pragmas are not supposed to affect the legality
 > of programs.

   I agree.  This is one of the cases that 3.5.6(8) is supposed to
address.  The interesting thing is that Wayne Magor seems to have
identified a case of potentially general interest.  What Wayne needs
is a nonstandard fixed point type which corresponds to his hardware.
But he could build that out of a nonstandard fixed type which just got
rid of the special "*" and "/" operators.

   If someone wants to do this, be sure to take advantage of Reduced
Accuracy Subtypes from J.3:

   subtype My_Fixed is Nonstandard.Fixed delta 0.125; 

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Fixed point design error in Ada95

[dewarr]

In article <EACHUS.98Sep11203812@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> In article <6tb0j5$4rg$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes:
>
>  > A pragma is obviously the wrong solution. It would be a nasty
>  > kludge at best. Pragmas are not supposed to affect the legality
>  > of programs.
>
>    I agree.  This is one of the cases that 3.5.6(8) is supposed to
> address.  The interesting thing is that Wayne Magor seems to have
> identified a case of potentially general interest.  What Wayne needs
> is a nonstandard fixed point type which corresponds to his hardware.
> But he could build that out of a nonstandard fixed type which just got
> rid of the special "*" and "/" operators.
>
>    If someone wants to do this, be sure to take advantage of Reduced
> Accuracy Subtypes from J.3:
>
>    subtype My_Fixed is Nonstandard.Fixed delta 0.125;
>
> --
>
> 					Robert I. Eachus
>
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...
>

Well I would agree he has identified this case, but it is
a very well known one that has been much discussed. It is
one of the more serious incompatibilities, and worse than
that it is a case in which Ada 83 is far superior to Ada
95, there simply is no good solution to this in Ada 95.
I am not even sure Robert Eachus' solution of indtroducing
a peculiar non-standard fixed-point type is allowable from
an implementation point of view, but I am happy to leave
that issue moot, since in any case such an approach does
not help the user.

We are considering adding a pragma in GNAT that will cause
GNAT to implement the obvious solution which should have been
put into the language in the first place, namely a preference
rule that prefers a user defined operator to the implicit
one (that is only useful in limited circumstances).

I really don't see the argument against this preference rule,
it only affects programs that are currently illegal in
Ada 95, and legal in Ada 83, and gives the (desirable) Ada 83
semantics in this case.

The pragma is interesting, it is sort of a language extension
but actually no more than the Ada_83 switch (-gnat83 or
pragma Ada_83) itself. It is after all just a subset of the
effect of that switch, assuming that it does indeed handle
this case (which is true in the latest version of GNAT).

Robert Dewar
Ada Core Technologies


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Fixed point design error in Ada95

[Robert I. Eachus]

In article <6tejfi$7pm$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes:

  > Well I would agree he has identified this case, but it is
  > a very well known one that has been much discussed. It is
  > one of the more serious incompatibilities, and worse than
  > that it is a case in which Ada 83 is far superior to Ada
  > 95, there simply is no good solution to this in Ada 95.

    Sorry, the particular case of general interest that was identified
was for a type which did not have ANY fixed*fixed or fixed/fixed
operators.  Yes, everyone has known about the overloading problem.  But
a type with no predefined multiply and divide operations (other than
those for Integer) seems a lot easier to create.

  > I am not even sure Robert Eachus' solution of indtroducing
  > a peculiar non-standard fixed-point type is allowable from
  > an implementation point of view, but I am happy to leave
  > that issue moot, since in any case such an approach does
  > not help the user.

    Why not?  RM 3.5.6(8) seems very clear:  "An implementation may
place arbitrary restrictions on the use of such types; it is
implementation defined whether operators that are predefined for 'any
real type' are defined for a a particular nonstandard real type."  I
guess you could argue that the operations to be disallowed are of type
_universal_fixed_, but really we are talking about disallowing the
implicit conversions to _universal_fixed_ for these nonstandard types.

  > We are considering adding a pragma in GNAT that will cause
  > GNAT to implement the obvious solution which should have been
  > put into the language in the first place, namely a preference
  > rule that prefers a user defined operator to the implicit
  > one (that is only useful in limited circumstances).

    Sounds reasonable.  This is as you point out, purely a language
extension.  Actually, I personally think the right idea is to add
such a rule to 8.6(29).  This might be a good case for a non-binding
AI, to be made binding if and when it is widely supported.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...