"Bill Page" <[EMAIL PROTECTED]> writes:
[...] | > | Another example of this in Axiom that *does* work right now is: | > | | > | DirectProduct(4,OrderedVariableList [a,b,c]) | > | | > | OrderedVariableList is a domain constructor that takes something of | > | List Symbol as a parameter. In order to introduce '1..9' as a domain | > | it would be possible to introduce new domain constructor like | > | | > | )abbrev domain INTS IntegerSegment | > | IntegerSegment(S:Segment Integer): with Finite ... | > | | > | that takes something of 'Segment Integer' as a parameter. Do we want | > | 'IntegerSegment' to also be a subdomain of Integer?. In any case, | > | then we could write: | > | > I do not see obvious reasons why I would want IntegerSegment to be a | > subdomain of Integer. | > | | Well for example, maybe I would want to write: | | x:IntegerSegment 1..9 BTW, a general approach I have been working on for some time now is to have a domain ParseForm, for parse forms i.e. parse trees after they have been property annotated, at the Spad level, and define a protocol to construct new entities out of ParseForms. This ParseForm domain is different from InputForm (which represents only expressions). That way people can extend the interpreter in ways unimagined by OpenAxiom developers, and move lot of code out of the interpreter itself. The tricky part, of course, is to nail down the protocol so that it is both useful and safe enough. -- Gaby _______________________________________________ Axiom-math mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-math
