Fixed point multiplication ambiguity

Fixed point multiplication ambiguity

[Marc A. Criley]

The following test program is compilable by Rational Apex, but
GNAT rejects it with:

tf.adb:5:38: type cannot be determined from context
tf.adb:5:38: explicit conversion to result type required

I've studied the LRM 4.5.5(13-20), but who has the correct
interpretation doesn't quite jump out at me, though I am
leaning towards one over the other.
--------------------

procedure Tf is

    D : Duration := 5.0;

    Dec_Delt : Integer := Integer (D * 10.0 + 0.5);

begin
    null;
end Tf;

-----------------------
Marc A. Criley
Chief Software Architect
Lockheed Martin M&DS
(610) 354-7861

Re: Fixed point multiplication ambiguity

[Robert I. Eachus]

In article <369E14CA.90715966@lmco.com> "Marc A. Criley" <marc.a.criley@lmco.com> writes:

  > I've studied the LRM 4.5.5(13-20), but who has the correct
  > interpretation doesn't quite jump out at me, though I am
  > leaning towards one over the other.

   I argee with GNAT that the code as written is illegal.  My guess is
that the other compiler is incorrectly applying 8.6(29) to the
addition of _universal_fixed_ and _root_real_.

--

					Robert I. Eachus

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

Re: Fixed point multiplication ambiguity

[Matthew Heaney]

"Marc A. Criley" <marc.a.criley@lmco.com> writes:

> procedure Tf is
> 
>     D : Duration := 5.0;
> 
>     Dec_Delt : Integer := Integer (Duration'(D * 10.0) + 0.5);
                                     ^^^^^^^^^^        ^

> 
> begin
>     null;
> end Tf;

Add the type qualification I've indicated.

D * 10.0 returns universal fixed, and you tried to add a number to that
product.  Is addition defined for universal fixed + universal real?  I
think you have to explicitly state the type of the universal fixed
product before you can do anything else to it.

Re: Fixed point multiplication ambiguity

[Tom Moran]

>The following test program is compilable by Rational Apex, but
>GNAT rejects it with:
  ObjectAda and Janus both accept it without complaint.

Re: Fixed point multiplication ambiguity

[Tucker Taft]

Marc A. Criley (marc.a.criley@lmco.com) wrote:

: The following test program is compilable by Rational Apex, but
: GNAT rejects it with:

: tf.adb:5:38: type cannot be determined from context
: tf.adb:5:38: explicit conversion to result type required

: I've studied the LRM 4.5.5(13-20), but who has the correct
: interpretation doesn't quite jump out at me, though I am
: leaning towards one over the other.
: --------------------

: procedure Tf is

:     D : Duration := 5.0;

:     Dec_Delt : Integer := Integer (D * 10.0 + 0.5);

This is legal.  Overload resolution interprets "D * 10.0" as returning
universal_fixed.  This is implicitly convertible to Duration (as well
as any other fixed point type), as is 0.5.  Presuming there is no 
other fixed-point type with a directly visible "+", this should resolve, 
and use the "+" of Duration.

: begin
:     null;
: end Tf;

: -----------------------
: Marc A. Criley
: Chief Software Architect
: Lockheed Martin M&DS
: (610) 354-7861

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

Re: Fixed point multiplication ambiguity

[robert_dewar]

In article <F5KMxx.3L8.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Marc A. Criley (marc.a.criley@lmco.com) wrote:
>
> : The following test program is compilable by Rational
Apex, but
> : GNAT rejects it with:
>
> : tf.adb:5:38: type cannot be determined from context
> : tf.adb:5:38: explicit conversion to result type
required
>
> : I've studied the LRM 4.5.5(13-20), but who has the
correct
> : interpretation doesn't quite jump out at me, though I
am
> : leaning towards one over the other.
> : --------------------
>
> : procedure Tf is
>
> :     D : Duration := 5.0;
>
> :     Dec_Delt : Integer := Integer (D * 10.0 + 0.5);
>
> This is legal.  Overload resolution interprets "D * 10.0"
as returning
> universal_fixed.  This is implicitly convertible to
Duration (as well
> as any other fixed point type), as is 0.5.  Presuming
there is no
> other fixed-point type with a directly visible "+", this
should resolve,
> and use the "+" of Duration.
>
> : begin
> :     null;
> : end Tf;
>
> : -----------------------
> : Marc A. Criley
> : Chief Software Architect
> : Lockheed Martin M&DS
> : (610) 354-7861
>
> --
> -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
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Fixed point multiplication ambiguity

[Nick Roberts]

Tucker Taft wrote in message ...
[...]
|: procedure Tf is
|
|:     D : Duration := 5.0;
|
|:     Dec_Delt : Integer := Integer (D * 10.0 + 0.5);
|
|This is legal.  Overload resolution interprets "D * 10.0" as returning
|universal_fixed.  This is implicitly convertible to Duration (as well
|as any other fixed point type), as is 0.5.  Presuming there is no
|other fixed-point type with a directly visible "+", this should resolve,
|and use the "+" of Duration.
[...]

Yes, this is legal, but Tucker's explanation is not precisely right. The
D*10.0 does resolve as Tucker says, giving a universal_fixed. The 0.5
literal is a universal_real. Thus adding them gives us the pattern
"+"(universal_fixed,universal_real) return unknown. However, it is the rule
in RM 8.6 [29,30] preferring root types that allows this to be resolved into
the pattern "+"(root_real,root_real) return root_real implied by RM 4.5.3
[2]. So the expression D*10.0+0.5 returns a value of type root_real, which
can then be converted to an integer and assigned to Dec_Delt.

However, the expression Integer(D*10.0+0.5) causes a root_real addition and
conversion to integer to be executed dynamically. It may be slightly more
efficient to use the expression Integer(D*10+0.5) instead, causing the
multiplication, addition, and conversion to all be carried out on the type
Duration. For some implementations, operations on the type Duration will
execute slightly faster than the same operations on the type root_real. On
the other hand, some implementations' optimisers will effectively make this
change automatically.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Fixed point multiplication ambiguity

[Tucker Taft]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:

: Tucker Taft wrote in message ...
: [...]
: |: procedure Tf is
: |
: |:     D : Duration := 5.0;
: |
: |:     Dec_Delt : Integer := Integer (D * 10.0 + 0.5);
: |
: |This is legal.  Overload resolution interprets "D * 10.0" as returning
: |universal_fixed.  This is implicitly convertible to Duration (as well
: |as any other fixed point type), as is 0.5.  Presuming there is no
: |other fixed-point type with a directly visible "+", this should resolve,
: |and use the "+" of Duration.
: [...]

: Yes, this is legal, but Tucker's explanation is not precisely right. 

I believe I am right (see below).

: ... The D*10.0 does resolve as Tucker says, giving a universal_fixed. The 0.5
: literal is a universal_real. Thus adding them gives us the pattern
: "+"(universal_fixed,universal_real) return unknown. However, it is the rule
: in RM 8.6 [29,30] preferring root types that allows this to be resolved into
: the pattern "+"(root_real,root_real) return root_real implied by RM 4.5.3
: [2]. So the expression D*10.0+0.5 returns a value of type root_real, which
: can then be converted to an integer and assigned to Dec_Delt.

Sorry, but you are wrong.  Universal_fixed is *not* implicitly convertible
to root_real.  It is implicitly convertible to any *fixed point* type,
and to universal_real (because any real type is implicitly convertible
both *to* and *from* universal real), but *not* to root_real (I realize 
only a died-in-the-wool language lawyer will believe this reasoning).

: However, the expression Integer(D*10.0+0.5) causes a root_real addition and
: conversion to integer to be executed dynamically. 

No, this expression uses Duration's "+", because this is effectively
equivalent to:
   Integer(Duration(D*10.0)+Duration(0.5))

The whole fixed-point multiplication model is pretty obscure, unfortunately.

: ...
: -------------------------------------------
: Nick Roberts
: -------------------------------------------

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

Re: Fixed point multiplication ambiguity

[robert_dewar]

In article <F696u2.Cp.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> The whole fixed-point multiplication model is pretty
> obscure, unfortunately.

I agree with Tuck's analysis in its entirety. Note that
the model may be a bit obscure, but the normal practice
of qualifying intermediate results returned by
multiplication using an explicit conversion removes
this obscurity.

I actually find the implicit use of Duration MOST
unfortunate. GNAT finds it worrying enough to emit a
warning:

  1. procedure Tf is
  2.     D : Duration := 5.0;
  3.     Dec_Delt : Integer := Integer (D * 10.0 + 0.5)
                                                 |
   >>> warning: Universal-fixed expression interpreted as
       type "Standard.Duration"

  4. begin
  5.    null;
  6. end;

Since it really seems strange to have Duration creeping
in here. Note that this is NOT related to the declaration
of D as being of type Duration, it would happen if D were
of some other fixed point type, as long as it was not a
visible type at the point of the expression.

If two fixed-point types *are* visible, then GNAT says

  1. procedure Tf2 is
  2.     type r is delta 1.0 range -10.0 .. +10.0;
  3.     D : r := 5.0;
  4.     Dec_Delt : Integer := Integer (D * 10.0 + 0.5);
                                                 |
     >>> ambiguous universal_fixed_expression
     >>> possible interpretation as type Standard.Duration"
     >>> possible interpretation as type "r" defined at
         line 2

     5. begin
     6.    null;
     7. end;

It could still confuse a beginner :-) but it is hard to
see how one can do better error-message wise!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Fixed point multiplication ambiguity

