Re: Q: on redefinition of equal

Re: Q: on redefinition of equal

[W. Wesley Groleau (Wes)]

I don't know how inescapable is your "requirement" to hide predefined "="
from "ALL" data types.  But here's something to consider:

How much will it cost over the life cycle to have maintenance programmers

replacing

   if (A = B) = True then

with

   if A = B then

only to (attempt to) compile and then change it back?

Plus the time wasted when initial programmers write

   if A = B then

out of habit and have to (attempt to) compile twice?

Of course, with GNAT you can change the compiler to accept the standard
form with your new type Bool  :-)

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Q: on redefinition of equal

[david scott gibson]

In article <9604031559.AA05644@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>I don't know how inescapable is your "requirement" to hide predefined "="
>from "ALL" data types.  But here's something to consider:
>
>How much will it cost over the life cycle to have maintenance programmers
>
>replacing
>
>   if (A = B) = True then
>
>with
>
>   if A = B then
>
>only to (attempt to) compile and then change it back?

Well, of course, this is only one of the problems with such a
strategy.  BTW, I consider

    if Is_True(A = B) then 

preferable to using two different ='s since appears a little less
confusing.  Note that I'm only exploring possibilities at this point!

>Of course, with GNAT you can change the compiler to accept the standard
>form with your new type Bool  :-)

If I wanted to modify the compiler, all I'd need to do is change the
Normalize_Scalars pragma to initialize all scalars with valid
representations.  Then I could use the built-in scalars directly with
the aid of the modified, but still legal, pragma.  (Of course, such a
modification directly contradicts the implementation advice.)

--
Dave
dgibson@cis.ohio-state.edu

Re: Q: on redefinition of equal

[Brad Balfour]

In article <4k131kINN2ac@thalamus.cis.ohio-state.edu>,
dgibson@thalamus.cis.ohio-state.edu (david scott gibson) wrote:

>If I wanted to modify the compiler, all I'd need to do is change the
>Normalize_Scalars pragma to initialize all scalars with valid
>representations. 

Perhaps I've missed something in all of the preceeding articles, but is
all of your work to overload Booalean and the associated operations is in
order to detected unitialized variables which contain "invalid" bit
patterns?

If so, is there a reason that you aren't using the 'valid attribute?

Brad
--
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://lglwww.epfl.ch/Ada/
bbalfour@sw-eng.falls-church.va.us
bbalfour@acm.org
**new address: 3930 Pender Drive * Fairfax, VA 22030 * 703/277-6767 **

Re: Q: on redefinition of equal

[david scott gibson]

In article <bbalfour-0504961227320001@stmac0088.std.caci.com>,
Brad Balfour <bbalfour@std.caci.com> wrote:
>In article <4k131kINN2ac@thalamus.cis.ohio-state.edu>,
>dgibson@thalamus.cis.ohio-state.edu (david scott gibson) wrote:
>
>>If I wanted to modify the compiler, all I'd need to do is change the
>>Normalize_Scalars pragma to initialize all scalars with valid
>>representations. 
>
>Perhaps I've missed something in all of the preceeding articles, but is
>all of your work to overload Booalean and the associated operations is in
>order to detected unitialized variables which contain "invalid" bit
>patterns?

No.  I discussed my problems with scalars on cla a few months ago, it
wasn't part of this thread.  In order to map the RESOLVE language to
Ada95, I need all variables, including those of generic formal types,
initialized to a specified value of their type at the beginning of
their scope.  This is done in RESOLVE to support verifiability,
efficient implementations using swap, and, indirectly, composability.
For scalars, I can get away with an "unknown" initial value as long as
it is a valid representation.  In RESOLVE/Ada, generic package
operations may manipulate a generic initial-valued object without
regard to its actual (but valid) representation.  For nearly all
non-scalar types, I must use Initialize and Finalize calls, and thus
my heavy use of controlled types.  In order to perform constant-time
swapping on all types, most type representations in RESOLVE/Ada must
be dynamically allocated.  A yet unproven hypothesis is that the
improved efficiency that can result from using swapping (instead of
copying) will overcome the added indirection overhead necessary in an
Ada95 implementation of RESOLVE.  (Results with RESOLVE/C++ are
encouraging.)

>If so, is there a reason that you aren't using the 'valid attribute?

There might be some way I could make use of the 'valid attribute, but
if so, I suspect that it would be very messy. The problem occurs when
I declare a local variable of a generic formal type which could, in
general, be instantiated with a scalar type.  In RESOLVE, it is common
to immediately Swap an (initial valued) local variable with one of the
operation's parameters.  In Ada, if the local variable value is not a
valid representation, then I believe the call to Swap could raise a
Program_Error.  To make use of 'valid, I would have to check every
locally declared variable of a generic formal type before using it.
Then if the representation were invalid, I might be able to somehow
correctly initialize it to a scalar value.  No, this seems a bit far
fetched and probably wouldn't yield a performance improvement anyway.

Thanks very much for the suggestion!

--
Dave
dgibson@cis.ohio-state.edu

Re: Q: on redefinition of equal

[Robert I. Eachus]

In article <4k131kINN2ac@thalamus.cis.ohio-state.edu> dgibson@thalamus.cis.ohio-state.edu (david scott gibson) writes:

  > In article <9604031559.AA05644@most>,
  > W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:

  > >How much will it cost over the life cycle to have maintenance programmers
  > >replacing
  > >   if (A = B) = True then
  > >with
  > >   if A = B then
  > >only to (attempt to) compile and then change it back?

  > Well, of course, this is only one of the problems with such a
  > strategy.  BTW, I consider

  >     if Is_True(A = B) then 

  > preferable to using two different ='s since appears a little less
  > confusing.  Note that I'm only exploring possibilities at this point!

  > >Of course, with GNAT you can change the compiler to accept the standard
  > >form with your new type Bool  :-)

  First, a big suprise for all you Ada users:

  RM95 5.3(4): "A condition is expected to be of any boolean type."

  The rule in Ada 83 is the same.  If Bool is derived directly or
indirectly from Standard.Boolean, then it is a boolean type.  This is
very useful if you want to provide an enumeration representation
clause to match hardware.

   However if you need a three valued type, may I suggest that
if...then...else be replaced with:

   case X is
     when True   => ....
     when False  => ....
     when others =>
   end case;








--

					Robert I. Eachus

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