Martin Rubey wrote:
>
> I'd like to report on a curious problem I have with SPAD/Aldor, which Python
> does not seem to have.
>
> In Axiom, we currently have the (mostly unused) Categories
>
> CoercibleTo S, RetractableTo S and ConvertibleTo S that provide
>
> coerce: % -> S, coerce: S -> % and retract: % -> S
>
> respectively. One can then ask
>
> (4) -> SquareMatrix(2, INT) has CoercibleTo Matrix INT
>
> (4) true
> Type: Boolean
>
> Very unfortunately, currently in almost all cases the query "has CoercibleTo
> Something" will return false, because the coerce function is not inherited by
> the category.
>
Hm, AFAICS CoercibleTo(X) is properly inherited. Only X is a fixed
domain. But I belive that intended usage of CoercibleTo was for
cases like CoercibleTo(OutputForm).
> Now, I would like that for domains of the same category, say
> UnivariatePolynomialCategory, that differ only in the representation of their
> elements, say sparse or dense, we would have
>
> A has CoercibleTo B and B has CoercibleTo A
>
> Eg., we could have a package
>
> UPOLYCoerce(A: UPOLYC, B: UPOLYC)
>
> that implements coerce: A -> B generically, using only operations from the
> category UPOLYC.
>
> But it seems that we cannot teach Aldor/SPAD, that for all domains A and B of
> UPOLYC we have
>
> A has CoercibleTo B and B has CoercibleTo A
>
Well, currently:
(6) -> InputForm has CoercibleTo(InputForm)
InputForm has CoercibleTo(InputForm)
(6) false
and I am not sure if we really want A CoercibleTo(A) to be true
(we must be careful to make sure that search for coercions does
not loop).
Considering your main question: currently Spad do not have
"first class" categories. Trurly first class categories,
more precisely computing list signatures at runtime means
trouble with overloading. Namely, in such case dispatching
(overload resolution) should happen at runtime. This is no
problem in languages like Python or Lisp where dispatching
is on types of arguments. But in Spad functions may be
overloaded on return type, such overload is rather nasty
to resolve at runtime -- one would be forced to run separate
copy of program for each possible retrun type and kill
all copies which lead to type error.
If you agree that you can call only "statically" known
signatures, then this is a significant restriction on
how categories can be used. In particular, it limits
what you can do with things like Foo(X) where X is
a category. Another question is using "forall" types
(your semantics of CoercibleToCat is essentially forall
type): I think that such types would be a nice addition,
but first we should work out semantics to make sure
that we do not fall into some trap (like conflict
with overloading).
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
