Thanks Gaby. I like that you're tightening up spad behaviour. Arthur
On 12/18/2010 05:24 PM, Gabriel Dos Reis wrote: > Arthur Ralfs<art...@mathbrane.ca> writes: > > | Hi Gaby, Martin, > | > | I've uncovered another problem in getting Martin's framework to work > | under OpenAxiom. Here's some stripped down code illustrating the problem: > > > Hi Arthur, > > The problem is simply an error in the `add' specification in SCartesian. > > The `add' part in a capsule can only designate a domain on its left. > At least, that is the behaviour documented by the AXIOM book > (see section 13.8 titled `Add Domain') The OpenAxiom runtime relies on > that in the way it interprets domain slots at runtime -- slot number 5 > is usually where OpenAxiom puts add-domain, as implied by the design of > the original AXIOM. > > More specifically: > > | **begin code******************************************************* > | > | )abbrev domain SCRT SCartesian > | > | SCartesian(n) : Exports == Implementation where > | > | n: PositiveInteger > | PI ==> PositiveInteger > | DF ==> DoubleFloat > | > | Exports == SetCategory with > | sipnt: (a:Integer,b:Integer) -> % > | spnt: (a:DF,b:DF) -> % > | > | Implementation == Type add > ^^^^^^^^ > > that is an error. That line should simply be > > Implementation == add > > Type is not a domain, it is a category; so it should not be used there. > (It can be used in the exports though, see below.) > > | sipnt(a:Integer,b:Integer):% == spnt(a::DoubleFloat,b::DoubleFloat) > | > | > | Rep := PrimitiveArray DF > > More generally, if you specify an `add domain', then should not specify > a Rep. (OpenAxiom will issue a warning to that effect.) The reason is > that the `add domain' also implicitly provides a Rep -- that was > intended in the original AXIOM design but never fully implemented, > OpenAxiom fully implements that semantics (with warning.) > > So, in this case, if you just remove the `Type' in the definition of > Implementation, you should be good -- and that should work with all > AXIOM flavours. > > As a general remark, I would suggest to avoid `add domain' unless, you > know you are truly doing an *extension*, as opposed to `inheritance' > as understood in the object oriented world. In all AXIOM variants, a > domain extension *adds* to the base domain, it does not necessarily > override the base domain (especially, when the base domain uses > defaults.) > > I think OpenAxiom should not silently let the code pass through at > compile time, only to error at runtime. I'll try to see how I can fix > that without introducing to any pertubation on assignment of slot numbers. > > | > | spnt(a:DF,b:DF):% == > | pt := new(n+1,0$DF)$Rep > | pt.0 := a > | pt.1 := b > | pt.n := 1...@df > | pt > | > | )abbrev domain SCENE Scene > | > | Scene(): Exports == Implementation where > | PT ==> SCartesian(2) > | I ==> Integer > | NNI ==> NonNegativeInteger > | LINES ==> List List PT > | BOUNDS ==> Record(mins:PT,maxs:PT) > | PARAMS ==> Union(points:LINES,boundbox:BOUNDS) > | > | Exports == with > > Stylistically, I prefer to write > > Exports == Type with > > when writing package exports. > > [...] > > | Using a Fricas build from trunk 2010-12-07 and an OpenAxiom build from > | trunk 2010-12-16 these domains compile under both. However whereas > | under Fricas I get > | > | (1) -> createSceneRoot()$Scene > | > | (1) "scene root #ch=0" > | Type: > | Scene > | > | > | under OpenAxiom I get > | > | (35) -> createSceneRoot()$Scene > | > |>> System error: > | The value 5 is not of type LIST. > | > | > | I can get rid of the error under OpenAxiom by either eliminating the > | SetCategory assertion in the SCartesian domain or by changing the > | commented out lines for the corresponding ones. > | > | Any ideas? > > With the correction as indicated at the beginning of this message, I get > the same result as FriCAS. > > -- Gaby > ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
