George Russell <[EMAIL PROTECTED]> writes on 03 May 2000
> There are two problems with freezing large modules into
> languages:
> (1) they make life harder for implementors
> (2) when you want to use them, it usually turns out that there is some
> slight niggle you want which the implementor didn't think of,
> thus making the whole thing useless. For example, where
> are Division Rings (useful for Quaternions) in this proposal?
If the user discovers the lack of some category or instance needed
for one's purposes, this does not mean
"making the whole thing useless".
The rest of the library works, and the extra items, they are
introduced by the user program. As it is usual, when you program,
for example, in Haskell-98
- if I ever understand the whole sentence.
As to the particular example of
> Division Rings (useful for Quaternions) [..]
probably, you mean the category which in the Russian language is
called `telo' (`body'), and for what I cannot recall now the
English term. Maybe, it is called Division Ring, let us assume it
for now.
This means, probably, a Ring with 1, not necessary commutative,
where each non-zero element has left and right inverse. Quaternions
satisfy this, indeed.
Well, if the user needs it, one declares in the user program
class Ring a => DivisionRing a where ...
<operations which the user likes>
and adds its instances one likes.
And this inherits the operations from Ring of basAlgPropos.
In particular, the division in a Division Ring will be (/) and it
arises from Multiplicative of basAlgPropos.
This all does not mean "making the whole thing useless".
Alternative: the user declares data Quaternion ...
instance Ring Quaternion where ...
After this, all the reasonable operations, like +, -, *, / ...
will work as they should for the Quaternions.
Maybe you are asking why the proposal does not include DivisionRing ?
Because it cannot include as standard all the infinitely many
potentially needed categories for mathematics. It has to stop at some
reasonable size and include only the most popular categories.
For example, Haskell-98 has Num, Ord, Enum. And it could decide to
skip Enum. Alternatively, it could decide to include more categories.
This is the matter of author's taste and understanding.
Comparing basAlgPropos volume to others:
---------------------------------------
it introduces more algebraic categories than Haskell-98 prelude,
but many times less than the Axiom system.
What part of hierarchy I expect to be accepted
----------------------------------------------
If the committee stops at Set, Ord, ..., Ring, Field
and rejects LeftModule, NormedVectorSpace and such,
this will be what I expected.
Though, do not think that I want these latters to be rejected.
I added them just to present a choice for the community.
So that people would not tell me after "why you had hidden from us
these standard possibilities that may be so useful".
Also, for example, Jerzy Karczmarczuk mentioned once that he would
like to deal with NormedVectorSpace and such.
Concerning more DivisionRing:
-----------------------------
I think is is good to include the *property name* IsDivisionRing
(or some appropriate one) to make it possible to put its value into
the expression (baseRing _).
Generally, these attribute lists serve the dynamic recognition of
the category the data comes from, though, this recognition is not
guaranteed (the property may include Unknown value in some
situations...). In practice, the program would find in the list
(IsDivisionRing, v), with, for example,
v = Yes for Rational, Quaternion,
= No for Integer,
= Unknown for some possible subtle domains.
Of course,
this all should be and can be ignored by
non-mathematically minded programmers.
Probably, the proposal can arrange the truly extensible by user list
of property names in baseSet, baseRing ...
---------------------------------------------------------------
A great advantage of these attribute lists is that they help to
keep the number of standard classes small and still enable some
support for the extended category detection.
---------------------------------------------------------------
> There are some things it does which can't be done by a library.
> For example I like being allowed to tell the compiler that
> operations may be assumed associative. But wouldn't it be
> better to work out a way of specifying such things in a general
> way (EG by pragmas), rather than freezing them into particular
> operations and classes?
This *can be done by the library* - to some extent.
And this extent depends on the wisdom of a particular compiler.
Also the above two approaches do not controverse each other.
In basAlgPropos, declaring MulSemigroup ... you really tell
the compiler many things. For example, that (*) is associative at
such and such domain. The question is only whether and how this
particular compiler will use this information. The cleverer
compiler is the wiser usage it will make.
For *this year*, I do not expect the compilers would try to exploit
this. And we have not to insist strongly. Because the developers
know, what and when has chances to be introduced. *Rules* in GHC
is a good sign.
As I wrote earlier, even recently, such properties from
basAlgPropos work automatically, helping to predict the properties
of constructed instances. Knowing the property value for a,b you
can often tell what it will be for (a,b), and so on. Having the
standard like Num of Haskell-98, we are deprived of such
possibility. This all is important because
the main in a functional program is not how it computes a thing,
but what properties possesses a thing that the program computes.
> In general I am worried that Haskell is getting too complicated.
basAlgPropos pretends to arrange a library so that the advanced
features could be ignored by the users that fear complications.
As to the ease of implementation, it is 100 times simpler than what
CA systems usually do.
Of course, for the standard instances, I am ready to provide all
the supporting or explaining Haskell code.
Others have right to submit it as well.
This detailed job may have sense only after the proposal is
accepted by the committee in principle, revised by the author and
accepted again.
> [..] But wouldn't it be
> better to work out a way of specifying such things in a general
> way (EG by pragmas) [..]
It is good. But
* Generally, this does not contradict the ad hoc properties taken
from MulSemigroup, and such
* Introducing a good Rules construct to the very language is going
to be even better than Pragma. And I had presented once some non-
detailed proposal.
But this is - on the language, not on the library.
* All this is good, but not for the recent basAlgPropos, because
people tend to qualify it as too complex even without Rules.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
