1 2 3 | ||

Editor: test1
Time: 2023/09/18 17:17:45 GMT+0 |
||

Note: |

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

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.

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