Martin referred to this thread again recently: On Fri, Sep 16, 2011 at 11:22 AM, Martin Baker wrote: > On Wednesday 08 Jun 2011 17:51:19 Waldek Hebisch wrote: >> - You implement a bunch of "expression like" domains. Have you >> checked if existing domains have needed functionality? One >> obvious alternative is to base you implementation on Kernel. >> Another is to use SEexpression as representation. > > I've been thinking about this and I agree that the computation > domains are "expression like" .... sort of .... but .... > it seems that an expression would be in some algebra, for instance > perhaps there could be an expression where the symbols are > elements of a group, or a boolean algebra, or even a mixture of > algebras? >
One reason I did not reply earlier to this is because I did not understand what you meant by "algebra" in this context. What is the essential characteristic of an "algebra" that is essential for your application? > So if lambda-calculus, combinators and intuitionistic logic are like > expressions then, what is the algebra that they are expressions in? > Without completely understanding what you mean by "algebra" It seems rather obvious that each of lambda calculus, combinators and intuitionist logic are themselves selves "like" an algebras - or at least, they are formal languages, each with its own syntax and semantics. The expressions in lambda calculus are all syntactically valid statements in that particular language, etc. > For instance imagine I had an algebra (don't take this very loose > pseudo-code laterally): > > myAlgebra(baseAlgebra).... > .... with > e:Record(baseAlgeba,baseAlgeba) -> % -- constructor > m:(%,%) -> % -- binary op > .... ==> > Rep:=Record(A,B) > What is A and B? Maybe you meant Record(A:%,B:%) ? This looks just PAIR from OpenAxiom. > Then I could have some expression manipulator for that algebra: > > myExpression().... > .... with > e:% -> Symbol -- code to read out a given expression > m:% -> Record(%,%) > eval:% -> myAlgebra -- apply myAlgebra recursively to get single > term > ... ==> > Rep:=Union(e:Symbol,m:Record(%,%)) > Record(A:%,B:%) In general this looks OK. > But I can't see a way to define lambda-calculus, combinators or > intuitionistic logic in this sort of way? Somehow they seem to need to > be defined in terms of a inductively defined co-datatype like this: > > Rep:=Union(e:base,m:Record(%,%)) > > rather than a datatype like this: > > Rep:=Record(A,B) > I don't understand what you are trying to say here. In each case you will have a different set of operators (like 'm' above). > I am coming at this in abstract terms here, but in practical terms I > haven't yet seen a practical reason to use the domains you mention, > for instance I haven't yet noticed a need for caching of terms, but > that may change? > Representations can be chosen for reasons of efficiency or convenience and in the best case both. In Axiom is ofter makes sense to try to choose the "highest level" representation available which already represents many of the essential aspects of the target domain, at least by way of some obvious analogy (mapping). > However I do like the idea that when the compiler compiles an > algebra like myAlgebra then why not allow it to generate > expression manipulator code for the algebra at the same time? > Could you give an example of what you mean by "expression manipulator code"? Regards, Bill Page -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
