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