[Nick Roberts]

Tucker Taft wrote in message ...
[...]
|: ... The D*10.0 does resolve as Tucker says, giving a universal_fixed. The
0.5
|: literal is a universal_real. Thus adding them gives us the pattern
|: "+"(universal_fixed,universal_real) return unknown. However, it is the
rule
|: in RM 8.6 [29,30] preferring root types that allows this to be resolved
into
|: the pattern "+"(root_real,root_real) return root_real implied by RM 4.5.3
|: [2]. So the expression D*10.0+0.5 returns a value of type root_real,
which
|: can then be converted to an integer and assigned to Dec_Delt.
|
|Sorry, but you are wrong.  Universal_fixed is *not* implicitly convertible
|to root_real.

Tucker is, of course, quite right. My slip.

|It is implicitly convertible to any *fixed point* type,
|and to universal_real (because any real type is implicitly convertible
|both *to* and *from* universal real), but *not* to root_real (I realize
|only a died-in-the-wool language lawyer will believe this reasoning).


|: However, the expression Integer(D*10.0+0.5) causes a root_real addition
and
|: conversion to integer to be executed dynamically.
|
|No, this expression uses Duration's "+", because this is effectively
|equivalent to:
|   Integer(Duration(D*10.0)+Duration(0.5))


I am not arguing with this, but which rule (or rules) in the RM specify the
above interpretation, please? I've searched and searched (even the AI95s)!
(Then again, I reckon my brain must be coming up for it's 20,000 mile
service anyway ;-)

|The whole fixed-point multiplication model is pretty obscure,
unfortunately.


But then I would say that, in general, the RM95 does an amazingly good job
of pinning down a slippery monster. I hope I haven't added to the confusion
too much :-(

Just off for a slice of humble pie. Tuck remains champ :-)
-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Fixed point multiplication ambiguity

[Tucker Taft]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:

: |... [ Integer(D*10.0 + 0.5) ] is effectively equivalent to:
: |   Integer(Duration(D*10.0)+Duration(0.5))


: I am not arguing with this, but which rule (or rules) in the RM specify the
: above interpretation, please? I've searched and searched (even the AI95s)!
: (Then again, I reckon my brain must be coming up for it's 20,000 mile
: service anyway ;-)

  RM95 3.4.1(6-7) introduces the universal numeric types.

  RM95 4.2(8) says that a real literal is of type universal-real.

  RM95 4.5.5(18) defines the multiplication operator:

    univ-fixed * univ-fixed => univ-fixed 

  RM95 8.6(21) indicates that any fixed-point type is acceptable
  when the expected type is universal-fixed, as is any universal
  type that "covers" universal-fixed (e.g. universal-real)
  (i.e., any fixed-point type is implicitly convertible to
  universal-fixed, as is universal-real).

  RM95 8.6(24) indicates that universal fixed is acceptable
  when the expected type is any specific fixed-point type 
  (i.e., universal fixed is implicitly convertible to any
  fixed-point type).

  RM95 8.6(28) indicates that if there is exactly one acceptable
  interpretation for a complete context, then that one is chosen.

There is only one directly visible "*" operator which can "accept"
one operand of type Duration (D), and one univeral-real operand (10.0):
univ-fixed * univ-fixed => univ-fixed.

There is also only one directly visible "+" operator which can "accept"
one universal-fixed operand (D*10.0) and one universal-real operand
(the literal 0.5): Duration + Duration => Duration.

Hence, the only acceptable interpretation is the one which
is effectively equivalent to: 

    Integer(Duration(D*10.0) + Duration(0.5))

Q.E.D. (I hope ;-).

: -------------------------------------------
: Nick Roberts
: -------------------------------------------

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

Re: Fixed point multiplication ambiguity

[Nick Roberts]

I am much chuffed by your time and effort in replying Tuck. Big big thanks.

The wording I was missing out on was "For a complete context" (RM 8.6 [31],
the 'context' being defined by RM 8.6 [4]). Now it all fits into place (and
you can actually _see_ the steam coming off the top of my head ;-).

What this means is that a compiler _deeply searches_ a complete context for
a single, unambiguous, interpretation: in this case, the one with all
Durations. I was simply assuming that Ada wouldn't be designed this way (I
wouldn't have :-).

Why? Because it means that the search space could, theoretically, end up
getting rather big. But, of course, in practice, it's very unlikely to get
_too_ big (especially considering the big search spaces modern compilers
cover in the name of optimisation). It also means that sometimes an
interpretation will be 'non-obvious' to someone reading the code. But that's
the way it is. Maybe a change needed for Ada 200X?

Okay, I'm a cheeky so-and-so (you may have noticed), so my next question is:
do you recommend I try developing 'tree pruning' techniques to cut down the
search space (searching for interpretations), or just search it all 'brute
force'?

Again, thanks.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Fixed point multiplication ambiguity

[Tucker Taft]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:

: ...
: What this means is that a compiler _deeply searches_ a complete context for
: a single, unambiguous, interpretation: in this case, the one with all
: Durations. I was simply assuming that Ada wouldn't be designed this way (I
: wouldn't have :-).

It doesn't actually need to search that far.  For example, in a
case like this, it is only concerned with directly visible
operators, and that is a pretty well-defined set.  The thing
which makes it a bit more complicated in many Ada compilers is
that all the predefined operators are not really inserted into the symbol
table, but instead "spring" into existence when referenced.

The one place where things can get truly exponential is in the
following:

    (a,b) & (c,d) & (e,f) & (g,h) & ...

The compiler is not "allowed" to look inside the aggregates until
it has determined what composite type each must be, by using context.
Because there are 4 predefined "&" operators for every array type,
and in the case of an array-of-composite, you could legitimately
use all 4 different operators in a single expression like the above,
some sort of tree-pruning is necessary.

As a little anecdote here, we had one user who rather than simply writing
a large aggregate as:

    (a,b,c,d,
     e,f,g,h,
     i,j,k,l, ... [for several pages]

They instead chose to write it as:

    (a,b,c,d) &
    (e,f,g,h) &
    (i,j,k,l) & ... [for several pages]

It blew out several gourds...

In all other cases, a "straightforward" (yeah, right) bottom-up
enumeration of all possibilities, with removal of illegal combinations 
on the way up, is generally efficient enough.

: Why? Because it means that the search space could, theoretically, end up
: getting rather big. But, of course, in practice, it's very unlikely to get
: _too_ big (especially considering the big search spaces modern compilers
: cover in the name of optimisation). It also means that sometimes an
: interpretation will be 'non-obvious' to someone reading the code. But that's
: the way it is. Maybe a change needed for Ada 200X?

I could see some change in the handling of fixed-point multiplication
in Ada 200X.  It has been a source of incompatibilities and surprises.
Other than that, though, any significant change to the overload
resolution rules is *extremely* unlikely in my view.

: Okay, I'm a cheeky so-and-so (you may have noticed), so my next question is:
: do you recommend I try developing 'tree pruning' techniques to cut down the
: search space (searching for interpretations), or just search it all 'brute
: force'?

Are you building an Ada compiler?  If so, I would suggest investing
in head examination techniques ;-).

: Again, thanks.

: -------------------------------------------
: Nick Roberts
: -------------------------------------------

