Re: [Axiom-developer] B#

[Hans Peter Würmli]

On Sunday 20 November 2005 07.05, root wrote:
> if you do
>  )lisp (trace pf2sex)

pf2sex is currently missing in the Debian distribution, so I can't try.

> ... It should
> be possible to write USER algebra domain that captures
> this, parses it, and allows you to manipulate it as a
> tree expression.

Yes, this is probably possible, but probably difficult, too, if one does not 
know enough about Lisp and the way the interpreter works now (for which Lisp 
knowledge is probably necessary, isn't it). Parsing an S-expression looks 
like analysing something untyped (with Lisp or Axiom) that is untyped. As as 
colleague of mine once remarked "strong typing is for the weak of minds" I 
have to admit that I have a very weak mind. That's also how I would excuse my 
preference of Haskell over Lisp: strong versus no typing. I have noticed with 
several of your and Bill's answers that you quickly assume a user's dislike 
of typing, if unease with the interface is expressed (please forgive me if 
I'm wrong, I don't intend to criticise somebody who does such great work). 

At least in my case its different: I have a liking for syntactic sugar and a 
dislike of opacity. The way the current Axiom interface handles user input, 
is relatively opaque (but admittedly, I neither know all the tools, nor have 
I kept notes to build "documentation").

But to get back to your advice: where would you start, if you wanted to build 
such a USER algebra domain?
                  
Let me give some examples of what I would consider nice syntactic sugar, and 
it must be syntactic sugar as the evaluation of any expression is ultimately 
extremely simple as explained at the end of section 5 of the "Axiom as 
Scratchpad" article.

1) TeX-like conventions: being able to define, say, variables as x_{i,j} looks 
very handy. One should actually go further and allow type annotations, like

x_{i:NNI,j:PI}:POLY INT,

or even further and allow "operators" as syntactic elements, like defining a 
few variables as (or the sum example in "Afterthoughts, ...")

for i in 0..5 repeat x_i:POLY INT

This actually seems to be nothing else than polymorphism of the function 
"for", if - as the manuals claim - types are first class citizens.

2) Afterthoughts: if "==" generally would point to a rewrite rule then 
exending eval to an eval ( expr, List 'Rewrite Rules' ) would semantically be 
the same as the "afterthoughts". It looks to me that this is the regular 
evaluation mechanism of any functional programming language. (Currently an 
expression like x==t has the type Void; I wonder what would happen if this 
construct came under programming control.)

3) Pattern-matching and functional paradigm: it's probably the type of pattern 
matching and currying from Haskell that I miss most. Actually, I don't have 
the feeling that it is entirely missing, not at all, but the ease of use of 
Haskell is certainly missing.

Thank you for the comments and have a nice Sunday

H.P.