>> Float has signature random: Float -> Float
> -1 Yuck. Another keyword? :-(
-2
> I think that testing for specific function signatures should be
> avoided. That leads to the "slippery slope" of full reflection and
> run-time types - something that the original designers of Axiom
> intended to avoid.
I dont' think that is connected to full reflection. But there is another
problem.
Suppose you do something like
if D has with {+:(%, %)->%} then x := foo(a + b) else x := foo(0);
That is a very unreliable program the only thing at that moment one
knows about the +$D in the 'then' branch is that there is a function in
D that is called +. No properties are connected to it. You cannot even
tell whether
if D has with {+:(%, %)->%} then x := foo(b + a) else x := foo(0);
does the same thing. (I exchanged a and b.) There is no *knowledge* that
+ must be commutative. If there were
if D has AbelianMonoid then ...
that would be a bit better. But only a bit, because at the moment it is
only a *convention* that the + in implementation of AbelianMonoid is
commutative. But AbelianMonoid is just an identifier that I could also
have called AbelschesMonoid. Or maybe I should use some Chinese variant
or simply call it Foo (same documentation as the one for AbelianMonoid).
Until Axiom has axioms that can be formally expressed in the language
(instead of just in the documentation) it is only "safe by convention"
to use "has".
Ralf
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
