Kay Schluehr wrote:
> Ken Tilton schrieb:
>
>
>>Looks promising. How does a generic engine that sees only a solution (a
>>list of mathematical expressions and for each the transformations,
>>results, and opnds logged by individual TF functions) build up this
>>environment such that it has named attributes such as signed-value?
>
>
> Most likely it doesn't since there is no such engine. Instead local
> rules and combinators are encoded in classes. Hence there is nothing
> but an object tree and actions are threaded through recursive method
> calls.
Most likely that is the engine of which I was speaking. :) Why does the
engine consisting of "internal" methods make it not an engine? I think
you saw the word "engine" and assumed I did not understand OO design. I
feel a Naggum coming on...
kt
ps. This won't make sense unless you know about my Cells project, but
the solution to a /problem/ which has attributes expr and instructions,
is a declarative attribute of a problem. But that attribute is coded
essentially like this:
(defclass problem ()
....
(solution :accessor solution
:initform (c-formula ()
(solve (expr self) (instructions self)))))
k
>
> This implies that the generic reverse function is just the dual of a
> method call:
>
> def reverse(expr):
> return expr.reverse()
>
> What expr does depends on the internal representation encoded in the
> class of expr. This also implies that not only the form of the
> expression is significant but also its ( dynamic ) type.
>
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
--
http://mail.python.org/mailman/listinfo/python-list
