About the expressions like [1.0 .. 9.0], people write
Lennart Augustsson:
> By definition, if you follow the standard you can't be wrong. :)
> But the standard can be wrong. Perhaps this is a typo in the report?
George Russell <[EMAIL PROTECTED]>:
>> [..] The standard is kaput. It gets even worse if you try to make
>> sense of the definitions of succ and pred as applied to
>> floating-point number. My suggestion: get rid of Enum on
>> floating-point numbers. Maybe it'll make floating point loops a
>> little lengthier to code, but at least it will be clear what exactly
>> is being coded.
I agree with George - about Enum Float.
Enum is kind of counter-intuitive for Float and such.
Think of what is succ ("successor") for the Real or
Rational number: just "next real number", "next rational number".
Kind of a nonsense.
We know that Float is not exactly a Real number,
that Ord is not a superclass for Enum.
Still Enum.succ does not look good for the Float-like domains.
We can imagine "next real number", but - for some non-standard
ordering, that does not correlate good with other operations.
Therefore such ordering hardly ever fit to be included into the
language standard.
If some user needs it, one may introduce the user class.
The expressions like
let x = ... :: (<context> a) => a
d = ... :: (<context> a) => a -- the "step"
in
[x + (fromInteger n)*d | n <- [l..(h :: Integer)]]
can be coded as
arithmSequence :: Num a => a -> a -> Integer -> Mybe Integer
--Ring
--RingLike
For example,
arithmSequence -3.0 0.02 0 (Just 300) = [-3.0, -2.08, ..., 3.0]
arithmSequence -3.0 0.02 0 Nothing = [-3.0, -2.08, ...]
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
