Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
| Gabriel Dos Reis wrote:
| >
| > Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
| >
| > | Gabriel Dos Reis
| > | >
| > | >
| > | > Consider the definition of ModMonoid:
| > | > --------------8<---------------8<----------------8<--------------
| > | > )abbrev domain MODMON ModMonic
| > | > ++ Description:
| > | > ++ This package \undocumented
| > | >
| > | > ModMonic(R,Rep): C == T
| > | >
| > | <snip>
| > | > Its description does not have a claim for "author", but the intersection
| > | > of authors of domains using this domain leaves me with Johannes
Grabmeier :-)
| > | >
| > | >
| > | > ModMonic is not a builtin domain, therefore one needs a definition of
its
| > | > representation, i.e. a definition for "Rep", is needed. Yet, none is
| > | > provided. Rather, "Rep" here is specified as a parameter to the
functor.
| > | > (That is not the same as defining it locally to some value)
| > |
| > | Hmm, I am not sure what difference makes defining:
| > |
| > | ModMonic(R,RepT): C == T
| > |
| > | and later
| > |
| > | Rep := RepT
| >
| > that is the brownie point (and what I did internally).
| >
| > There are fundamental differences. First, because of the principle of
| > abstraction, parameter names are and should be immaterial. Surely, you
| > do not want your functions or constructors to start behavingly
| > differently just because you happen to consistently rename its parameters.
|
| In loose sense yes. But I do not expect to be able to use
| 'for' as a name of parameter,
`for' is not a name; it is a keyword.
Howeverif you write it _for, is becomes a legit name.
| in general language-defined identifiers may carry special meaning.
No dispute about that. However, the special meaning is usually in
specified contexts.
| number of such special identifiers but they have their place
| in the language. Concerning 'Rep' specifically, shadowing
| builtion meaning would be worse.
Agreed.
| Signalling error is reasonable, but I do not see it as clearly
| superior to current behaviour.
I do not know how to make sense of it. There are several guess, but I
do not know a general coherent principle that makes sense it. As I
observed early, in old AXIOM if you write
Rep == RepT
you do not get the special identifier treatement. So, what is the principle.
I would hate to have to paraphrase the implementation as specification,
when in fact we do not even know what the implementation is correct (we
do not know what it is implementing.)
|
| > | BTW: AFAICS there is no need to have Rep at all -- all Rep does is
| > | allowing magic coercions between % and Rep.
| >
| > Let me clarify.
| >
| > There ought to be a way of saying what the representation domain is.
| > The AXIOM book documents that you need the "special variable Rep", as
| > stated in section 13.6 titled "Representation". The official grammar in
| > section 13.2 (page 528) lists assignment to Rep as the first thing.
|
| 13.6 says 'uses the special variable Rep to identify the lower level
| data type ...'. It does not say that you have to 'identify the lower
| level data type ...'. 13.2 says 'recommended format', again no
| indication that Rep is mandatory.
but then why
Rep == RepT
does not work if you think there should be no mandatory format?
| My reading of Davenport paper is that actual represention is
| by design untyped.
That is correct. The underlying low-level representation
matters only from representation isomorphism point of view.
But that is irrelevant in order to decide which function to pick.
Otherwise, one generates wrong code, untyped lower-level representation
notwithstanding.
| In particular one can provide creation
| functions and operations in lower-level language -- consitency
| of such operations with representation is responsibility of
| implementer, _not_ of Spad compiler. Similarely, one can
| implement creation functions and operations in Spad and
| use 'pretend' to switch view between '%' and actual
| representation domain.
|
| Of course, you may wish to have more strict rules about
| representation, but this is language change.
|
| > | > Now, consider the capsule-level variable "power". It is declared as
| > | >
| > | > power:PrimitiveArray(%)
| > | >
| > | > then later assigned to as
| > | >
| > | > power := new(0,0)
| > | >
| > | > There are two lexical occurences of the literal '0' in there. Can you
| > | > guess, which one is which? There are at least five interpretations for
| > | > each constant:
| > | >
| > | > 0: R -- the parameter R satisfies Ring
| > | > 0: Rep -- the parameter Rep satisfies
UnivariatePolynomialCategory(R)
| > | > 0: % -- the current domains satisfies same
| > | > 0: NonNegativeInteger
| > | > 0: Integer
| > | >
| > |
| > | Well, 'power' is declared to be of type 'PrimitiveArray(%)' so 'new'
| > | should produce 'PrimitiveArray(%)' and compiler searches for it
| > | in 'PrimitiveArray(%)'. And indeed, in 'PrimitiveArray(S)' we
| > | have:
| > |
| > | new : (NonNegativeInteger, S) -> %
| > |
| > | So the first argument to 'new' must be 'NonNegativeInteger' and the
| > | second must be '%'.
| >
| > 1. new, expects its second *argument* to be of type %. It does not
| > require that there be no implicit coercion between the argument
| > as lexically written in the source code, and the actual code
| > generated for that argument. If one thinks that the mere presence of
| > the parameter "Rep" indicates that is the representation domain,
| > therefore the implicit coercion from Rep to % is OK, then 0@Rep is
| > a good viable candidate.
| >
| > 2. Fortunately, in this case, 0@% is also defined explicitly to be
| > 0$Rep, but there is no requirement that be the case. And when
| > it is not, we get a problem.
|
| Actually 13.6 says that '%' take precedence over 'Rep', so this one
| is excluded.
except it is vague on what it means by '%' takes precedence over 'Rep'.
The implementation is this:
compNoStacking(x,m,e) ==
T:= comp2(x,m,e) =>
(m=$EmptyMode and T.mode=$Representation => [T.expr,"$",T.env]; T)
--$Representation is bound in compDefineFunctor, set by doIt
--this hack says that when something is undeclared, $ is
--preferred to the underlying representation -- RDJ 9/12/83
compNoStacking1(x,m,e,$compStack)
compNoStacking1(x,m,e,$compStack) ==
u:= get(if m="$" then "Rep" else m,"value",e) =>
(T:= comp2(x,u.expr,e) => [T.expr,m,T.env]; nil)
nil
By the time Rep is changed to %, the selection has already been done.
The importance to Rep vs. % is that it affects overload resolution.
So in the above situation where m=$EmptyMode, we are inference mode, the
compiler goes and pick the constant that returns a value of type Rep.
Now, it just change the *type* of the expression to % -- as if by pretend.
It does not necessarily select the constant with type %.
| > 3. ModMonic(R,Rep) satisfies UnivariatePolynomialCategory(R), so that
| > means that there is alsoanother implicit coercion that turns
| > 0@R into a legitimate value of type %.
| >
| > 4. Similar reasoning holds for 0@Integer because % satisfies Ring,
| > and there is an implicit coercion from Integer to any domain that
| > satisfies Ring.
| >
| > 5. Since NonNegativeInteger is a subdomain of Integer, it also
| > provides an implicit coercion.
| >
| > So, in fact if one thinks that the mere presense of the parameter Rep is
| > sufficient to indicate representation domain and therefore implicit
| > coercions, then we have a legitimate case of ambiguity.
|
| OK, if you think about exact operations used to produce 0, then
| there is really ambiguity. However, IMO coercions are supposed
| to be homomorphims, so each of ways should lead to 0 in '%'.
they supposed to, but we don' require that in the type system (even if
we have desired it.)
| Sure, in general current selection mechanism is unsafe, but
| in case of 0 and 1 I would try to preserve it if possible.
I am not proposing to change 0 or 1. I think the principle of selection
should be clearly specified and applied to other constants too.
-- Gaby
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
