2 points about language

[S.D.Mechveliani]

Dear haskellers,

I suggest you the two notes on the Haskell language:

(1) it is desirable to accommodate such features of Aldor language
    as  types as values and dependent types

(2) the properties of operations, like associativity, 
    commutativity ..., can be handled by `usual' Haskell, to some 
    extent.


(1):
As I wrote earlier, Haskell instances cannot model such domains as 
the residue ring  Integer/(n),  when n changes dynamically. 
This is why the BAL library applies the sample argument approach, 
and this somewhat complicates the program meaning.

Now, we observe in the  Aldor  manual  (http:/www.aldor.org),
Section 7.8:
``
  Zmod(n: Integer) : Ring with { if prime? n then Field; }
  == 
  Integer add { if prime? n then {inv (x: %) : % == ...} } 
                                         
Z_n, the domain of integers modulo n, is always a Ring. However,
if n is prime, then Z_n is also a Field, meaning that it should 
provide a multiplicative inverse for nonzero values. In an `add'
expression, a definition which appears in the consequence of an 
`if' expression is said to be a conditional definition ...
''
 
But Aldor is non-functional, strict, has a bit of `garbage' in the 
language, has only one implementation, and this one is not 
free-with-source.
Also I am not sure that the above example will really work in the
existing Aldor implementation.
Further, there exists a fully commercial Axiom program, which can
be considered as a large nonstandard algebraic library for Aldor. 
This library is certain recommendation for the language.

It will be good for Haskell, or any language of its type, to extend 
and drift towards Aldor, but with preserving functionality and 
elegance.
I always thought (naively) that `unsolvability' of types is a 
fiction. Typically, types and instances resolve at the run-time. 
But the compiler has to try each time to resolve at compile time as 
much as possible.
 

(2) 
I wrote in the BAL paper that meaningful standard algebraic 
categories (classes) may, in principle, help the compiler to 
optimize programs using the properties related to the category
names (associativity, commutativity ...).
On the other hand, people write now and then, that they consider
such possible properties only as intended, saying that the 
language does not provide room for their explicit usage
(the latter was also said by the referee of this paper).
 
It occurs to me now that there may be certain misunderstanding.
I kept in mind implicitly that as soon as these categories enter a 
library standard their names can also be added to the 
_key words of a language_. 
In this way the compiler is enabled to use the relevant properties.
There remains a question of expressions like  _|_ + 1 === 1 + _|_,   
but this is another matter, maybe, a matter of flags for the compiler 
and language version.
 
Regards,

-----------------
Serge Mechveliani
mechvel@botik.ru