RE: [Axiom-developer] B#

[Page, Bill]

Tim, 

On Thursday, March 23, 2006 9:35 PM you wrote:
> 
> re: quote
> 
> nope. i agree with this rather insightful quote though:
> BOOT is toast. :-)

I'll pass on that one.

> 
> re: the future of aldor
> 
> there are some sticky IP issues with aldor. Manuel was a
> major contributor and he is no longer able to agree to
> donate his code.

I thought this only applied to some of the Aldor libraries
and specific packages written for Aldor. Or did he also
"own" some of the source code to Aldor itself?

> i'm in discussion with people associated with INRIA about
> making his code and research available but that, like
> everything else, moves at a (pre-global-warming) glacial
> pace.

I am glad you are looking at this. Frankly I really don't
understand why any of this is an "issue" at all. I can not
see how limiting access to research benefits anyone and it
surprises me that some people apparently think that providing
free and open access could somehow diminish their own interest
in the work. Given the Internet, being the type of community
that it is today, it seems to me very remote the chance that
anyone might unduly exploit such work without giving full
and complete credit to the original authors.

> 
> re: aldor replacing spad
> 
> aldor may or may not replace spad. that's a huge task. and
> it will be made worse because it's unlikely that any one
> of us will be willing to perform a straight spad to aldor
> conversion without generating numerous opinions regarding
> "better ways to do this" (witness the ongoing Monoid/Ring
> discussion).

It is a big task, but investing time in this now makes more
sense than continuing to "patch up" the old stuff - just as
it did when IBM originally set out to develop Aldor as
version 2 of the Axiom library compiler. I think psychology
suggests that we can count on much more enthusiastic
support for continuing with this forward-looking plan
rather than the option of trying to correct past "mistakes".

I don't see a problem with people agreeing on a one-to-one
SPAD to Aldor conversion as the first phase of this task.
There are always going to be "better ways" to do something
and usually these apply equally well to both SPAD and Aldor.
We can make note of these and get on with the main task...
And this can be done in an incremental manner, converting
a few SPAD routines with each new release until there are
now SPAD modules left.

> 
> even without that level of issue it's tempting to try to
> break the algebra cycles using post-facto extensions. this
> will generate more very interesting but, to the actual
> implementers, painful discussion.

That is a good example of what I mean. Post-facto extension
is not really a fundamentally new idea. One can easily do
the same thing in SPAD. It goes like this:

  1) Write a SPAD "stub" that includes incomplete function
     prototypes ignoring the dependencies.
  2) Write SPAD code that depends on these prototypes and
     defines new functions.
  3) Write the SPAD "extension" that replaces the prototypes
     with actual function definitions in terms of those
     functions defined in 2).

As I understand it, all that Aldor's post-facto extension
does is make this process a little "prettier" by providing
a syntax that explicitly references the code in step 1).
That this possible at all depends on the internal design
for dispatching functions calls that is basic to SPAD. We
could use this approach now in SPAD to break the algebra
cycles. But if we do a one-to-one conversion of SPAD to
Aldor then we can (at initially) keep the current bootstrap
process as is.

> 
> re: B-natural
> 
> B-natural won't replace the interpreter because the real
> semantics of an expression is carried in the type. B-natural
> has the essential goal of hand-waving away the type issues
> to make it easier for people who don't care about the type.

No. Have you read the actual B# paper? There is no "hand
waving". The user interacts with only one type - the UserType.
The UserType in turn has a well-defined relationship to the
underlying types defined in the Axiom library.

> but i believe this raises some very hard coercion/conversion
> questions which will turn out to be fundamental.

Could you give some examples of such coercions or conversions
that you think might be hard or impossible to resolve without
fundamental changes in the approach?

> 
> we would probably get further faster by working out the exact 
> coercion/conversion graph and formalizing the mechanism.

I agree that that is an essential part of the design of B# -
at least between the UserType and the Axiom library.

> then we could make the interpreter smarter as well as extend
> it to special domains (e.g. to interval arithmetic which does
> not preserve the distributive property).
> 

Making the current Axiom interpreter "smarter" is a harder
problem then just implement B# which side-steps the general
problem by introducing the UserType.

BTW, isn't it true that Axiom's existing Float domains already
do not preserve the distributive property? Does interval
arithmetic really add anything new (besides intervals)?

Regards,
Bill Page.