Riccardo Guida wrote:
>
> just for reference, a simple and quite precise explanation of evaluation in a
> proposed variant of A^# called B^# is available here: [JenksTrager94] at p
> 39. The authors say that evaluation in B^# corresponds to scratchpad and
> Common Lisp, so I *hope* that it is what is used by Axiom/FriCAS. If you know
> of similar/better references, please let me know, there are tons of articles
> out there.
>
> Greetings
> ric
>
> [JenksTrager94]
> http://axiom-wiki.newsynthesis.org/public/refs/axiom-scratchpad.pdf
Well, B^# is a vapourware: it was never implemented. There are
other references which aim to give precise semantics, mainly for
Aldor but they are very relevant to FriCAS. However, much of
what the theory can be summarised by "the devil is in details".
At core of FriCAS (Spad, Aldor) is extremally simple imperative
language with just two buit-in operation: assignment and
function call (there is also conditional expression and loops).
At overview level there is not much to say about assignment: it
behaves as assignment in other languages with no extra frills.
Essentially, anything interesting happens due to function calls.
Again, call in itself is quite ordinary with eager evaluation
of arguments.
For symbolic computations probably the most important domain
is Expression(Integer) (or Expression with more general argument,
but Integer as argument is most important case). 'eval' is a
function in Expression.
Coming back to FriCAS language, complications come due to
overloading and runtime dispatch: which functions will be
called is decieded first by overloading which choses
signature of function. Signature means types of arguments
and result and "origin" (roughly domain exporting the
function). Overloading resolution is at level of
parametric types, that is you will get actual types
only when you supply parameters. Only at runtime we
know actual values of parameters and can get actual type.
Runtime dispatch is resposible for choosing function
corresponding to actual parameters (code implementing
a function may and frequently do depend on parameters).
To explain it a bit more, if you type:
recip(a)
overload resolution is likely to decide that 'recip' come from
MagmaWithUnit. But each domain of this category may implement
its on 'recip'. In particular, if 'a' in an Integer you get
'recip' from Integer which behaves differently than 'recip'
from Fraction(Integer). If 'a' is a square matrix with
fractional entries 'recip' will do gaussian elimination
which is again quite different than previous cases.
To make things "more interesting" FriCAS contains some
support for guessing types which is used during overload
resolution. I write guessing, because this unlike type
reconstruction in say Haskell it is incomplete and less
systematic. In compiled language (Spad), this is limited
and essentially compiler only makes "obvious" inferences.
In interactive use "interpreter" makes guesses -- basically
there are special rules for common constructs. Guesses
means that "interpreter" can commit to wrong type for
subexpression and due to this fail to find type for whole
expression. OTOH, "interpreter" can assign somewhat
reasonable types in situation where Haskell style type
reconstruction would give up.
Coming back to overall design: in FriCAS interesting things
happens in domains. The FriCAS language makes effort
so that domains can implement needed behaviour. In
particular overloading means that domais can use as
operations names words that would be reserved in other
languages. Also, there is special syntatic sugar so
that constructs that at first glance look like builtin
into language in fact resolve to function calls. For
eample
a(1) := 5
is _not_ an ordinary assignment -- it essentially gets
converted to
setelt(a, 1, 5)
and setelt function can do what it wishes.
More about evaluation in another post.
--
Waldek Hebisch
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
