On 27-Jul-1999, Ralf Muschall <[EMAIL PROTECTED]> wrote:
> Lennart Augustsson wrote:
>
> > b) Haskell does not have a function called primShiftInt so
> > you can't say that's intended or not intended.
>
> I looked once more where it appears: It is used in the
> extension libraries which come with hugs and ghc for the
> definition of shiftR etc. in Int.hs and Word.hs.
> I.e. it is not a part of Haskell (if we define
> Haskell as the thing being defined by the report).
>
> I still believe that it might be better to catch the
> behavior of C's >> and have mathematically sound
> shift operations in Haskell, even if it is only in the
> extensions. Otherwise, users who need those operations
> would have to define them in Haskell itself, which would
> probably be much slower.
We recently tackled a very similar issue for Mercury. The Mercury
standard library includes `>>' and `<<' operators, and these were
implemented in terms of the corresponding operators in C, and hence had
undefined behaviour if the shift count was >= than the word size --
but, just as is currently the case with the Hugs/ghc extensions, this
undefined behaviour was not documented.
The issue came to light because we found that this caused bugs: people
wrote code assuming that these operators would work for any shift count.
So we changed it. We added new functions `unchecked_left_shift' and
`unchecked_right_shift', which were implemented using C's `<<' and `>>';
these were documented as having undefined behaviour if the shift
count was >= the word size. And we changed the implementation of the
original `<<' and `>>' operators so that they worked correctly for any
shift count.
I suggest that the Hugs/ghc implementors do the same.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