-Tuck

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

Re: Fixed point multiplication ambiguity

[Robert I. Eachus]

In article <F6BzAA.KKI.0.-s@inmet.camb.inmet.com> stt@houdini.camb.inmet.com (Tucker Taft) writes:

 > I could see some change in the handling of fixed-point multiplication
 > in Ada 200X.  It has been a source of incompatibilities and surprises.
 > Other than that, though, any significant change to the overload
 > resolution rules is *extremely* unlikely in my view.

   Note that putting some other visible fixed-point type in Standard
would fix the most surprising case discussed above.  It would never be
possible then for Duration to appear out of the blue.
--

					Robert I. Eachus

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

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[Nick Roberts]

Tucker Taft wrote in message ...
|Are you building an Ada compiler?  If so, I would suggest investing
|in head examination techniques ;-).


Yes (he admits sheepishly). And yes, agreed.

But ... people have the strangest passions (climbing mountains, leaping out
of aircraft, standing for presidential election), and mine happens to be
building an Ada compiler. It's a bit like sex: if nobody did it, there would
be no more people! Well, somebody's got to build Ada compilers: if nobody
did it, there would be no Ada compilers.

Still munching on my Muchnick :-)

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[Chris Morgan]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> But ... people have the strangest passions (climbing mountains, leaping out
> of aircraft, standing for presidential election), and mine happens to be
> building an Ada compiler. It's a bit like sex: if nobody did it, there would
> be no more people! Well, somebody's got to build Ada compilers: if nobody
> did it, there would be no Ada compilers.

Presumably there are some "itches" in the design of GNAT/GCC that you
would like to scratch by building your own alternative. I have to
wonder though whether you wouldn't get more satisfaction out of
building extended versions of GNAT. There have been some discussions
of language extensions on this group, including one for which Tucker
Taft eventually gave the most popular new syntax.

I am reminded of some code I once tried to rewrite at a Wall St
firm. It was so horrible to read I thought I would replace it with
clean code, but the more I coded, the more I understood the old
horrible stuff, and eventually I saw the fix was 5 lines long (with
one cheat) and I had more confidence in those 5 lines than a new
implementation (given that there was some interaction with other bad
code). [Aside : Of course that did no favours to the next poor chap to
look at the code, but that's the way that firm works, anyway it was
C++.]

Still, if you want to try, it's a worthy challenge, let us know when
your parser runs faster than GNAT's ;) I once thought about it myself
but I decided my interest lay in how correct code is translated
(implementation of language constructs) whereas real compilers have to
do a lot of drudgery handling all those pesky user errors.

Chris
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[robert_dewar]

A very nice project would be to try to add full garbage
collection to GNAT ....

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[news.oxy.com]

robert_dewar@my-dejanews.com wrote in message
<79asc3$cq3$1@nnrp1.dejanews.com>...
>A very nice project would be to try to add full garbage
>collection to GNAT ....


Yes ,

No doubt, a lot of people using GNAT would be very happy as it would save
them a lot of time for doing their own programming instead of inventing
their own garbage collection methods.

LRM says:
27 Implementations are permitted, but not required, to provide garbage
collection (see 13.11.3).

Probably it is right  time for that.
Moreover, any Ada implementation targeted for Java code generation should
probably have this facility.


Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunications specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[robert_dewar]

In article <79c2ch$j1c$1@remarQ.com>,
  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
> No doubt, a lot of people using GNAT would be very happy
> as it would save them a lot of time for doing their own
> programming instead of inventing their own garbage
> collection methods.

So, Vladimir, put all the effort you put into writing
posts to CLA into learning how to do this, and get busy.
That's the *real* way to help Ada :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[David Botton]

Bravo.

> So, Vladimir, put all the effort you put into writing
> posts to CLA into learning how to do this, and get busy.
> That's the *real* way to help Ada :-)

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[Tom Moran]

>So, Vladimir, put all the effort you put into writing
>posts to CLA into learning how to do this, and get busy.
>That's the *real* way to help Ada :-)
 The Ada boat needs both oarsmen and navigators.

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[news.oxy.com]

robert_dewar@my-dejanews.com wrote in message
<79ckt6$rp3$1@nnrp1.dejanews.com>...

>>> robert_dewar@my-dejanews.com wrote in message
>>>      <79asc3$cq3$1@nnrp1.dejanews.com>...
>>>A very nice project would be to try to add full garbage
>>>collection to GNAT ....

>>In article <79c2ch$j1c$1@remarQ.com>,
>>  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
>> No doubt, a lot of people using GNAT would be very happy
>> as it would save them a lot of time for doing their own
>> programming instead of inventing their own garbage
>> collection methods.
>
>So, Vladimir, put all the effort you put into writing
>posts to CLA into learning how to do this, and get busy.
>That's the *real* way to help Ada :-)



Congratulations Mr. Robert Devar !
Wonderful answer !

It is interesting to know whether your post represents ACT official position
(as an Ada  software company) to the current and potential/future needs of
Ada users or this is something else ?

If this is an official position of ACT then it is very sad for Ada community
and this is shame for ACT. Such position won't attract new people and
organizations to Ada . Just the opposite it may only  divert them from it.

Just imagine - Person representing Ada company in this forum tells that it
would be nice to implement something that exists in LRM but is not still
implemented (because it is not mandatory). Some other person reply that this
would be great and receives the answer saying something like this: " go off,
do it yourself and do not bother us any more ". Such position just kills
Ada. It works as repellent.
I have doubt that after reading such things  anyone new to Ada could
consider it as a valuable choice for doing something serious. Not only
quality of the language itself  has an impact on such decisions but more the
attitude of the software companies that selling Ada compilers, tools and
services.

Expected and well understood answer would be: " We are glad to make Ada
users more happy and we will do whatever we can to make this happen. We have
such and such plans for future and we will do our best  to put then into
existence as soon as possible. Please tell us more about your needs and you
will see them implemented in our compiler/tools "

