axiom-math
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-math] Re: [open-axiom-devel] [fricas-devel] Re: iterators and car


From: Gabriel Dos Reis
Subject: [Axiom-math] Re: [open-axiom-devel] [fricas-devel] Re: iterators and cartesian product.
Date: 22 Oct 2007 11:40:32 -0500

"Bill Page" <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]