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, in general language-defined
identifiers may carry special meaning. It is good to limit
number of such special identifiers but they have their place
in the language. Concerning 'Rep' specifically, shadowing
builtion meaning would be worse. Signalling error is
reasonable, but I do not see it as clearly superior to
current behaviour.
> | 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.
My reading of Davenport paper is that actual represention is
by design untyped. 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.
> 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 '%'.
Sure, in general current selection mechanism is unsafe, but
in case of 0 and 1 I would try to preserve it if possible.
--
Waldek Hebisch
hebi...@math.uni.wroc.pl
------------------------------------------------------------------------------
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
