The recent state of basAlgPropos discussion reveals the
important points enclosed below.
You also will find its copy in the directory
http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/
in separate file, notes1.txt, or such.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
Hackers and snobs
-----------------
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.
For example, I am a snob, and several other members in this list are
too. I would like the committee to be a snob.
The source and origin of the functional programming is snobby.
But to my mind, the snobs of the Haskell community should respect
and take care of the needs of hackers.
And the hackers should not aggressively destroy everything they do
not understand.
Harmless for hackers, advanced for snobs
----------------------------------------
I am going to prove (can I ?) that basAlgPropos is so.
The approach is: do not mention advanced features in the hacker
program, and the program would not bite you.
Generally, the recent state of Haskell is so that it looses many-
many useful scientific possibilities.
And its aim has to be to recover this possibilities - preserving the
room for the hackers, not forcing them to study any new notions.
Few explicit categories, many implicit ones
-------------------------------------------
AddSemigroup ... Ring, EuclideanRing ... are the explicit
categories - there are provided the *classes* for them.
How the hacker uses them? One simply takes (+) from Additive,
(*) from Multiplicative, dimRem from EuclideanRing
- instead of Num, Integral of old Haskell-98.
When one wants the instance for the type T with, say, (*),
one needs to declare for it
instance Set T -- skip implementation !
instance Multiplicative T where (*) = ...
Also one writes, for example, zero x
instead of zero `asTypeOf x`.
One might also need to write
instance ... compare_m (..) (..) = ...Just GT
instead of old ... compare (..) (..) = ...GT
(`compare', (<) being derived automatically from compare_m).
I hope, the changes will not be essentially more than this.
Is simplicity possible?
-----------------------
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.
As to me, if the user, say, skips the advanced operation definitions
like baseSet of Set, then, one's program does not rely on what
baseSet produces. And the library implementation can be built so
that such cases it would not essentially use the attributes in
baseSet.
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.
First, this is not so a great tragedy. I find this place and improve
and consider this expense as less than the benefits given by the
above trick with fromInteger.
But the main consideration is:
the implementors of the basAlgPropos library can pay special
attention to the flex usage of the advanced part of basAlgPropos.
The difference is: the designers and implementors of Haskell-98,
probably, did not expect some snob ignoring fromInteger.
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.
Implicit categories are for snobs
---------------------------------
Hackers, ignore them!
Also they can be rejected by the committee, the rest of proposal
does not essentially depend on this feature.
But I hope, they would not be rejected.
FiniteSet, FiniteGroup, RingWithUnity ... are implicit.
They are given as the *attributes*, mostly as the property names in
the lists produced by `base' operations from explicit categories.
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.
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.
Careless definition or usage of the attributes produced by the
`base' operations may, in principle, damage the performance - this
is on the user design.
Though, I had not observed such effect in my practice, when tried
this approach in the old DoCon-1.07 computer algebra program.
The next version DoCon-2 undertakes special design to guarantee the
above performance safety in non-trivial cases, but these
complications should not be considered in the recent basAlgPropos
discussion.
Organization
------------
Besides the public discussion, some expert committee has to consider
the proposal. The committee may reject the proposal in principle.
It may as well accept some part of proposal and give the revision
recommendations for the author. In the latter case, the proposal is
re-considered after the revision ...
Can anybody imagine any other way to advance in this business?
When accepted, the proposal puts certain responsibility on the
author for helping to compose some necessary part of implementation.
Last heads of proposal
----------------------
'rd' Parsing algebraic expressions,
'kersl' Kernel standard language,
'dcon' Domain conversion proposal
- this all is *optional*, presented in order to give the committee
a wide choice, what part to reject.
Library and language
--------------------
Some parts of basAlgPropos rely on the language extension.
But they are optional:
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.
But this does not mean all the problems around them are solved.
basAlgPropos is for the *future* Haskell language, presumably, for
Haskell-2.
It encourages greatly Haskell-2 to include the extended features
like Overlapping and "undecidable" instances, multiparametric
classes, domain conversion via Cast instances for matriparametric
classes.
I would also like greatly to incorporate into the very language
some appropriate Rules mechanism for equational "simplification" of
the program parts defined by the user. Just to make a language more
"logic". Again - preserving the easy safe room for the hackers.
But these are only the author wishes for the language.
They relate somehow to the possible development of basAlgPropos
for the standard library.
Sample argument
---------------
This approach is both an important and optional part of proposal.
If unfortunately, it gets rejected - I cannot predict now what
revision might be needed. So far, I would first wait for the result.
Abstract types
--------------
Probably, it worth to introduce them to basAlgPropos, for example,
for Fraction, UniPol, ResidueE.
They may help to create automatically "safer" representations for
the algebraic elements.
