axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] B#


From: Bill Page
Subject: RE: [Axiom-developer] B#
Date: Mon, 21 Nov 2005 10:29:36 -0500

On November 20, 2005 11:41 PM Tim Daly (root) wrote:
> 
> I suggested the BOOT language because some of the ideas are
> already implemented there. Making it a standalone language
> would give us a place to play with various syntactic and
> semantic changes. Starting to build a compiler from scratch
> would be a lot of work.
> 

After re-reading the Jenks and Trager article "How to Make
AXIOM Into a Scratchpad",

http://portal.axiom-developer.org/refs/articles/axiom-scratchpad.pdf/view

I think it is clear that B# should not be conceived of as an
non-statically typed language like Boot, but rather as a language
in which there is only one mathematical type. The authors call
this single type 'USER'. I think this is a rather poor choice
of name for the domain. Really it seems to me to be just a
generalization of the existing Axiom domain constructor
'Expression' that allows all of the kinds of manipulations of
expressions that are common in other systems like Maple and
Mathematica.

Presumably the B# language would also include some additional
data structure types like List, Array etc.

This difference between Boot and B# is important because it is
presumed that all of the objects in the USER domain can be
coerced into objects in the underlying Axiom domains just as
it is possible now to say:

(1) -> A:Expression Integer:=2*x+1

   (1)  2x + 1
                                     Type: Expression Integer
(2) -> A::Polynomial Integer

   (2)  2x + 1
                                     Type: Polynomial Integer

--------

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.

It seems to me that Boot is too low a level at which to build
such a language. And further it does seem to make a lot of sense
to me to think of this as a "stand alone" language. I think it
must be built on top of the Axiom library, not beneath it or in
parallel with it. This means that B# should be written in Spad.

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.

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:

(1) -> repl()$Bnatural

Of course this could be hidden for first time users within the
initial axiom.input file.

After invoking the repl, the user's interaction would be
controlled by the B# package as described in the Jenks and
Trager article.

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

Regards,
Bill Page.






reply via email to

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