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: Sun, 20 Nov 2005 22:17:21 -0500

On November 20, 2005 10:16 PM Tim Daly (root) wrote:

> 
> Two comments. Lisp IS strongly typed. It just associates the type
> with the object and not with the box (variable) it comes in. That
> is, it distinguishes a TV from the box labelled TV as the type is
> related to the object and not the box. Other "strongly-typed"
> languages don't so once you say a box (variable) is a TV box you
> can't put anything else in it.  You can spot a Box-Typed language
> because it forces you to coerce your entertainment center to a TV
> to put it into a TV box. Exactly why you would want to consider
> the TV and the box it came in to have any fixed relationship is
> beyond most lispers.

I think this is a great analogy! :-) In technical jargon we
would translate "box-typed language" to statically typed.

Of course there is very good reason to want to have this fixed
relationship between a box and it's contents: You don't have to
look inside to know what's in there! Every shop keeper knows the
advantage of that and every consumer knows they should probably
open the box before they leave the story. ;)

> (Bad Tim slaps his own wrist for joining in another language war)

No, don't do that.  This is just another friendly Sunday afternoon
discussion... :)

> 
> Bill's interest in B-natural could easily be grounded in BOOT
> code. Taking the BOOT language as a starting point and expanding
> the syntax and semantics to include the other paradigms would get
> us a long way toward a B-natural compiler. Some of the ideas in
> the Jenks/Trager paper are already implemented with a compiler
> and running code. Expanding the syntax and the compiler are
> probably easier tasks than trying to start from scratch.

Yes, I see the similarity between Boot and B# since Boot is a
lot like Spad without the static type system. But I think the
point of B# is as a entry-level programming language for new
Axiom users. This would be an alternative to the programming
language that is normally accessed through Axiom *.input files
and is part of the Axiom interpreter. Currently the programming
language in the Axiom interpreter is closely related to the
Spad programming language that is accessed via the )compile
command. Although the interpreter makes attempts to relieve the
burden of assigning types to objects by a series of heuristics,
The language is still essentially strongly and statically typed.

The purpose of Boot of course is/was very different being focused
on the internal design of Axiom and never appearing at the user
level. I am not convinced that the best path to B# would be through
Boot.

> 
> Presenting a USER type that can be programmed in an extended
> BOOT language is reasonable. Indeed, the experiment could
> eventually influence the syntax and semantics of the Spad
> compiler language. The goal is to make it easier to express
> mathematics. The current syntax used by non-computational
> mathematicians is horribly ambiguous.
> 

I would not use the word "ambiguous" in reference to Spad,
since it does require complete specifications of types, but
I would agree that the syntax is not ideal for the non-
computational mathematicians. I think that most people do at
least initially view the strong type system as a hindrance.
It is only later as they become experienced computationally
oriented mathematicians that they may really appreciate the
purpose of the type system. However Spad as the Axiom library
compiler is specifically targeted for the experienced Axiom
user so this is as it should be.

As I understand it, the idea of B# was as an intermediate
language for Axiom that would appeal more to these initial
users of Axiom - not to be a replacement for Spad. In my
opinion, the evolution of Spad reached it's most desirable
state of development in Aldor. But I don't think that a similar
solution exists yet for the Axiom user interface.

Regards,
Bill Page.






reply via email to

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