A lot of bright people outside Ada club have rather negative opinion of Ada
and do not wont to spend their time and efforts in doing anything in Ada.
Small example: I recently asked professor  Douglas C. Schmidt  about his ACE
(Adaptive Communication Environment
http://siesta.cs.wustl.edu/~schmidt/ACE.html  ):
----------------------------------------------------------------------------
----------------------
||>           Are there (or were) any intentions to write it in Ada 95?
||
||   No.
||
||>           Are there any reasons why this can not be done?
||
||  No, other than no one seems very interested in Ada 95 anymore!
----------------------------------------------------------------------------
---------------------------
This is opinion of the professor who is Director of the Center
for Distributed Object Computing in the Department of Computer Science in
Washington University in Saint Louis.
He is very bright person and he has a lot of sponsors from military and
aerospace industry that could be sponsors of ACT as well (provided that ACT
would do  .
Surprisingly http://www.adaresource.org/  has a lot of references to Douglas
C. Schmidt  works and to his ACE and TAO (real-time Corba implementation
based on ACE).

One of the answers to the question why no one seems to be very interested in
Ada anymore lies in Mr. Devar phrase: "go off and do it yourself and do not
bother us anymore".
Here I would also remind Mr. Devar reply to my remark concerning GLADE
distribution with GNAT 3.11 for Windows NT/95/98. It tells about the
same:-"go off and do it yourself and do not bother us anymore".

As far as garbage collection concerned   Mr. Devar probably did not read my
other message posted yearlier than mentioned at the top that I've already
did it for myself (as a small experiment).



Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunications specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.


P.S. Sorry for being late with the answer. I was out of the loop for some
time busy with the other things.

Re: Garbage collection - was Re: Building a compiler

[Samuel Mize]

news.oxy.com <Vladimir_Olensky@oxy.com> wrote:

> robert_dewar@my-dejanews.com wrote in message
...
>>>In article <79c2ch$j1c$1@remarQ.com>,
>>>  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
>>> No doubt, a lot of people using GNAT would be very happy
>>> as it would save them a lot of time for doing their own
>>> programming instead of inventing their own garbage
>>> collection methods.
>>
>>So, Vladimir, put all the effort you put into writing
>>posts to CLA into learning how to do this, and get busy.
>>That's the *real* way to help Ada :-)
...
> It is interesting to know whether your post represents ACT official position
> (as an Ada  software company) to the current and potential/future needs of
> Ada users or this is something else ?
...
[describes Dewar's answer as]
>" go off,
> do it yourself and do not bother us any more ".

Mr. Dewar's writing style is often misunderstood.  He comes across
to some people as being much more sarcastic than he intends to.
I don't think he meant to drive you off.

But he is a little curt on this subject, probably because it's been
discussed here many, many times.  People are always happy to tell ACT
what unfunded project they should do next.  ACT has to focus on the
things that people are willing and able to pay for.

I would say, based on previous c.l.a discussions of garbage collection,
that he meant to say:

- don't go off, come in to the community of GNAT developers (which
  is MUCH larger than ACT).

- don't do it yourself, do it in the company of the other people who
  complain about GNAT not having garbage collection.  Start a project.

- Share it with us and tell us all about it.

> As far as garbage collection concerned   Mr. Devar probably did not read my
> other message posted yearlier than mentioned at the top that I've already
> did it for myself (as a small experiment).

Looks like that message has scrolled off my newsreader.  What kind of
garbage collection did you implement?  Is it integrated with the GNAT
compiler?  Did you post all the details?  Is your code available for
others to use?  Did you submit it to whoever maintains GNAT code?

ACT is hardly the entire Ada community.  You don't need Mr. Dewar's
permission to upgrade the GNAT compiler.

By the way, Mr. Dewar is posting for himself, not as ACT -- I assume
that's one reason he's posting via Deja News.  As such, he's posting
for his own reasons.  I agree, he may not have read your prior post,
and he has no duty to do so.

I'll dig in Deja News and see what you posted earlier.  If you did
implement a garbage collection scheme that would enhance GNAT, there
are a number of people here who would like to share it.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Garbage collection - was Re: Building a compiler

[Samuel Mize]

Samuel Mize <smize@imagin.net> wrote:

> news.oxy.com <Vladimir_Olensky@oxy.com> wrote:
>> As far as garbage collection concerned   Mr. Devar probably did not read my
>> other message posted yearlier than mentioned at the top that I've already
>> did it for myself (as a small experiment).
> 
> Looks like that message has scrolled off my newsreader.  What kind of
> garbage collection did you implement?
...
> I'll dig in Deja News and see what you posted earlier.

OK, I looked it up.  What you say you did was:
> ... I created and tested small top-level package that performs
> user defined garbage collection using controlled access type to the
> controlled class-wide types. This package (just small experiment or
> exercise) proved to be working fine and I an going to use it  later to
> create hierarchy of controlled types with automatic garbage collection.

So, it isn't a general garbage collector integrated into the compiler.
It's a controlled type that cleans itself up -- I assume it's using
reference counting.

That's a useful exercise, and I'd like to see you post the code.

But it's not particularly related to the level of effort it would take
to do a full-up, behind-the-scenes garbage collector integrated into
the compiler.

I'm not aware of a project to develop garbage collection for GNAT --
anybody, is there one going?  ACT isn't planning to do it.  Is the
Ada community going to do it?

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[dewar]

In article <7ah65p$4ag$1@remarQ.com>,
  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:

> Expected and well understood answer would be: " We are
> glad to make Ada users more happy and we will do whatever
> we can to make this happen. We have such and such plans
> for future and we will do our best  to put then into
> existence as soon as possible. Please tell us more about
> your needs and you will see them implemented in our
> compiler/tools "

That is of course our attitude to our customers, and indeed
our customers are not shy about telling us what they would
like to see, and as you can see from the features list, we
continue to make major additions to GNAT.

Unfortunately, none of our customers has any interest in
garbage collection, so that is nowhere on our radar screen
for possible future enhancements (except of course in
JGNAT, where it is standard).

It is precisely this kind of feature which would be nice to
have, but which no paying customers are interested in, that
is a good target for volunteers to implement, and there
have been some such efforts in the past (most notably the
DOS port of GNAT).

You may argue that we should put in garbage collection
because it would gain customers, but our market analysis
which I suspect is in a bit better position than you to
guess right here says that this simply is not a critical
feature to the Ada community. The fact that every other
Ada vendor has made the same decision is indicative that
this judgment is correct.

> Here I would also remind Mr. Devar reply to my remark
> concerning GLADE distribution with GNAT 3.11 for Windows
> NT/95/98. It tells about the same:-"go off and do it
> yourself and do not bother us anymore".

Well here you are asking us to invest effort in a
particular area which for the moment we choose not to.
Again, we do not think this is a critical market
requirement. Especially because lots of people have
managed to do this on their own perfectly fine (we somewhat
feel that anyone who cannot build GLADE is unlikely to be
able to use it effectively in practice). We may build a
binary release of GLADE in the future, but we have no plans
to do it right now.
>
> As far as garbage collection concerned   Mr. Devar
> probably did not read my other message posted yearlier
> than mentioned at the top that I've already did it for
> myself (as a small experiment).

It is of course trivial to implement conservative garbage
collection, and any number of the commercial tools in this
area work fine with GNAT. That is of course a given, but
that is not what I was talking about, I was talking about
implementing full, accurate, compacting garbage collection
of the type expected in an Algol-68 compiler. That's a big
project, probably several person months from someone who
knows what they are doing, longer for someone who has to
learn.

Once again, Vladimir, it seems a pity that you don't put
all this energy into actually achieving something useful
in the Ada field, there certainly are lots of useful things
that can be done. We do a lot of development work, and
every new version of GNAT contains many new features
(basically the features that we and our serious users
consider the most important), but we can't do everything.
The point of opening sources is to encourage others to
help. You have all the raw materials to do lots of
interesting development, why not try it!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[David Botton]

I would be happy to post the source code of your "small experiment" on The Ada
Source Code Treasury - http://www.botton.com/ada. Despite the fact that Dr.
Dewar doesn't exactly have the best on-line people personality, he has also
contributed his hard work and time to producing GNAT and making /keeping it
public.

David Botton


>
> As far as garbage collection concerned   Mr. Devar probably did not read my
> other message posted yearlier than mentioned at the top that I've already
> did it for myself (as a small experiment).
>

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[AdaHag]

news.oxy.com wrote:

> Congratulations Mr. Robert Devar !
> Wonderful answer !

> Just imagine - Person representing Ada company in this forum tells that it
> would be nice to implement something that exists in LRM but is not still
> implemented (because it is not mandatory). Some other person reply that this
> would be great and receives the answer saying something like this: " go off,
> do it yourself and do not bother us any more ". Such position just kills
> Ada. It works as repellent.

Right On ! Give it to the "we've discussed this before" "you don't know what 
you're talking about" "hearsay" prick ! ( but I think you'd better batton down
the hatch ... there seems to be a strong brown nosing collective operating on CLA )

> Regards,
> Vladimir Olensky

Anonymous public moral support offered. carry on CLA posting Vladimir.

Re: Garbage collection - was Re: Building a compiler (was: Fixed point multiplication ambiguity)

[Steven Hovater]

Vladimir -

Read your comments, and I suppose you have a non-business perspective. Not
being
critical, but it seems one has to weigh every added feature versus the cost in
engineer development
and testing time, and compare that to the business case - if you'll gain
business by adding an
obscure feature, then it might be worth it - but engineer time is precious, and
should be spent where
it'll get the most mileage.

(the above is my personal opinion,  I'm not speaking for Rational.)

Regards,
Steve

"news.oxy.com" wrote:

> robert_dewar@my-dejanews.com wrote in message
> <79ckt6$rp3$1@nnrp1.dejanews.com>...
>
> >>> robert_dewar@my-dejanews.com wrote in message
> >>>      <79asc3$cq3$1@nnrp1.dejanews.com>...
> >>>A very nice project would be to try to add full garbage
> >>>collection to GNAT ....
>
> >>In article <79c2ch$j1c$1@remarQ.com>,
> >>  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
> >> No doubt, a lot of people using GNAT would be very happy
> >> as it would save them a lot of time for doing their own
> >> programming instead of inventing their own garbage
> >> collection methods.
> >
> >So, Vladimir, put all the effort you put into writing
> >posts to CLA into learning how to do this, and get busy.
> >That's the *real* way to help Ada :-)
>
> Congratulations Mr. Robert Devar !
> Wonderful answer !
>
> It is interesting to know whether your post represents ACT official position
> (as an Ada  software company) to the current and potential/future needs of
> Ada users or this is something else ?
>
> If this is an official position of ACT then it is very sad for Ada community
> and this is shame for ACT. Such position won't attract new people and
> organizations to Ada . Just the opposite it may only  divert them from it.
>
> Just imagine - Person representing Ada company in this forum tells that it
> would be nice to implement something that exists in LRM but is not still
> implemented (because it is not mandatory). Some other person reply that this
> would be great and receives the answer saying something like this: " go off,
> do it yourself and do not bother us any more ". Such position just kills
> Ada. It works as repellent.
> I have doubt that after reading such things  anyone new to Ada could
> consider it as a valuable choice for doing something serious. Not only
> quality of the language itself  has an impact on such decisions but more the
> attitude of the software companies that selling Ada compilers, tools and
> services.
>
> Expected and well understood answer would be: " We are glad to make Ada
> users more happy and we will do whatever we can to make this happen. We have
> such and such plans for future and we will do our best  to put then into
> existence as soon as possible. Please tell us more about your needs and you
> will see them implemented in our compiler/tools "
>
> A lot of bright people outside Ada club have rather negative opinion of Ada
> and do not wont to spend their time and efforts in doing anything in Ada.
> Small example: I recently asked professor  Douglas C. Schmidt  about his ACE
> (Adaptive Communication Environment
> http://siesta.cs.wustl.edu/~schmidt/ACE.html  ):
> ----------------------------------------------------------------------------
> ----------------------
> ||>           Are there (or were) any intentions to write it in Ada 95?
> ||
> ||   No.
> ||
> ||>           Are there any reasons why this can not be done?
> ||
> ||  No, other than no one seems very interested in Ada 95 anymore!
> ----------------------------------------------------------------------------
> ---------------------------
> This is opinion of the professor who is Director of the Center
> for Distributed Object Computing in the Department of Computer Science in
> Washington University in Saint Louis.
> He is very bright person and he has a lot of sponsors from military and
> aerospace industry that could be sponsors of ACT as well (provided that ACT
> would do  .
> Surprisingly http://www.adaresource.org/  has a lot of references to Douglas
> C. Schmidt  works and to his ACE and TAO (real-time Corba implementation
> based on ACE).
>
> One of the answers to the question why no one seems to be very interested in
> Ada anymore lies in Mr. Devar phrase: "go off and do it yourself and do not
> bother us anymore".
> Here I would also remind Mr. Devar reply to my remark concerning GLADE
> distribution with GNAT 3.11 for Windows NT/95/98. It tells about the
> same:-"go off and do it yourself and do not bother us anymore".
>
> As far as garbage collection concerned   Mr. Devar probably did not read my
> other message posted yearlier than mentioned at the top that I've already
> did it for myself (as a small experiment).
>
> Regards,
> Vladimir Olensky
> (vladimir_olensky@yahoo.com)
> (Vladimir_Olensky@oxy.com)
> Telecommunications specialist,
> Occidental C.I.S. Service, Inc. ( www.oxy.com )
> Moscow,
> Russia.
>
> P.S. Sorry for being late with the answer. I was out of the loop for some
> time busy with the other things.

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

A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Steve Quinlan]

I think it's quite amazing how some people seem to feel that because GNAT is
free, they can insist that ACT add or develop feature x, y or z, because "the
users want it". (ACT probably knows best what GNAT users want -- God knows they
probably have more direct contact with Ada programmers than any other company).
Such people then procede to get mightily and indignantly upset if the response
isn't a nurturing electronic hug and immediate acquiescence to their
suggestions, along with a promised release date!

As a paying customer of ACT (well, I work for a paying customer) I find they are
very responsive. But the free version is a side benefit. They probably, and
rightly, extend and enhance GNAT to provide what their paying customers need.
They just did so for us for a specific feature we wanted.   The rest of the
world benefits when that stuff becomes public.

I believe ACT is happy to listen to suggestions from anyone. Make your
suggestions, make your case to them why it would be valuable, try to enlist
others to your side to support that. ACT will consider it, in the context of
their business needs. But they make the final decision about whether to expend
their finite resources on work which their paying customers  may not be
clamoring for. And no one really has much standing to beat them up for it. How
many other  companies are giving you free Ada compilers? How many other compiler
company presidents are here every day helping out answering questions, etc. If
he didn't care about Ada and its users, he wouldn't spend so much time here
answering our stupid questions, or correcting our stupid answers to other
people's intelligent questions (OK, they're not all stupid -- a bit of
rhetorical hyperbole there.)

                          Steve Quinlan

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dewar]

