Hi Bill, > See: 'Built-in' section of: > > http://axiom-wiki.newsynthesis.org/SandBoxNonZeroInteger > > In general I think the FriCAS library compiler support for SubDomain > should be more complete so that such built-in knowledge is > unnecessary.
> Comments would be most appreciated. You know that I rather like to do without the SubDomain constructor. Why do you want to support SubDomain? That would make for a new keyword in SPAD. Actually, Stephen Watt said something with respect to SubDomain. 1) SubDomain(X, p?) should not export anything. It cannot inherit any function from X since as with your NonZeroInteger, there is actually no relation between the categories of INT and NZINT. The latter is not an AbelianMonoid anymore. 2) The only knowledge that the SubDomain constructor states is that X and SubDomain(X, p?) have exactly the same representation. So there SubDomain(X, p?) could be made to export coerce: % -> X retractIfCan: X -> Union(%, "failed") retract: X -> % -- actually that might throw an exception with the obvious default implementation. So what advantage does the (undocumented) SubDomain constructor bring for you? One can easily do without, as the Aldor libraries show. The only thing that SubDomain adds is the "p?" in ist argument which is accessible to the compiler. But I rather opt for a general mechanism to incorporate a specification language into SPAD than to just allow a hack for SubDomain. Other opinions? Ralf --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
