Fri, 5 May 2000 16:53:12 +0400 (MSD), S.D.Mechveliani <[EMAIL PROTECTED]> pisze:
> > 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.
>
> The situation with my application program is exactly as you describe.
> And it often repeats with different users and different operations,
> and there is no tragedy about this.
But it's an unfortunate exception. It should not be forced all the
time, saying that it sometimes happens so it must be good.
> > 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.
>
> No. In the *standard* instances, say, for (,), Fraction ...,
> it is defined thoroughly. And the user may use it or not.
I talk about new types I define, and standard instances that are not
needed by me but forced by superclass relationships.
> For the user types and instances, it a business of the user how
> (and whether at all) one is going to exploit such operation.
I don't want to answer the question how many elements my type contains
if the only thing I want is to let FiniteMap use my type as the key.
But I also don't want to prevent somebody from answering this question
himself and making use of the answer in a standard way if he has
such need.
It really can be done well. The simplest way it to put cardinality
either in a separate class, or in a class with some related operations
which are generally used and defined together.
> In the worst case, the hacker defines one extra *dummy* Set instance.
No dummy instances at all!
> advancedAlgebra key proposal
> -----------------------------
> To introduce the standard compilation key -fadvancedAlgebra
>
> Without this key, the compiler inserts automatically the dummy
> definitions for all the necessary instances for the user types
> from certain fixed list of "advanced" categories - like
> Set, AddSemigroup, MulMonoid ...
No dummy instances, neither user-defined or compiler-generated.
They are not needed. If some library needs them, fix the library.
Or let it define them itself (I don't care what libraries I don't
use define), without forcing anybody to have a contact with this
ill design.
Please don't hide bad design under the carpet. It will not make it
better:-)
> I sometimes get warnings on skipping the operation definitions in
> some standard classes. And find it natural.
It is not natural. I always use -Wall and make my code warning-free,
excluding the development time of course. Warnings are good and
meaningful.
> >> 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.
> > [..]
>
> There is no problem about this. In any case, the dummy Show can
> be generated automatically, by the compiler, if the user skipped it.
NO! It does not make any sense. Why on Earth should a type that is
not showable have the Show instance?
> Let it put for example,
> showsPrec _ = ("Dummy Show"++)
> Would you then cry that it had printed occasionally what you did not
> like to see for T, if you had not bothered to define it for T ?
I did not define it either because it's impossible (e.g. it's a state
monad implemented as a function) or because I wanted to write some
code quickly, and make non-essential instances later when necessary.
I want the compiler to refuse to compile a code which requires a Show
instance for such type in both cases. In the first case the code or
the usage of the code is broken anyway and needs to be fixed. In the
second case a real Show instance should be added.
> I admire, how people like to make problems from nothing instead of
> looking for really serious questions related to the subject.
basAlgPropos has tens or more of those little problems. They together
make the proposal inappropriate for any serious consideration to be
put into the core library in this form.
If they are so many misdesigns in simple places I understand, I wonder
how many are there in more complex places that I don't understand.
> > 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.
>
> "Only" or not only, but this is sufficient. Because we have to add
> "
> when our class makes little sense without the superclass
> - in many particular situations that can be possibly created by
> the user types.
> "
> This is a good reason to make Show a superclass.
It does not. Show is not necessary for (<) or any other Ord method
to be meaningful. This implies that Show should not be a superclass
of Ord. Period.
> At least - if this can be made in a manner that does not complicate
> the life for other programmers.
But it does complicate life for other programmers! It forces them to
make a Show instance that would not be otherwise needed. And makes
programs bigger and the compilation slower (not much, but this is
not the only such case).
And how would it complicate your life when Show would not be mandatory?
Nobody prevents you from making Show instances for all types! I want
only to prevent you from forcing all other programmers to make Show
instances for their types.
If you make such obviously incorrect decisions in such simple cases,
I would not rely on your decisions in more difficult areas.
> > Fortunately they are needed in so small percentage of programs,
> > that the overall complexity of Haskell programs would be smaller.
>
> The attributes `IsFinite', `cardinality' - for example, are
> *fortunately* going to be used by millions, next 10 years.
I very much doubt it.
Is an equivalent of any of them used anywhere in such a big piece of
code as GHC sources? If not, why do you want to put them in a very
base class of almost everything, to be used by all Haskell programs?
> >> 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++.
>
> ?
> For example, do you suggest to put all the Haskell-98 standard
> classes in one class, to make it a single nice class.
The opposite.
(AlgebraOverRing a, LeftAssociative a) => ...
(AlgebraOverRing a, LeftAssociative a, WithUnity a) => ...
(I didn't dig into the details of these particular concepts, so I
don't know how exactly it should be partitioned. This is only an
example of the idea.)
> > 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.
>
> Probably, you mean
> "... on one of my types with Set instance is Noetherian".
> The answer would be simple, then.
> The type constructor, say, C, was not standard, it was *your* choice
> to put (OrderIsNother,Unknown) for it.
No. I did not want to make the Set instance at all. The superclass
relationships forced me to do it. My choice would be to let somebody
else to do it, or let me do it later. It's impossible in your proposal.
> For example, you may write fromInteger _ = 0
> for the type T and then, complain that the user of you program
> always obtains 0 :: T when calls fromInteger for T.
> And say "Where is the justice? I do not know what is fromInteger"
If I don't know what is fromInteger, I would not make a Num instance
myself.
--
__("< 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-