In article <36CF00DB.43DF428C@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> I think it's quite amazing how some people seem to feel
> that because GNAT is free, they can insist that ACT add
> or develop feature x, y or z, because "the users want
> it". (ACT probably knows best what GNAT users want -- God
> knows they probably have more direct contact with Ada
> programmers than any other company).

Well thanks for that nice note :-). In fact at ACT we
always welcome suggestions, and have implemented many of
them. When it comes to large features, we still welcome
the suggestions, but often are not in a position to follow
through, either because we disagree with them, or because
we don't have the resources.

The boundary between suggest/encourage/insist can sometimes
be ill-defined. Let's think positive and assume that what
seems like inappropriate insistance is simply
over-enthusiasm :-)

> Such people then procede to get mightily and indignantly
> upset if the response isn't a nurturing electronic hug
> and immediate acquiescence to their suggestions, along
> with a promised release date!

Again, let's just put that down to enthusiasm. Certainly
it is nice to see people enthusiastic about Ada, even if
it can come across as upset sometimes.

> As a paying customer of ACT (well, I work for a paying
> customer) I find they are very responsive.

Thankyou for that vote of confidence (now I will have to
rush back to our records and make sure we have no
outstanding reports from you :-)

> But the free version is a side benefit. They probably,
> and rightly, extend and enhance GNAT to provide what
> their paying customers need.

Most of the time, I think the needs of our customers do
reflect the needs of the general market. The one place that
this is called into question is when someone says: "If you
add feature X, you will increase your market, since now
GNAT will be used by people who would not use it
otherwise."

Our experience teaches us to be very sceptical of such
claims. I particularly think it is important not to neglect
the current core Ada users in an attempt to win new
markets. I am reminded of a discussion in my theater group
(*) where we were discussing how to attract new younger
audiences, and someone suddenly wondered how our thoughts
would affect our current audiences, which was a sobering
thought!

> They just did so for us for a specific feature we wanted.
> The rest of the world benefits when that stuff becomes
> public.

Indeed many features in GNAT are there because of direct
customer requirements. Sometimes these are things we have
done as part of general support, sometimes they are funded
as special projects.

I have always thought that the fully supported customers
using GNAT Professional and students, researchers,
hobbyists etc using the public release of GNAT are natural
partners.

The paying customers provide the resources to continue the
development of GNAT (our revenue continues to grow, and we
are not getting ebay-style rich, or even some minuscule
fraction of this, but we can afford a first rate staff that
works well together to continue the development of new
versions of GNAT and tools with useful new stuff (I think
everyone will agree that 3.11p has LOTS of nice new
features compared to 3.10p, and I can promise that 3.12p
will be an equally exciting jump).

In turn, the users of the public version pioneer the
testing and use of the compiler. In particular they
tend to be much less conservative than large project
users (quite appropriately) and so they tend to pioneer
the less widely used features of the language.

We continue to get many valuable reports and suggestions
from users of the public version at report@gnat.com. We
cannot discuss these in detail, or provide a rapid
response, but all such reports are eventually read and
examined, and many useful fixes and enhancements have
come from this source, which of course in turn benefits
paying customers.

> I believe ACT is happy to listen to suggestions from
> anyone. Make your suggestions, make your case to them why
> it would be valuable, try to enlist others to your side
> to support that.

Absolutely Steve, that is good advice, and we are indeed
happy to get suggestions. I know it is frustrating some
times to people who are dead sure their suggestion is
*the* key to Ada's success, and they don't find us jumping
to agree, but we do listen carefully to all suggestions.

> ACT will consider it, in the context of their business
> needs. But they make the final decision about whether to
> expend their finite resources on work which their paying
> customers  may not be clamoring for. And no one really
> has much standing to beat them up for it.

Well we do get some funny cases. Once some procurement
agent called me to demand that I give a formal statement
that the version of GNAT 3.10p they were using was Y2K
compliant. I told him we did not make any such statements
about the public version. He got VERY indignant, and
started shouting at me "WELL WHO IS THE MANUFACTURER
OF THIS COMPILER? WHO CAN MAKE THIS GUARANTEE?" I told
him no one, but he was not satisfied. Oh well, we do our
best to sit back and have a chuckle when this sort of
thing happens :-)

