David Barton is right,
probably.
Looking into Maude www page, i saw the name of Manuel Clavel and
recalled a message on the OBJ language, i listened to, several years
ago. Clever thing.
A program in a really good language has to formulate a set of term
equalities and, - very separately, - a strategy. The language for the
strategy may differ much from one for equalities. Then, the things go
reducing according to equalities and strategy.
Yesterday, there was a Sunday, i rested from the "work", and started to
think - knowing nothing more of Maude.
Indeed, setting, for example, different partial ordering rules for the
terms, one makes the equations to rewrite terms in different directions.
I suspect that adding to the user program equations the equations of
lambda calculus (substitution, abstraction, what else?) and setting
appropriate ordering, we obtain the reduction to the head normal form
- that is the model Haskell interpreter.
Maybe, this assertion needs improvement, this is only a dreaming
philosophy.
This, probably, answers to the
Frank A. Christoph's <[EMAIL PROTECTED]>
words of 10 May 1999:
> [..] but I feel Maude is less a programming language than it is an
> algebraic theorem prover---its programs are not necessarily confluent.
If one sets proper equations and strategy, it would, probably, coincide
with Haskell !? So, the confluency is on the choice.
Then, one can built-in the default HNF strategy, and here, Haskell is
included without performance overhead - ?
(there remain the type classes)
Another point: non-confluent does not mean bad:
e = let n = 1234 in n-n+1
may reduce to r1 = 0+1 and r2 = 1 as well
- it depends on the chosen strategy.
Both results are correct: e === r1 === r2 according to lambda
equations. r2, maybe, slightly smaller.
It is good to compute not precisely, but to compute only some required
characteristic of result, maybe, property.
"Find expression equal to e, and possibly small, as you can, - in
this given ordering"
- this is what the computation should be. It specifies less definitely,
how to compute, only gives hints.
Releasing strategy, one obtains rich optimization.
The usual *optimization* notion used among functional programmers, can
be modeled by mere setting of the *partial ordering rules* - the
strategy.
It is said, the head normal form is somewhat the best strategy, so, why
care providing the strategy choice?
Because HNF is best for the very lambda calculus, maybe - i do not know
- not for optimizing expressions under rules (?)
I advise the Haskellites to apprehend the Jose Meseguer's Maude
philosophy and see what might be its relation to the Haskell type
system. Here might arise the main obstacle for the Haskell optimization
paradise.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
