> 1. On what level are recursive definitions a problem?
I don't think they are a problem for the spad compiler. Also the
dependent type stuff should work fine. (Something that doesn't work in
most languages.) But in some sense it looks ugly
from the design point of view. This kind of mapping from Polynomial(Z)
to Polynomial(Q) is a function that is neither attached to the first nor
to the second domain, so it rather should live on its own in a new
package and have Z and Q as parameters of the package. It is exactly as
the original developers have designed it.
> 2. This seems to tie in with my previous recent question about the
> possibility of polymorphic functions. How hard would it be to
> implement those? Superficially it seems like they could be
> implemented as simple syntax sugar over parametric packages (each
> function parameterized over type T gets its own (anonymous?) package
> with T as constructor parameter).
Usually, with a bit of thinking one can do with a design that does not
need polymorphic functions. Usually, you put the function in a package
that is parametrized by a type and implement the function for this
parameter type. At the time of usage you call the function from the
package giving the right parameter type that you want.
> 3. I noticed that there's a category called CoercibleFrom (and one
> called CoercibleTo, too). Could one of those categories be used to
> solve this issue, maybe?
No. These categories are not implementations of any function. They
basically only provide the signatures
coerce: X -> %
or
coerce: % -> X
for some domain X, but no implementation of such a function.
> So it would go something like this (I don't
> know the appropriate syntax, I'm just asking if this could be
> possible): For any types A and B that Polynomial can be
> parameterized with, if type A is in CoercibleFrom(B), define a
> function like so:
> coerce: Polynomial(B) -> Polynomial(A)
>
> coerce(b: Polynomial(B)): Polynomial(A) == map(c +-> coerce(c)@A,
> b)$PolynomialFunctions2(B, A)
Actually, I think, one can do this starting a package like this
PolyMap(A, B): Exports == Implementation where
A: Ring
B: Join(Ring, CoercibleFrom A)
Exports ==> with
coerce: Polynomial A -> Polynomial B
Implementation ==> add
coerce(x: Polynomial A): Polynomial B ==
map(c +-> coerce(c)@A, x)$PolynomialFunctions2(A,B)
(WARNING: I haven't checked whether the above code actually works.)
But what would that help you? Suppose in your program you construct a
polynomial p of type Polynomial(INT). Just typing
p :: Polynomial(FRAC(INT))
will not work. Why? Simple, you would ask the compiler to search for a
function coerce with type Polynomial(INT) -> Polynomial(FRAC INT).
You might say that, well, there is PolyMap with exactly that function in
the library. But how does the compiler know that there is PolyMap?
Having all packages visible all the time is not a good idea.
Furthermore, what should the compiler do if someone programs another
package later, say, PolyMapHemmecke(A, B) that also provides a function
coerce: Polynomial A -> Polynomial B? Should the compiler choose the
implementation from PolyMap or from PolyMapHemmecke. You see, **you**
have to give the exact function name and the exact package from where
this function comes. This is how programming works in FriCAS.
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/4d21d355-f978-74b2-98fe-ee2ae57c723c%40hemmecke.org.
