[Axiom-developer] [BNatural] (new)

[Bill Page]

Changes http://wiki.axiom-developer.org/BNatural/diff
--
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://portal.axiom-developer.org/refs/articles/axiom-scratchpad.pdf/view

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

--
forwarded from http://wiki.axiom-developer.org/address@hidden