[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] B#

From: Ralf Hemmecke
Subject: Re: [Axiom-developer] B#
Date: Tue, 22 Nov 2005 13:24:00 +0100
User-agent: Thunderbird 1.4 (X11/20050908)


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)

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]