Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes on 2 May 2000
>> basAlgPropos says
>> "class (Show a, Eq a) => Set a where ...
>> is introduced as a superclass for all algebra. It also provides
>> compare_m for the partial ordering (which, for example, can be
>> defined trivially).
>> "
>> Now, compare_m can be separated to
>> class Set a => PartialOrd a where
>> compare_m :: a -> a -> Maybe CompValue,
>>
>> PartialOrd being a superclass for Ord
> Currently, to be able to use a type as a key of FiniteMap, I must
> make Eq and Ord instances. [..]
> It's easy to see why Eq and Ord are separate, fewer types have (<)
> than (==), but otherwise it's very simple, the whole picture easily
> fits in mind.
>
> With your proposal I would have to define instances of
> Show
> Eq
> Set
> PartialOrd
> Ord
> to be able to define and use (<). They include strange "belongs"
> which IMHO does not make sense at all, they include baseSet which
> maps a sample argument to a record of five fields which uses five
> Maybe-Maybes, two enumeration types, Integer, list, and tuples. I
> must think about Show instance, and define partial ordering first,
> then make it total ordering.
>
> This is why I say it's too complex.
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.
Also you often repeat the arguments that were answered earlier.
I remember this from the discussion on overlapping instances.
I already said that `belongs' can be ignored by any person who does
not want to involve into various wise considerations.
And spent several lines of text for this.
basAlgPropos announces that the operations like `baseSet' also can
be ignored by everyone who is lazy to consider it.
There are the common operations - for everybody (+,*,divMod...), and
the advanced ones (baseSet ...) - for those who might like to play
in advanced game.
Please, read the Proposal before denying it
and recall the previous relevant parts of discussion.
Without this, it is too hard to progress.
This is the problem of the signal/noise ratio.
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.
> 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. Every
"algebraic" data is likely to be printed one day, maybe, in the
error message.
Alternatively, we could think of removing Show out of being a
superclass for the algebra. This question is not principal.
But why make things worse?
What the people think of this?
> and define partial ordering first, then make it total ordering.
The user is free to make this automatic.
The original proposal designs it in the following style.
If the user does not need the ordering for this particular type,
one either skips the definition of compare_m or puts
compare_m = compareTrivially (I like the second more).
If one needs the "usual" ordering - as in Haskell-98, one defines
compare_m x y = Just $ compareH x y, where compareH is what it
was `compare' in Haskell-98. Then, `compare', (<), (<=) ...
are derived automatically from this compare_m.
No extra efforts needed to make it total.
In Haskell-98 `compare' may define really an ordering or not an
ordering at all (note this), it may occur total or not. Similarly,
the programmer has possibility to arrange all this in basAlgPropos
by defining various compare_m.
Naturally, there are the *standard* instances of compare_m,
like for Integer, Fraction a, and some others.
And there is preserved extra possibility. If the user wants to put
the useful information on the ordering, one may set, for example,
osetProperties = [(OrderIsTotal,Yes)...] in the baseSet term.
After this, the Basic algebra and other user programs can, in
principle, exploit the property of this particular definition of
compare_m - by looking into osetProperties.
To exploit or not to exploit it, this is on the user program.
Skipping such action with osetProperties would mean that the things
go as it was in Haskell-98.
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.
> 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*.
This remains things like in Haskell-98.
It may be defined differently by the users who like to exploit it.
"
osetCard = n >= 0 means BS is a set consisting of n elements,
-1 infinite,
n < -1 of unknown cardinality.
"
( I an going to improve this to Fin n | InfiniteV | UnkownV )
> Of course I could define these methods trivially: the cardinality is
> unknown, I don't know when the type will be finite, I don't know the
> bounds, I don't know what does it mean that the order is Noether,
> everything will show as "<foo>", and everything "belongs", whatever
> it means. But this defeats the purpose of classes.
How strange. "I don't know and put it unknown. And this is bad".
Really, what can one put if one does not know?
Also for several standard types it *is known*, the user should not
care.
Being known for basics (Integer, Bool, Char ...), many things spread
automatically to other types by the standard *instances*. Again, the
user should not care.
> But this defeats the purpose of classes.
No.
For example, when it is put cardinality = 2 for Bool
(and I think the standard should put this),
then the standard Set instance for (a,b) would produce
automatically and very nicely cardinality = 4 for (Bool,Bool).
The role of classes and instances preserves.
Important point:
Attributes vs classes
---------------------
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.
And this is in the air of Haskell classes.
Formally, it is so.
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 ...
Each attribute SuchAndSuch needed for theoretic purpose will require
additional class with the new composed frightening name.
I have got an impression that Axiom had kind of stepped in this
path.
basAlgPropos avoids this: it has very few categories (classes),
while the additional attributes are optional, no matter how numerous
or messy they might be. For example, declaring instance Set ...
skip the baseSet definition, and behave as in Haskell-98.
> 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.
But for the occasion,
OrderIsNoether
means "ordering is Noetherian", that is there does not exist any
infinite sequence x1 < x2 < ... in the given domain.
This has to be inserted into Proposal.
> Please, NO!
>
> Haskell is hard enough for newbies to learn, compilers are slow enough,
> compiled programs are big enough.
As it is visible, newbies will have nothing new to learn.
Just skip all the advanced stuff.
The compilers already compile much more complex things, and I do not
complain on their slowness.
The aim of programming is comfortable programming, fitness of the
tool for the tasks.
And ease of the tool implementation is at the last position.
> IMVHO we should concentrate on making the thing useful for programmers.
> Not on exact modeling of mathematical concepts.
>
> This is a programming language, not a tutorial on algebra.
>
> Let's see what concepts will be useful in real programs, what has to
> be distinguished and what does not have to - using math as a tool,
> not as a guide.
>
> (And keep it simple and elegant.)
I consider my DoCon as a real program. For example, you give it a
square matrix with the entities the rational functions, like
(x+1)/(y+2), and it is able to inverse this matrix. Very "real".
Also Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes
K> I believe that a modest approach is really what we need,
K> but for me the modesty means - try to *apply* to concrete
K> problems whatever you have, and if you miss something -
K> CRY LOUD!
There are many "real" programs, not only the ones you personally
write.
> This is a programming language, not a tutorial on algebra.
Discussed is Basic Algebra Proposal for algebraic part of Library.
Very exactly a tutorial on algebra is welcome here.
Hacker and science in programming
---------------------------------
Generally, it is not correct to pretend for such a language as
Haskell to serve *only* the hackers.
Haskell is called after Haskell B.Curry. You see: lambda calculus,
wise combinators, their rules, clever equational theory,
"confluentness of reduction" ... A scientific stuff.
And there is a good way out. If one adds the pattern matching to C++
(is it there?), discuss the Microsoft Windows matters and develop
with C++ some money counting software for the banks, then, in this
area, one surely would not hear of Rings or Noetherian orderings ...
--------------------------------------
Jan Skibinski <[EMAIL PROTECTED]> writes
> [..] I wanted to help. Specifically, I sensed
> a tone of resignation in your letter dated Wed, 26 Apr, 2000
> in response to Fergus:
>
> Fergus:> I think the "jury" is unlikely to rewrite the proposal;
> Fergus:> more likely, they will simply reject the proposal.
> Fergus:> It is up to the proponent(s) of the proposal to rewrite it.
>
> Sergey:>>I have no idea of how such committee may appear.
> Sergey:>>Neither do I care much of what with this proposal will happen.
>
>
> If you are satisfied with a current process, I rest
> my case.
Thanks for the help.
What I think of all this:
* This proposal was not exactly my initiative. Mainly, it was
provoked. I had spent more than 20 days composing it. Maybe, it
worths then to spend 5 days in responding comments.
* The proposal was silenced for 1-2 years. I get used to this
silence. Now it arises unexpectedly, 1/2 of it being strangest
objections, when people do not read it and assert falsely that it
lacks this and that. Some others repeat the old-answered objections
and again, pretend not to notice what the proposal declares.
For example, when I do not know something, I say
"maybe, it worth ...", "probably", "why it is put so?", never just
put strange definite objections like
"no, commutativity cannot be exploited".
It appeared though, half of the people tend to discuss things
essentially.
> But this is not good enough to attract general attention
> and to make it easy to discuss about. The onus is still
> on you, to be frank.
It is large enough. If I expand it with more comments, people will
be frightened by its messiness and would speak more about its
complexity. Probably, it is better to add the comments in the form
of responses. But, for example, you wrote more than page of
comments, and there is nothing to really respond. The impression is
still that the proposal had not been read.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