> How many other  companies are giving you free Ada
> compilers?

Well it is nice to see that Aonix is making at least some
version of their technology freely available. I suspect
that GNAT had something to do with this, and if so, am
pleased to see it have this effect. If other vendors get
persuaded to consider the open source approach, so much
the better!

> How many other compiler company presidents are here every
> day helping out answering questions, etc. If he didn't
> care about Ada and its users, he wouldn't spend so much
> time here answering our stupid questions, or correcting
> our stupid answers to other people's intelligent
> questions

I never spend time answering stupid questions :-)

> (OK, they're not all stupid -- a bit of rhetorical
> hyperbole there.)

Indeed, despite the occasional frustration over junk in
CLA, this newsgroup is in fact in FAR better shape than
many of the other comp.lang groups, a tribute to the good
taste of Ada programmers and enthusiasts! It is also nice
to see, with rare exceptions, that we very rarely get
completely Ada-irrelevant posts, so the signal-to-noise
ratio stays high. Indeed even the extensive C++ vs Ada vs
.. language "war" thread recently remained remarkably
productive, especially with respect to contributions from
CLA participants

Robert Dewar
Ada Core Technologies

P.S. I try to make a distinction between messages which
are purely Robert Dewar sounding off, these come from
dejanews, and are unsigned, and messages which may
reflect ACT positions. I say "may" because we certainly
do not discuss everything and sometimes I may say things
which other people in the company point out to me are
wrong :-)

(*) My theater group, the Village Light Opera Group, the
oldest community theater group in New York, does fully
staged shows twice a year at the Fashion Institute Theater
in New York City, with a full orchestra. We are doing
Brigadoon this spring, and I am playing the role of
Archie Beaton (Harry Beaton's father, Harry is the one
who tries to run away). If anyone is interested in seeing
this show, let me know, or go to our site www.vlog.org.

Now that really IS an ad, but for that by VLOG hat is on,
and not my ACT hat :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Matthew Heaney]

dewar@gnat.com writes:

> Indeed, despite the occasional frustration over junk in
> CLA, this newsgroup is in fact in FAR better shape than
> many of the other comp.lang groups, a tribute to the good
> taste of Ada programmers and enthusiasts! It is also nice
> to see, with rare exceptions, that we very rarely get
> completely Ada-irrelevant posts, so the signal-to-noise
> ratio stays high. Indeed even the extensive C++ vs Ada vs
> .. language "war" thread recently remained remarkably
> productive, especially with respect to contributions from
> CLA participants


I'll second this emotion.  I read CLA every day, and always look forward
to posts from Robert Dewar, Bob Eachus, Bob Duff, and Tucker Taft, from
whom I learned much about the finer points of Ada95, language design,
and programming in general.

I also post frequently on CLA, and hope that in some small way, I've
contributed more to signal than to noise.

Matt

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[bill]

In article <m3iucv2gmv.fsf@mheaney.ni.net>, Matthew says...
>
 
>I also post frequently on CLA, and hope that in some small way, I've
>contributed more to signal than to noise.
>
>Matt

Yup, your posts are great. I collect most of them. I am still learning
Ada and it helps to have experts like you guys around. 

However, there seem to be more programming questions in 
other languages news groups about those languages (such as C, C++, 
Java) than there are questions here about Ada. Not sure if it is 
becuase there are less Ada programmers than the others, or is
it becuase Ada is better defined, Ada programmers do not need to
ask many questions about it, or is it that the Ada compiler finds
all the bugs for the programmer, there is nothing else left for 
them to ask about :)

Bill.

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Larry Kilgallen]

In article <7ar250$dq3@drn.newsguy.com>, bill <bill@newsguy.com> writes:

> However, there seem to be more programming questions in 
> other languages news groups about those languages (such as C, C++, 
> Java) than there are questions here about Ada. Not sure if it is 
> becuase there are less Ada programmers than the others, or is
> it becuase Ada is better defined, Ada programmers do not need to
> ask many questions about it, or is it that the Ada compiler finds
> all the bugs for the programmer, there is nothing else left for 
> them to ask about :)

I think one of the expectations of regulars here is that inquiries
should be made only after consulting a book.  Considering Ada's place
on the hyped-favorite-of-the-month scale, it seems that most who
bother to use Ada are willing to read books.

Larry Kilgallen

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dennison]

In article <m3iucv2gmv.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dewar@gnat.com writes:
>
> > Indeed, despite the occasional frustration over junk in
> > CLA, this newsgroup is in fact in FAR better shape than
> > many of the other comp.lang groups, a tribute to the good
> > taste of Ada programmers and enthusiasts! It is also nice
> > to see, with rare exceptions, that we very rarely get
> > completely Ada-irrelevant posts, so the signal-to-noise
> > ratio stays high. Indeed even the extensive C++ vs Ada vs
> > .. language "war" thread recently remained remarkably
> > productive, especially with respect to contributions from
> > CLA participants
>
> I'll second this emotion.  I read CLA every day, and always look forward
> to posts from Robert Dewar, Bob Eachus, Bob Duff, and Tucker Taft, from
> whom I learned much about the finer points of Ada95, language design,
> and programming in general.

I'll have to third that. Even the flamewars are enlightening. I'm sure Nick
would agree too. :-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dennison]

In article <36CF00DB.43DF428C@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:

> I believe ACT is happy to listen to suggestions from anyone. Make your

{choke!}

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Steve Quinlan]

dennison@telepath.com wrote:

> {choke!}
>

  Well, that was a well-considered response. I take it you've suggested
things to ACT that they did not implement. This is of course evidence that
they are unwilling to listen to suggestions.

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dennison]

In article <36D41563.D8A72F6B@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> dennison@telepath.com wrote:
>
> > {choke!}
> >
>
>   Well, that was a well-considered response. I take it you've suggested
> things to ACT that they did not implement. This is of course evidence that
> they are unwilling to listen to suggestions.

Well, I am a little curious where that belief of yours came from. It jibes
neither with my personal experience, nor (more importantly) with what I have
witnessed in the last 5 years here on c.l.a.

I'm not trying to be anti-ACT here. I think they have been a wonderful source
of good for the Ada community. Where would Ada be right now without Gnat?
(Nowhere, that's where!) But not stopping there, they consistently do more
than they have to or need to. Witness GLADE, the spitbol packages, etc. Also
(where the rubber meets the road) whenever I've submitted a bug report
through official channels as an unsupported user I got aswesome response. Way
better than most companies tech support when I *am* supported. I'm not
knocking the likes of GreenHills, Rational, Aonix either. But I have
submitted bug reports through email to all of them, and not once did I ever
get a complete response from the president of the company within an hour. :-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Steve Quinlan]

That was a rather glowing endorsement. So, why were  you choking in the previous
note?

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dennison]

In article <36D6B701.6DDB0997@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> That was a rather glowing endorsement. So, why were  you choking in the
previous
> note?

It was a specific point I choked on, not your whole posting. You'll note I
only quoted one sentence in the whole posting.

I don't think this is even a contraversial issue. You must have noticed that
Robert misses no oppertunity to point out that "unsupported" users can expect
no consideration whatsoever.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Simon Wright]

dennison@telepath.com writes:

> I don't think this is even a contraversial issue. You must have
> noticed that Robert misses no oppertunity to point out that
> "unsupported" users can expect no consideration whatsoever.
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In the UK this might be understood as 'can expect only rudeness'. That
has not been my experience (and may not be what you meant?)

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Dave Taylor]

Simon Wright wrote:
> 
> dennison@telepath.com writes:
> 
> > I don't think this is even a contraversial issue. You must have
> > noticed that Robert misses no oppertunity to point out that
> > "unsupported" users can expect no consideration whatsoever.
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> In the UK this might be understood as 'can expect only rudeness'. That
> has not been my experience (and may not be what you meant?)

Even though I am unsupported and on an unsupported platform, I have
found ACT very responsive to my problems. I have received a great
deal of consideration.

Dave

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dewar]

In article <7b6t9u$oag$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> I don't think this is even a contraversial issue. You
> must have noticed that Robert misses no oppertunity to
> point out that "unsupported" users can expect no
> consideration whatsoever.
>
> T.E.D.

