[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] B#
From: |
Hans Peter Würmli |
Subject: |
Re: [Axiom-developer] B# |
Date: |
Sun, 20 Nov 2005 09:02:31 +0100 |
User-agent: |
KMail/1.7.2 |
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.
- [Axiom-developer] B#, Hans Peter Würmli, 2005/11/19
- RE: [Axiom-developer] B#, Bill Page, 2005/11/19
- Re: [Axiom-developer] B#, root, 2005/11/20
- Re: [Axiom-developer] B#,
Hans Peter Würmli <=
- Re: [Axiom-developer] B#, root, 2005/11/20
- RE: [Axiom-developer] B#, Bill Page, 2005/11/20
- Re: [Axiom-developer] B#, Gabriel Dos Reis, 2005/11/20
- RE: [Axiom-developer] B#, Bill Page, 2005/11/20
- Re: [Axiom-developer] B#, Doug Stewart, 2005/11/20
- Re: [Axiom-developer] B#, Gabriel Dos Reis, 2005/11/20
- RE: [Axiom-developer] B#, Bill Page, 2005/11/20
- Re: [Axiom-developer] B#, Gabriel Dos Reis, 2005/11/20
- Re: [Axiom-developer] B#, M. Edward (Ed) Borasky, 2005/11/20
- Re: [Axiom-developer] B#, Gabriel Dos Reis, 2005/11/20