Fri, 5 May 2000 13:36:19 +0400 (MSD), S.D.Mechveliani <[EMAIL PROTECTED]> pisze:
> Let us call for the recent basAlgPropos discussion a hacker
> any Haskell user who do not like to care of mathematics, especially,
> of its most abstract parts.
> And call a snob any user that feels it quite different.
How to call a person that does care about mathematics and about
structure of numeric etc. types and classes in Haskell - but dislikes
basAlgPropos, feeling it's extremely inelegant, complex, illogical
and does not fit into the Haskell style at all?
I'm not against the principle of redesigning this area. But I
am against doing things that way, against very many aspects of
basAlgPropos.
I want Haskell to remain beautiful.
> The approach is: do not mention advanced features in the hacker
> program, and the program would not bite you.
It will bite when another person in his library relies on instances
like Set to be meaningful.
It's easier to add an instance that was not present (and the compiler
told so when somebody tried to rely on it), than to locate and fix
an instance that was poorly written because it's presence was forced
by artificial superclasses or badly designed grouping of overloaded
operations into classes, not by any real need of that time.
> Also one writes, for example, zero x
> instead of zero `asTypeOf x`.
This is one of many cases where I have no doubt basAlgPropos is
poorly designed.
Sample arguments are bad, because:
1. They present a confusing interface. This looks like a function,
but the real meaning is a constant. Neither mathematics nor
programming languages treat zero as a function from any unused
number to the zero value.
2. They usually make code larger. Even when a constant is overloaded
(instead of being only polymorphic), usually the exact type can be
deduced from usage. Haskell is not C++, it can infer types from
contexts of usage too.
3. They don't add any functionality or expressiveness.
4. They make interfaces inconsistent. Some constats have sample
argument, some don't. Do you expext Nothing to have a sample
argument?!
5. They hurt performance, Not always they can be optimized out.
Of course they (or something other, like "data Tag a = Tag") must
be present in cases where the rest of the type does not contain the
type that we parametrize over, like in Haskell98's RealFloat class.
Fortunately they are very few cases.
> Some people say here, that this is impossible, that the compilation
> errors become the run-time ones ...
> I do not see, so far, in what way these matters may occur serious.
> For the critics, it is a good point to provide some schematic
> examples.
One party makes a polymorphic use of the cardinality function from your
proposal. Another party defines a type, defines the Ord instance for
it, is forced to define a Set instance because of your superclasses,
but does not bother to provide cardinality, because you told it's not
necessary if they don't want to use it.
Now the first party, or some third party, wants to use the function
using cardinality on the type mentioned.
If a class were designed well, they would be two possibilities:
- The second party indeed did not define cardinality. The compiler
complains that the second type is not an instance of the class
that implements cardinality. Then anybody can add it.
- The second party did define cardinality. Everything works.
But with your proposal, the third possibility arises:
- We silently get an incorrect program that will bomb at runtime that
it needs cardinality that has not been provided.
> For example, I like to skip for the user types the fromInteger
> instance in Haskell-98, for some reason. Sometimes my program
> makes by error some implicit use of fromInteger, which leads to
> the run-time error.
This leads to the question whether the situation is common enough
that fromInteger should be moved to a different class.
(IMHO it's not common enough, you should define fromInteger for any
numeric type, because it's almost always needed for numeric types,
so it should remain in Num. Unless you use Prelude classes for things
they are not designed for.)
> Let us mark also the possibility of *dummies*. For example,
> baseSet _ = dummy_baseSet -- the program does not expect this
> -- part to be really used
> compare_m = compareTrivially -- minimal partial ordering
>
> Together with the design & implementation care, this is likely to
> satisfy the hackers.
It does not satisfy me. Why should I be forced to make a dummy
instance?
A Set class is very poorly designed in itself. It is a superclass
of almost all basAlgPropos classes, so it should really contain
fundamental operations that almost all types support. But it has
three methods:
- belongs, that does not make any sense for me and I could not hear
any rationale where it could be ever used.
- compare_m, which should belong to some other class, for types that
have a meaningful partial ordering. If a type has equality only,
only Eq instance should be defined.
- baseSet, which contains some arbitrary, non-extensible properties
of the given type.
It's hard to propose fixes for something that is broken from the
beginning.
> For example, (baseSet _) yields osetProperties, and the latter
> list may contain (Finite,v). Depending on this v <-
> [Yes,No,Unknown], the program can more precisely partially (and
> dynamically) solve in what real category the computation takes
> place. For example (Finite,Yes) means it operates in FiniteSet.
Not "can dynamically solve", but "must dynamically solve", i.e.
cannot determine statically e.g. if a set is finite.
Haskell is a statically typed language, and that is one of the reasons
I love it. I don't want to use a library which forces bad design.
> A nice feature here is that thousands of useful categories for
> different user tastes may appear in this way, and this would not
> require introducing new standard classes and instances.
It's exactly a misfeature. Because when new properties are added,
the old code must be _changed_ to support them, it can't be done
by _adding_ something. Moreover, the compiler will not statically
check whether definitions of properties are complete, i.e. where
definitions should be added. Not to mention that it's inefficient to
lookup properties in a list at runtime, and that they must all be
"yes/no/unknown" properties because they are a list of pairs. The
convention of property lists is bad as a whole.
> Besides the public discussion, some expert committee has to consider
> the proposal.
I would prefer to design a different proposal from scratch. Possibly
taking ideas from yours when stuck how to do something, but avoiding
the large set of misdesigns.
> the author does not know how ready the Haskell community and
> expert designers are to accept or implement various extensions.
> I think, at least, the Overlapping and "undecidable" instances,
> Multiparametric classes
> are ready to appear in the standard.
Multiparametric classes certainly should get into the standard, as they
are useful and elegant. But I hope that overlapping and undecidable
instances wil not go into the standard, at least in the current form.
--
__("< 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-
