Hi Haskellers,
Simon> Any objections?
frankly speaking, yes.
The intellectual meaning of a successor in a non-integral type
is not clear for me. Can anyone explain it?
I observed this report discussion for quite a long time and
maybe have found the deep reason behind the problems. It appears
to me that people like to add flexibility to the language
that should better not be added since it destroys structure.
The software engineering power of Haskell mainly comes from
its structure. One is surely more flexible with an untyped,
not referentially transparent language, but many efforts
have been made to add flexibility without loss of structure,
e.g., Generic Haskell.
Surely, one can enumerate the rationals like one can enumerate
pairs of integers, but that is not the kind of enumeration discussed
here, which is suppose to have a constant increment/decrement.
Unfortunately, several decisions concerning the predefined type class
system have already been kept according to other programming
languages instead of algebra. The latter
would have provided both mathematical rigor and more possibilities
for useful overloading of predefined operators.
Making non-integrals an instance of Enum appears to me like
a dirty hack, to reuse nice syntax. Maybe, it would be
more genuine to say that [a..b] is a counterpart of a loop
and use a new class called Iterator for a and b.
In any case, numbers which do not permit an exact increment,
as is the case for Float and Double should not be permitted
as types of iteration variables, since it would legitimate
bad programming style.
Since I suppose you also want to receive constructive suggestions,
I'd suggest to remove some instance definitions from the
report. Would any dubious instance definition have a consequence
on the performance of compiled code if it is, for compatibility,
only provided by a kind of deprecated prelude or library?
Cheers
--
Christoph
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
