Hello,
C Y wrote:
--- Bill Page <[EMAIL PROTECTED]> wrote:
I think of B# as first of all generalizing 'Expression' so that
all of the computations that a user is likely to want to do can
be done entirely within that one domain - just as if they were
calculating using Maple or Mathematica. And then simplifying
the syntax and semantics of the Spad language so that it always
implicitly refers to this generalized domain. And there is some
syntactic sugar to add to make this all a little sweeter.
Sounds like a good way to make Axiom more friendly for new (and casual)
users.
Yes, indeed.
But rather than Spad, I would argue that Aldor is actually a
better choice for the B# implementation language. We have
discussed elsewhere on this list the fact that Aldor has
already been used to write a parser for the Aldor language.
Doing something similar for the B# language seems completely
feasible to me.
I agree this is a job for a high level language, but I would suggest
that the Aldor licensing situation be clarified before implementing B#
in it. (I promise I'll move to axiom-legal if the discussion around
this heats up ;-).
We all agree on Aldor as an implementation language, but we have to wait
because of licencing problems. It's a pity. :-(
If we use Aldor (or Spad) to implement B#, then a user would
start using B# by invoking the read-eval-print-loop within the
B# package something like this:
Oh, I favour B# written in Aldor and also to clean up Axiom.
As far as I understand the sources the Axiom Interpreter does not only
execute (ehm interpret) the commands that are given to it, it also adds
some mathematical knowledge (especially coercions). Seems to be a good
idea to make Axiom more user friendly in the past, but with B#, the
knowledge should be in a BNatural domain/package. It's some guessing
anyway and all would be concentrated in BNatural.
However, even B# should not make assumptions out of blue sky, if it
cannot find a function coerce: Float -> Boolean or something similar in
the underlying Algebra library, it should simply reject it and not look
for intermediate functions coerce: Float -> Integer, coerce: Integer ->
Boolean. Shouldn't the library offer enough functionality already?
The library Algebra that comes with Aldor offers a type ExpressionTree,
which if made a bit richer could serve as the representation of the USER
type. Furthermore, usually each mathematical type offers functions
extree: % -> ExpressionTree --export of ExpressionType
eval: ExpressionTree -> Partial % --export of Parsable
I wouldn't mind if the coercion from one type to another on the
interaction level takes a bit longer. If the user wants to have it
faster he should take on the burden with the types and write an
appropriate function (if there isn't already such a function in the
library--which would have been found by BNatural).
Ralf
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
