Hugs> [3,7..22]
[3,7,11,15,19] <- OK
Hugs> map (* 1.0) [3,7,11,15,19] <- manual spec OK
[3.0,7.0,11.0,15.0,19.0]
Hugs> map (* 1.0) [3,7..22] <- same spec as first but !!! when
mapped to with a (*1.0) to coerce
them to reals:
[3.0,7.0,11.0,15.0,19.0,23.0] <- went one outside of range spec.
========================================
Exactly the same behaviour from ghci 6.10.4 :
Prelude> [3,7..22]
[3,7,11,15,19]
Prelude> map (* 1.0) [3,7..22] <- using a range
[3.0,7.0,11.0,15.0,19.0,23.0] <- it screws up
{at least it is not a "feature' to me}
Prelude> map (* 1.0) [3,7,11,15,19] <- spelled out it acts "right".
[3.0,7.0,11.0,15.0,19.0]
This seems like a possible bug? or at least a sure fire trap waiting to be sprung ... one of those nasties that could really create havoc if someone is not aware of this behaviour and buries a function that include something that unwittingly coerces from an Integral to a Realfrac or Fractional. Is this a well known thing to watch out for..
or is it something that can be worked around, other then having to
enumerate every value in a list rather then use the handiness of
the range notation as shorthand?
cheers,
gene