RE: [Axiom-developer] B#

[Bill Page]

On November 20, 2005 3:03 AM Hans Peter Würmli wrote:
> 
> 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.

I also can not find any reference to 'pf2sex' in my copy of
the Axiom sources. Is this really what you meant Tim?

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

I do not think that s-expressions is what Jenks and Trager
had in mind when they talked about "GREAT". Although lisp
s-expressions are certainly one way to represent a tree
structure, there are better representations of expression
trees that would probably be more suitable for the purposes
of B#.

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

It is not accurate to suggest that Lisp has no typing - quite
the opposite. But Lisp uses strong *dynamic* typing where all
values have types and this type information is strongly enforced
but in general (recent extensions to Lisp not withstanding) the
Lisp variables do not have types.

Haskell, Spad and Aldor on the other hand have strong static
typing which applies directly to both variables and values; and
which can be determined at "compile-time" rather than "run-time"
as is the case with Lisp.

I wonder if your colleague who said: "strong typing is for the
weak of minds" really knows what "types" in computer programming
really are? But I agree with you. I also have a weak mind in that
sense and strongly prefer a language which is an aid to the way
I think about a problem. I think human programmers (and
mathematicians, too :) need all the help we can get from the
computer.

I do prefer Haskell over Lisp for many purposes but it is not
becase Lisp is not a typed language.

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

I thought that this was your point because of your reference
to the Jenks and Trager paper which is mostly devoted to the
issue of a typed versus and untyped user interface language for
Axiom.

> 
> 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?

I think that a lot of work has already been done in Axiom to
support the concept of a USER algebra domain - specifically in
the Expression constructor. Expression implements many of the
ideas that Jenks and Trager assume for the type USER. The other
domain in the Axiom interpreter that implements some of these
ideas is ANY. I think of the type USER as sort of a cross
between these two.

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

I think you are mixing sugar with semantics here. It does not
make sense to me to associate types with superscirpts and
subscripts if these are just symbols. But if they are not
symbols then we need to decide what the use of subscript
means, e.g. if x is a matrix then the subscripts might
denote a reference to an element of a matrix. It is not
clear to me what meaning might be associated with your
example.

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

As I understand it, this syntax actually denotes 6 names,
x_0 x_1 ... x_5 all of type POLY INT, is that right?

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

Could you explain how you think of "for" as a function in this
example?

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

Could you please explain this a little more. I do not think
of == as involving any type of evaluation.
 
> (Currently an expression like x==t has the type Void; I wonder
> what would happen if this construct came under programming
> control.)

What type would you suggest?

> 
> 3) Pattern-matching and functional paradigm: it's probably 
> the type of pattern matching and currying from Haskell that
> I miss most.

Axiom supports currying of functions. You might recall some
discussion between myself and William Sit about this. But I
agree that Axiom does not provide quite the same kind of
syntactic sugar for currying as does Haskell. But Axiom is
not a purely functional language so I think it has more
constraints to satisfy in it's choice of syntax.

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

I have to agree with you on both counts.

> 
> Thank you for the comments and have a nice Sunday
> 

You too!

Regards,
Bill Page.