This claim from Ted, one of our at-times-rather-insistent
unsupported users :-) is a distortion. Please read what
I have said carefully.

We welcome suggestions and bug reports from unsupported
users, and we look at all such reports. If reports are
definitely bug reports, then the bug will be fixed in a
future release. For suggestions, we may well adopt a
suggestion in a future release if it makes sense to us.

Many unsupported users have submitted such suggestions
and bug reports, and these have been very helpful in
the continued development of the GNAT system. We certainly
want to thank those who have made the effort to make these
constructive contributions!

Robert Dewar
Ada Core Technologies

P.S. On at least some occasions in the past, Ted has
submitted such reports, for which we thank him. But
it is important to remember that if the report is only
submitted in the form of a post to CLA, that does NOT
constitute something which we guarantee to read and
pay attention to!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[dewar]

In article <36D41563.D8A72F6B@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
>   Well, that was a well-considered response. I take it
>   you've suggested things to ACT that they did not
>   implement. This is of course evidence that
>   they are unwilling to listen to suggestions.

This is so obviously incorrect that I suspect that Steve
missed a not :-)

Most certainly we are willing to listen to suggestions

Most certainly that does NOT mean that are willing to
implement all suggestions!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[Steve Quinlan]

dewar@gnat.com wrote:
This is so obviously incorrect that I suspect that Steve missed a not :-)

Yes, I considered it obvious from the context that I was being ironic.

Sometimes smileys just don't seem to fit. Imagine if Jonathan Swift had put
a ;-) at the end of "A Modest Proposal". (No, I do not have an inflated
sense of the literary merits of my CLA posts.)

Re: A Modest Defense of ACT (though they are big boys and can take care of themselves)

[robert_dewar]

In article <36D5713A.27E2BCAF@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> dewar@gnat.com wrote:
> This is so obviously incorrect that I suspect that Steve
> missed a not :-)
>
> Yes, I considered it obvious from the context that I was
> being ironic.

Well I agree it *should* be obvious, but you would be
surprised how many users of the public version of GNAT get
outraged that we do not follow their suggestions. Actually,
readers of CLA have seen this dynamic in action more than
once :-)


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: GC+HC for GNAT/GCC (was: Building a compiler)

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<79asc3$cq3$1@nnrp1.dejanews.com>...
|A very nice project would be to try to add full garbage
|collection to GNAT ....


Now _there's_ a challenge!

Actually, I'd be really surprised if someone hasn't already done this.
Still, I'm quite happy to throw in a contribution if it would be genuinely
useful.

First, let's be clear about what we are talking about. By "full garbage
collection", I assume Robert means both 'garbage collection' (i.e.
recognising which allocated objects are no longer accessible), and 'heap
compaction' (i.e. moving allocated objects so as to remove unused fragments
from their pool).

There are several possible combinations of schemes, all with their own
peculiar merits and problems, so I would suggest that a wide selection be
provided (as different pool types).

It should be understood that all of these schemes would have various
ramifications for both the GNAT front-end intermediate code emitter, as well
as for the GCC back-end object code emitter. Locking variations would
require a special machine instruction (different for each target
architecture).

It would probably be sensible for someone familiar with GNAT and GCC to help
me to 'splice' my code into GNAT and GCC. Any volunteers?

Finally, a quote:

"Machines with so-called 'virtual storage' may give the compiler writer a
large number of logically separate segments of storage, all of which can be
of effectively boundless size. The catch is that if storage is used as if it
were boundless, the time taken to run programs will be equally boundless.
Thus, irrespective of whether virtual storage is available, you do well to
be miserly with your storage." -- P.J.Brown, "Writing Interactive Compilers
and Interpreters", Wiley 1979 [written in the days of MULTICS: for "number
of logically separate segments" substitute "linear address space"]

And another:

"Garbage collection is a feature of the run-time support for some imperative
languages (such as Ada) ..."
-- David A. Watt "Programming Language Processors", Prentice Hall 1993

In practice, full GC isn't a feature of Ada - but I reckon it should be (at
least as an option). So, like Captain Picard, let's "make it so"!

Nick Roberts

Re: GC+FSD for GNAT/GCC

[Nick Roberts]

Andi Kleen wrote in message ...
[...]
|I wonder how hard it would be to put a "malloc()" plugin compatible
conservative
|GC like the Boehm GC into the GNAT run time library. As far as I can see
|GNAT uses a wrapper around the C Library's malloc function for its memory
|allocation needs. What would happen if I linked it with a GC malloc
library?


This strategy alone couldn't perform heap compaction - I'm going to call it
'free space defragmentation' (FSD) from now on (if nobody minds) - only GC,
and even then there are better ways (I think) of providing the GC. Without
FSD, however, you inevitably get creeping fragmentation (unless all blocks
allocated in the pool are the same size). I doubt that a GC scheme which
does not deal with fragmentation is of much value, in reality, but I would
welcome comments on this.

One kind of 'mark-sweep' scheme I am envisioning at this stage has the
following broad design.

The compiler (I'm not sure whether the front or back end) generates a piece
of constant data which encodes the locations of all access objects within
each record and array type, and of all access objects, and access
component-containing records and arrays, within each stack-frame. This data
is called the 'crib'.

The pool type's implementation can then use this crib to 'sweep' over all
access objects (including all those in the pool itself), 'marking' all
allocated objects which are still accessed (thus finding out all which are
not accessed, so performing GC), and then to sweep again, adjusting the
access values (or their data-pointers) as required (as a part of FSD).
Finally, the extant objects are shuffled into their new positions
(completing the FSD).

This is a non-locking scheme. The user (Ada programmer) must ensure that the
execution of a block which contains code that uses a pool (managed by this
scheme) in one task will never overlap with the execution of a block which
contains code that uses the same pool in another task. (If this cannot be
arranged, a locking scheme must be selected instead.) The most common case
will be where the pool is only ever used in one task (indeed, frequently in
a program which only has one task).

The compiler must generate code such that: no access object is in a
temporary location whenever an allocator or deallocator (of a managed pool)
is called; for every access object whose value is put into a temporary
location within a certain block, the value is written back into the
non-temporary location before the end of that block.

There are some details of this scheme I haven't quite sorted out yet (it's
quite complicated), but nothing major (with luck).

It is important to realise that this is just one scheme (albeit the most
important one, I think). I believe a variety of schemes -
locking/non-locking, mark-sweep/reference counter,
crib-reiteration/double-indirection/ring-of-pointers - will have to be
supplied.

Comments?

-------------------------------------------
Nick Roberts
-------------------------------------------

PS: I think the __GNAT_malloc() and __GNAT_free() routines would remain
unchanged, the entire GC+FSD stuff being managed at a higher level.

Re: GC+FSD for GNAT/GCC

[robert_dewar]

In article <79hsmq$jhv$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> One kind of 'mark-sweep' scheme I am envisioning at this
> stage has the following broad design.

Just make sure you look at the literature here, the problem
is very well understood at this stage (indeed most of the
important work was done in connection with languages like
Algol-68, SNOBOL4, and LISP2 a long time ago!)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Building a compiler

[Nick Roberts]

Chris Morgan wrote in message <87aeyv4kbg.fsf@mihalis.ix.netcom.com>...
[...]
|Presumably there are some "itches" in the design of GNAT/GCC that you
|would like to scratch by building your own alternative.

Interestingly, the "itches" you (very astutely) presume I wish to scratch
are not in GNAT/GCC - which I am only passingly familiar with - but were in
other, much older, Ada compilers I have used in my career.

These compilers were very intimately bound up with the execution
environments they targetted (essentially for real-time embedded
applications, albeit huge ones). The story is a familiar one: I had lots of
ideas as to how it could be improved, but, of course, no power at the time
to introduce any of my ideas.

So, the gist of it is, I am not only writing an entire new Ada compiler, but
I'm also writing a new operating system (a very small one) as well!
Together, these two will scratch most of my itches. The OS is a bit
Mach-like, but fully object-oriented, and introduces some interesting new
ideas. One of the key objectives of the OS is the use of memory-mapped,
fully-linked, object files for maximum program initiation speed. The general
theme of the compiler and the OS will be "speed to the max".

|There have been some discussions
|of language extensions on this group, including one for which Tucker
|Taft eventually gave the most popular new syntax.


