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

but IMHO passing Rep as argument is resonable shortcut for the above.
If there are differences in behaviour I would rather change compiler
so that they agree.

BTW: AFAICS there is no need to have Rep at all -- all Rep does is
allowing magic coercions between % and Rep.

> 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 '%'.

> 
> That this domain compiles at all is mysterious; it happens to depend on
> a very obscure implementation detail of AXIOM compilers, one that is not
> advertised at all -- and I don't think it should.  
> It is voodoo.  So, I am calling it Johannes's Rep voodoo :-).

I would not call this voodoo: the compiler performs reasonable type
inference.  Sometimes compiler works too much to make sense of
user input, but IMHO this is not the case.

-- 
                              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

Reply via email to