Wed, 3 May 2000 18:20:28 +0400 (MSD), S.D.Mechveliani <[EMAIL PROTECTED]> pisze:
> PartialOrd was asked by Tom Pledger.
> I responded: "if other people would not object".
> Trying to be a kind guy. Let the others decide whether PartialOrd
> is necessary.
It's not just a single place that I dislike. The proposal cannot be
fixed by making a small change here and there.
> basAlgPropos announces that the operations like `baseSet' also can
> be ignored by everyone who is lazy to consider it.
"Ignored" means "made returning \"don't know\" or even bottom",
and this is a bad design.
First, such instance is useless. The information that something is
not known gives us nothing.
Second, such instance cannot be improved. It has been defined,
and there can be only one instance for a given class+type pair in
a program. If someone needs a more complete instance, he is stuck.
You should not force other programmers to make a decision: either
define poor instances or spend time writing instances that will
probably never be used.
> Most class operations in Haskell are optional. For example, I am
> mostly forced to declare instance Num ... in my application
> programs in Haskell-98, but very seldom define fromInteger in it.
> Just like to skip it, for some reason.
You should not skip it, unless this is an unfortunate case where
particular classes do not fit well into what we are defining and
there is not any good definition of fromInteger.
> > must think about Show instance, and define partial ordering first,
> > then make it total ordering.
>
> What one can do without Show? It is needed everywhere.
Of course not! From all standard library types, in practice Show is
used almost only for numeric types, except some debugging messages.
OTOH almost all types are Ord.
> Every "algebraic" data is likely to be printed one day, maybe,
> in the error message.
If one thinks that a type would be printed, and there exists a good
default method of printing, he may make a Show instance. I don't
prevent people from defining Show. But I would certainly not force
them to do this.
A Show instance is not needed for (<), or for anything related to
comparisons, so it should not be a superclass of the superclass
owning (<)!
[qrczak ~/src/ghc-4.07/ghc/compiler]$ find -name "*.*hs" | xargs cat | egrep -c
'(instance|deriving).*Ord'
46
[qrczak ~/src/ghc-4.07/ghc/compiler]$ find -name "*.*hs" | xargs cat | egrep -c
'(instance|deriving).*Show'
36
There are at least 10 types in GHC sources that would have to get a
Show instance only to fit into your class hierarchy, that would never
be used.
GHC often uses pretty printing combinators instead of Show. You should
not force the arbitrary decision of using Show everywhere.
Typical object languages must have big and complex hierarchies of
classes because it is impossible to express that we want the object
to be an instance of more than one class. Haskell classes mean a
different thing: you can have several classes in a context. Please
don't apply C++'s style to Haskell.
Superclasses are needed only:
- when our class makes little sense without the superclass, to
simplify contexts, or
- when a default method implementation requires that class, and we
feel that the importance of having such default implementation is
larger than the inconvenience of having a superclass.
> Now, what is wrong about it? Where is the complication, if the user
> can always ignore extra possibilities?
> Complications are only for the users that want them.
I said above what it can mean to "ignore" a class.
I don't like putting so much of very arbitrary stuff into the very
core of libraries.
> > Why should Show be required for Ord? Why should I be forced to
> > compute the cardinality, which is not trivial for more complex
> > compound polymorphic abstract types?
>
> No need for such computation. You can always put it *unknown*.
With your proposal it would be much higher ratio of useless instances
in programs.
> This remains things like in Haskell-98.
No: you turn compile time errors into runtime errors.
> How strange. "I don't know and put it unknown. And this is bad".
> Really, what can one put if one does not know?
He should not be asked to put anything!
> Probably, you want to say that the attributes like OrderIsNoether
> are needless to introduce, because when needed, they can be
> expressed with the corresponding *classes* and instances.
Fortunately they are needed in so small percentage of programs,
that the overall complexity of Haskell programs would be smaller.
> But in practice, the result of such approach will be that we would
> need to add about 200 classes more to basAlgPropos, and also to
> mention their *mandatory* intermediate instances in the user
> program. And the classes will be named like this
> LeftAssociativeAlgebraOverRing,
> LeftAssociativeAlgebraWithUnityOverField,
> LeftAssociativeAlgebraWithUnityWithSuchAndSuchThingOverRing ...
Not necessarily, because you can put several things in one context.
This is one of reasons I like Haskell more than C++.
> > I don't know what does it mean that the order is Noether,
>
> You can ignore it, and you will remain as if with Haskell-98.
> No violence against old habits. Advanced features are optional.
Then another author needs to use the information about whether ordering
on one of my classes is Noetherian. And he cannot, because I already
went the easy way and made an instance saying that I don't know.
[Noether]
> This has to be inserted into Proposal.
But certainly not into the base class of almost everything!
This can go into a library sitting in -syslib num.
> Generally, it is not correct to pretend for such a language as
> Haskell to serve *only* the hackers.
Similarly incorrect is to make Haskell serve only authors of computer
algebra systems.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
