On Sunday 25 September 2011, 19:20:52, Chris Smith wrote:
> Would it be an accurate summary of this thread that people are asking
> for (not including quibbles about naming and a few types):
Not quite, I'm afraid.
>
> class Ord a => Enum a where
> succ :: a -> a
> pred :: a -> a
> fromEnum :: a -> Int(eger)
> toEnum :: Int(eger) -> a
> -- No instance for Float/Double
I'm not in favour of introducing an Ord constraint here.
For
data WeekDay
= Sunday
...
data Month
= January
...
an Ord instance would be dubious, but Enum is plenty fine.
>
> class Ord a => Range a where
> rangeFromTo :: a -> a -> [a] -- subsumes Ix.range / Enum.enumFromTo
> rangeFromThenTo :: a -> a -> a -> [a]
> inRange :: (a, a) -> a -> Bool
> -- Does have instances for Float/Double. List ranges desugar to this.
> -- Also has instances for tuples
Don't mix range and arithmetic sequences. I want arithmetic sequences for
Double, Float and Rational, but not range.
(For Float and Double one could implement range [all values between the
given bounds, in increasing order, would be the desired/expected semantics
for that, I think?], but I'm rather sure that's not what one does normally
want, and for Rational, you can't even implement it.)
Also, I doubt whether rangeFromThenTo is a useful addition to range, I
don't see how it would be natural for tuples. (The Ix instance for tuples
doesn't use the lexicographic ordering, but the box-partial order -
presumably so would the Range instance, so the 'distance' between two
tuples would depend on the given bounds. Using the box-partial order is
fine for range, but seems weird for blahFromThenTo.)
>
> class Range a => InfiniteRange a where -- [1]
> rangeFrom :: a -> [a]
> rangeFromThen :: a -> a -> [a]
> -- Has instances for Float/Double
> -- No instances for tuples
>
> class Range a => Ix a where
> index :: (a, a) -> a -> Int
> rangeSize :: (a, a) -> Int
>
> -- Again no instances for Float/Double. Having an instance here implies
> -- that the rangeFrom* are "complete", containing all 'inRange' values
Ho Hum. So Range would continue the same ambiguity/confusion that started
this thread, albeit in mitigated form.
Separating range from arithmetic (or 'fixed-step-size') sequences is
cleaner (we'd lose default methods anyway, you need Enum or Num && Ord for
them, but we now have numericEnumFrom* to make Enum instances for Num types
easier, we could move the current default methods out of the class to have
enumEnumFrom* so that writing instances for Enum types would be easier).
>
> class (RealFrac a, Floating a) => RealFloat a where
> ... -- existing stuff
> (.<.), (.<=.), (.>.), (.>=.), (.==.) :: a -> a -> Bool
> -- these are IEEE semantics when applicable
>
> instance Ord Float where ... -- real Ord instance where NaN has a place
Yes. I have pondered leaving Eq and Ord for Double and Float as is and
providing a newtype wrapper with container/sort-safe instances, but that'd
be cumbersome, people wouldn't know they exist and (when) they have to use
them, urk.
Also, although it's a change in behaviour, it doesn't badly break backwards
compatibility., as far as I can see (I hope x /= x isn't heavily used as a
NaN test).
So yes, definitely yes.
>
> There would be the obvious properties stated for types that are
> instances of both Enum and Range, but this allows for non-Enum types to
> still be Range instances.
>
> If there's general agreement on this, then we at least have a proposal,
> and one that doesn't massively complicate the existing system. The next
> step, I suppose would be to implement it in an AltPrelude module and
> (sadly, since Enum is changing meaning) a trivial GHC language
> extension. Then the real hard work of convincing more people to use it
> would start. If that succeeds, the next hard work would be finding a
> compatible way to make the transition...
>
> I'm not happy with InfiniteRange, but I imagine the alternative (runtime
> errors) won't be popular in the present crowd.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
