Re: [Axiom-developer] B#

[Ralf Hemmecke]

Hello,

C Y wrote:
> --- Bill Page <address@hidden> 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