An observation of Ada (may offend)

[bill@valiant.gmrc.gecm.com (R.A.L Williams)]

In article <1995Mar17.144930@lglsun.epfl.ch> Robb Nebbe wrote:
: In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:

: ...

: |> b. No bit level manipulation (fixed in Ada95 but only for unsigned
: |> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

: It is trivial to write a generic package providing bit manipulation on
: arbitrary integer types in Ada 83.

What do you mean? 

One approach is to hack something together, ie. shift implemented as 
multiply/divide, and implemented as something very complex involving 
subtraction etc. (unpleasant)

The other approach is to define BIT a derived type of INTEGER, WORD
as an array of BIT's and use a representation clause to try to force 
this down to one bit per 'bit'.  The trouble with this is that there 
is no natural coversion to/from integer. Another problem may be that 
not all compilers (at least the last time I used Ada 83) actually 
*implement* representation clauses. They're all meant to check them
syntactically, but this is an implementation dependent feature.

Have I forgotten something? Is there another approach?

: I would expect that it would usually be more appropriate to check if
: a value was < 0 rather than checking the sign bit but I'll assume you
: had a good reason.

No, that was just an example - I don't dee many situations where I'd do that.

: |> 
: |> h. And a special one for Ada95: poor encapsulation of objects. I can
: |> define a 'member function' for a class by including the class in the
: |> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
: |> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
: |> other features of Ada go out of their way to force the programmer to
: |> follow 'good practice' (sometimes a matter of opinion), this seems
: |> very lax.

: If you declare a private type then the only place you can see the
: implementation is from inside the package where the type is declared
: (or a child package). You can declare subprograms that have parameters
: of this type elsewhere but that certainly doesn't qualify as a 'member
: function'.

: The idea you are looking for is 'primitive operations' which a
: explained in the LRM.

Yes, mea culpa. I got this entirely wrong. I must RTFM before activating
fingers in the future!

: Robb Nebbe


Bill Williams