Henning Thielemann writes:
... some examples of transparency of notation based on 2+2=4 ...
I like to have this behaviour for derivation, too. So of what type must
be the parameter of 'derive'? A scalar expression with a free variable or
a function expression? The designers of Mathematica and Maple decided for
the first alternative. But the derivation function D breaks the constraint
of free combineability. If x=4 then D[x,x] is 0 or an error (I can't check
it currently), if x is not bound to a value it is 1. What I suggest is
that derivation should be limitted to functions. If two expressions denote
the same function, then D will derive two expressions, that may not be
equal but denote the same function. Indeed, the implementation of D must
know the expression of the function to give the result as a formula, but
if it only knows the set of argument-value-pairs it would work, too. This is the view on functions which Fourier brought to us.
Now:
Please don't abuse the examples based on differentiation in order to point
out the difference between 'expressions with variables' and 'functions'.
This is simply NOT TRUE that only functions can be differentiated. The
differentiation is an ALGEBRAIC procedure, people acquainted with the
differential algebra know that.
The differentiation (derivation) operator is a linear operator which
fulfils the Leibniz rule when acting on products. If the underlying
algebra (a ring, a field, etc.) fulfils some other constraints, if it
has some topology, this is ALL. People who do the so called 'automatic
differentiation' know that thanks to this it is possible to differentiate
formally the numerical programs WITHOUT any symbolic manipulation of the
program text; a "variable" 'x' is a GENERATOR of an appropriate differential
algebra.
In such a way you can write in Haskell - what I did some years ago -
a program which differentiates purely numerical infinite lists, representing
a value of an expression followed by a tower of all its relatives wrt. a
specified generator.
Math is not a question of notation, but of structure.
And - please - stop (this is not addressed to Henning) calling this or
that "stupid". Sometimes thing you don't like inspire people to find some
nice implementable solutions, even if outside a classical typed framework.
The double ordering: a < b < c
is a very well known contraption in Icon. The operator "<" may confirm
the inegality or FAIL. The failure is something which propagates across
all embedded expressions until it is caught. If it succeeds, then it returns
the SECOND argument. In such a way, going from left to right, "<" gives the
correct result. This is not 'functional' but I like it.
Jerzy Karczmarczuk
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