Do you mean the "raise ... when" contruct? I'll be happy to include this
(certainly a handy addition). But, then, I'll have to include a flag to
reject it :-( ;-)


|I have to
|wonder though whether you wouldn't get more satisfaction out of
|building extended versions of GNAT.
[...anecdote...]
|Still, if you want to try, it's a worthy challenge, let us know when
|your parser runs faster than GNAT's ;)

I imagine my compiler will always run a lot slower than GNAT/GCC. I am
writing both the 'front end' (parser) and 'back end' in Prolog.

As the compiler is going to be a deeply optimising one, the use of a 5GL
such as Prolog is likely to be fairly essential. At the risk of sounding
(extremely) snooty, constructing/extending such a compiler out of Ada and C
(as I assume - correct me if I'm wrong - GNAT and GCC are respectively
written in) would be a bit too clumsy to be practical. I'm willing to listen
to arguments about this point of view.

Yes, I'm writing the Prolog (semi-)compiler, too. There is really no limit
to my madness!

Whatever I produce, and whenever I produce it, I intend to publish as 'open
source'. I'll keep you posted.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Building a compiler

[Tucker Taft]

Nick Roberts wrote:

> Whatever I produce, and whenever I produce it, I intend to publish as 'open
> source'. I'll keep you posted.

Given your rather impressive list of goals, you might want to
start by addressing Ada's Y2.1K issue, just in case your schedule
slips a bit ;-).

> -------------------------------------------
> Nick Roberts
> -------------------------------------------

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

Re: Building a compiler

[Nick Roberts]

I'd be well chuffed to live that long Tuck!

Still, medical technology moves on - you never know. I can see it now:
everyone celebrating the new year 2100; somebody pushes a drink into the
hand of some ancient old codger, who's still crouched in front of his
ancient computer screen and keyboard (when by now all computers are voice
only). Somebody whispers a question: "What is he doing?" Somebody whispers a
reply: "Same as he has for the last century, _still_ trying to write his own
compiler". There's a short silence, then: "What's a 'compiler'?" Nobody
knows.

You never know ;-)

Nick

Tucker Taft wrote in message <36BB3637.DEA2DECD@averstar.com>...
[...]
|Given your rather impressive list of goals, you might want to
|start by addressing Ada's Y2.1K issue, just in case your schedule
|slips a bit ;-).

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[dennison]

In article <7982p7$nll$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Tucker Taft wrote in message ...
> |Are you building an Ada compiler?  If so, I would suggest investing
> |in head examination techniques ;-).
>
> Yes (he admits sheepishly). And yes, agreed.
>
> But ... people have the strangest passions (climbing mountains, leaping out
> of aircraft, standing for presidential election), and mine happens to be
> building an Ada compiler. It's a bit like sex: if nobody did it, there would
> be no more people! Well, somebody's got to build Ada compilers: if nobody
> did it, there would be no Ada compilers.

Hmmm. You must have the same kind of pathology as the retiree who decided to
singlhandedly build a four-lane highway from South Bend, IN to Indianapolis...

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Fixed point multiplication ambiguity

[robert_dewar]

In article <78sojm$crk$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Okay, I'm a cheeky so-and-so (you may have noticed), so
> my next question is: do you recommend I try developing
> 'tree pruning' techniques to cut down the
> search space (searching for interpretations), or just
> search it all 'brute force'?

What problem are you trying to solve, I don't see any
problem in implementing the proper semantics here!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[Nick Roberts]

It's not a problem of semantics, but of compiler speed. Users are tolerant,
but they don't like it when the compiler hasn't finished by the time they've
got back from the loo ;-)

There will be some (rare) examples of code where searching a context for
valid interpretations will have to cover a very large number of possible
interpretations (the 'search space'). This could take a long time, and
disappoint the user as suggested above.

You could, of course, say to the user "don't use such weird code", but then
the user could always say "no, I'll just use somebody else's compiler!" :-)

Nick

robert_dewar@my-dejanews.com wrote in message
<78tlmt$jte$1@nnrp1.dejanews.com>...
[...]
|What problem are you trying to solve, I don't see any
|problem in implementing the proper semantics here!

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[robert_dewar]

In article <7982p8$nll$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> It's not a problem of semantics, but of compiler speed.
> Users are tolerant,
> but they don't like it when the compiler hasn't finished
> by the time they've
> got back from the loo ;-)
>
> There will be some (rare) examples of code where
> searching a context for
> valid interpretations will have to cover a very large
> number of possible
> interpretations (the 'search space'). This could take a
> long time, and
> disappoint the user as suggested above.

Such claims are totally unconvincing without evidence that
the search in question could take a noticable fraction of
the total compilation time. I don't believe for a moment
that it could, and certainly obvious tests confirm this!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Building a compiler (was: Fixed point multiplication ambiguity)

[Tucker Taft]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:

: It's not a problem of semantics, but of compiler speed. Users are tolerant,
: but they don't like it when the compiler hasn't finished by the time they've
: got back from the loo ;-)

Overload resolution almost certainly takes a miniscule proportion of
compile time on any "real" program.  Most lines have no overloading
at all.

As I mentioned, the only time I have ever seen it take a 
measurable amount of time was on that amazingly long concatenation of 
aggregates.  So that case may be worth thinking about a bit, but for 
the others, the key is to keep the overload resolution algorithm as simple
and understandable as possible.  Chances are, unfortunately, that
"as understandable as possible" won't be very understandable ;-).
Especially if you try to keep predefined operators out of the
symbol table...

: ...
: Nick

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

Re: Fixed point multiplication ambiguity

[robert_dewar]

In article <78od6d$b4t$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>
> Yes, this is legal, but Tucker's explanation is not
> precisely right.

<<completely different analysis, with entirely different
legality consequences -- would make some programs legal
where Tucker's approach would make them illegal>> snipped

Brave fellow to be sure you know this stuff better than
Tuck :-)

I agree with Tuck's analysis (and so does GNAT :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Fixed point multiplication ambiguity

[bob]

Marc,

For what it is worth, I cant answer the LRM interpretation, haven't
researched it yet. Maybe Hoos, or one of the others. But changing the 10.0
to integer 10 matches the "*" definition in package standard (gnat). It
then works. See following.

procedure Tf is

  D : Duration := 5.0;

  Dec_Delt : Integer := Integer(D * 10 + 0.5);

begin
    null;
end Tf;


linux:~/atest> ada tf.adb
gcc -c -g tf.adb
gnatbind -x tf.ali
gnatlink -g tf.ali


cheers...bob

Marc A. Criley <marc.a.criley@lmco.com> wrote in article
<369E14CA.90715966@lmco.com>...
> The following test program is compilable by Rational Apex, but
> GNAT rejects it with:
> 
> tf.adb:5:38: type cannot be determined from context
> tf.adb:5:38: explicit conversion to result type required
> 
> I've studied the LRM 4.5.5(13-20), but who has the correct
> interpretation doesn't quite jump out at me, though I am
> leaning towards one over the other.
> --------------------
> 
> procedure Tf is
> 
>     D : Duration := 5.0;
> 
>     Dec_Delt : Integer := Integer (D * 10.0 + 0.5);
> 
> begin
>     null;
> end Tf;
> 
> -----------------------
> Marc A. Criley
> Chief Software Architect
> Lockheed Martin M&DS
> (610) 354-7861
> 

Re: Fixed point multiplication ambiguity

[David C. Hoos, Sr.]

Marc A. Criley wrote in message <369E14CA.90715966@lmco.com>...
>The following test program is compilable by Rational Apex, but
>GNAT rejects it with:
>
>tf.adb:5:38: type cannot be determined from context
>tf.adb:5:38: explicit conversion to result type required
>
>I've studied the LRM 4.5.5(13-20), but who has the correct
>interpretation doesn't quite jump out at me, though I am
>leaning towards one over the other.
>--------------------
>
>procedure Tf is
>
>    D : Duration := 5.0;
>
>    Dec_Delt : Integer := Integer (D * 10.0 + 0.5);
>
>begin
>    null;
>end Tf;
>
The problem is simply that the compileter has to guess the type of "10.0",
or have D converted to Float.

Either of the following lines is acceptable to gnat.

    Dec_Delt : Integer := Integer (Float (D) * 10.0) + 0.5);
    Dec_Delt : Integer := Integer (D * Integer (10.0) + 0.5);

David C. Hoos, Sr.