Edit detail for BNatural revision 3 of 3

A new project has been proposed to attempt to implement BNatural using Aldor as an extension of the open source version of Axiom.

Look for updates on this project here.

Initial Email Trail

**On November 19, 2005 2:05 AM Hans Peter Würmli wrote:**

In "How to Make AXIOM Into a Scratchpad" Jenks and Trager describe "... a new user interface language ..." for Axiom, which they called B# ("B natural") in the article.

http://wiki.fricas.org/public/refs/axiom-scratchpad.pdf

If it ever had been implemented, it would offer a lot of the language elements at least I would have hoped for in the interpreter interface for Axiom.

Does anybody know what ever happened to that project?

On November 19, 2005 10:05 PM Bill Page wrote:

The date on this paper, 1994, closely coincides with the time when IBM decided to close Axiom as a research project and negotiated with Numerical Algorithms Group to market Axiom as a commercial product. It is easy to guess that B# might have been a causality of this transition.

I agree with Peter that B# is probably what a lot of new users of Axiom are expecting to find. I like most of the design ideas for the B# language presented by Jenks and Trager in this paper so I think implementing B# would be a great project to resurrect for open source Axiom.

Also interesting in this article is mention of the project GAUSS which was an attempt to provide an Axiom-like type system in Maple GAUSS is contrasted with B# because Maple is essentially untyped while B# was an attempt to provide an untyped user environment within Axiom. As an active Maple developer at that time, I remember briefly playing with GAUSS and not being particularly impressed. My point of view has changed a lot since then. I am convinced of the value of strong type system in Axiom but I find I often miss the freedom of expression that the untyped environments of Maple, Mathematical and Maxima provide. B# might very provide the kind of bridge that Jenks and Trager envisaged in this paper.

Does anyone else have an interest in investigating the possible implement of B# ?

**On November 21, 2005 1:41 PM C Y wrote:

Sounds like a good way to make Axiom more friendly for new (and casual) users.

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

Bill Page wrote:

  What do you think? Is there enough interest in this to declare
  this as an "official" Axiom open source project?

I would say so! We want users, and Axiom's type system is frequently cited as a high hurdle for beginners.

I like the idea of starting out in B-natural, and then for advanced users being able to "drop down" into the current environment when strong typing becomes a tool rather than a distraction. The full power of Axiom is hidden but when the user wants to expand they will find the system able to do so.

On November 22, 2005 7:24 AM Ralf Hemmecke wrote:

We all agree on Aldor as an implementation language, but we have to wait because of licencing problems. It's a pity. :-(

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