On Fri, Jul 14, 2006 at 01:17:59AM -0700, ***@gmx.at wrote:
> Rob Thorpe wrote about Lisp:
> > Within a statement you can define anything you want.
> > You could write a form called "arith" for example that did normal
> > arithmetic with precedence etc if you wanted.
> > (arith 4 + 6 * 3)
> > You could implement it with a macro so it expanded into normal code at
> > compile time.
> You don't get rid of the parantheses around the call of the
> 'arith' function.
But you could by using read macros. The reason people don't (and also
the reason people don't use infix arithmetic) is that it's unlispy; you
just don't write Lisp code that way. However, that doesn't mean it isn't
possible. You could probably implement a read macro that parsed C-like
syntax and converted it to Lisp code if you wanted to.
> > It is true to say that in lisp there is not associativity or
> > precedence.
> The 'arith' function has to interpret the precedence (execute * before
> + is executed) itself? This would be an interpreter written in Lisp.
No. Arith would be a macro, which means the translation is done at
compile time. At run time, it would be just like the user had written (+
4 (* 6 3)) to begin with.
> > Since there are no operators there is no overloading.
> You say it yourself: Lisp has no (infix) operators and therefore
> no operator overloading.
Depending on what you mean by that. There certainly is overloading in
Common Lisp; you can say
(defmethod foo ((x integer)) ...)
(defmethod foo ((x complex)) ...)
and get two versions of foo, one working on integers and another on
complex numbers. You could do the same for +, although it is a bit more
involved, because + isn't a generic function the way it's initially
defined, so you'd have to hide the previous definition first, then
introduce a new one.
You can still complain that + isn't an operator, but (1) I don't see why
you so badly want to have operators with associated special status in
your language (2) you can make it behave just like + in languages where
it is a special operator if you really want to, and (3) who says it's
not? just because it uses prefix notation like everything else doesn't
mean it isn't a special operator (in Scheme, for example, + is special
in the sense that it's undefined what happens if you try to redefine
> > But you can define any syntax for statements you like, so long as you
> > define a statement as everything inside a list after the first element.
Actually, read macros lift that restriction.
> As you say a Lisp 'statement' has to be written in list form, like
> (cond ((= n 0) 1)
> ((> n 0) (* n (! (- n 1)))))
(loop for i from 0 and for x in xs collecting (cons i x))
which doesn't look like it has Lots of Irritating Superflous
Parentheses, does it? (It doesn't do the same as the code above, by the
> You don't get rid of the list notation with parentheses (Before the
> first element of the 'statement' you have to write '(' and after the
> last element of the 'statement' you have to write ')').
Again, unless you use read macros to break this rule. And you don't
break the rule, because that would make the code harder to understand.
> > This isn't that different to most languages with this capability where
> > what you can define is everything from the first word to a terminator
> > like ';'.
> There is a big difference to
> if n = 0 then
> result := 1;
> elsif n > 0 then
> result := !(n - 1);
> end if;
Yes. And whether you prefer that or
((= n 0) 1)
((> n 0) (not (- n 1)))))
(assuming that is what your code means), is a matter of, well,
preference. Probably, it's also influenced by what you're used to.
> Defining new statements is not only a story about the definition
> of the statement semantics (what Lisp is capable to do) but is
> also about the statement syntax (which Lisp can only aproximate).
Again, unless you use read macros.
> I know that you can define your 'arith' function (with interpreted
> priority and assoziativity) and your user defined 'statements'
> (with an approximation of the syntax using lots of
> parentheses) in Lisp.
You should know this is wrong by now.
> But is the syntax check and the type
> check done at compile time?
Syntax checks: yes.
Type checks: generally not, though many implementations will give you
> If you want to reuse the + operator to add 'colors', can you
> just write something like (in Seed7):
> const func color: (in color: col1) + (in color: col2) is func
> var color: result is color.value;
> result.red_part := (col1.red_part + col2.red_part) div 2;
> result.green_part := (col1.green_part + col2.green_part) div 2;
> result.blue_part := (col1.blue_part + col2.blue_part) div 2;
> end func;
> and it just works?
You can do this with any generic function. + isn't a generic function,
but you can redefine it to be. After that's done, you can write:
(defmethod + ((col1 color) (col2 color))
(make-color (/ (+ (color-red-part col1) (color-red-part col2)) 2)
(/ (+ (color-green-part col1) (color-green-part col2)) 2)
(/ (+ (color-blue-part col1) (color-blue-part col2)) 2)))
> While Lisp has its reasons, I think that lack of precedence,
> lack of overloading (In Lisp functions are identified with a
> name) and the missing possibility to define the syntax of
> new statements in Lisp is a weakness.
> - Lisp does not have (infix) operators.
Which is considered an advantage, because it simplifies the syntax of
the language. This makes macros easier to implement and understand.
> - There are no user defined operators (just functions).
I don't know what characteristic of operators you want that Lisp cannot
> - Overloading of operators does not exist.
Depends on your definition.
> - The statement syntax can not be defined in Lisp.
It's not like Lisp doesn't have any weaknesses, but I don't count the
things you mention to be among them. Probably, this is largely due to
you and I having different ideas about how things should work; it seems
that you insist a language must have infix operators, whereas I would
rather have uniform syntax. Also, you seem to have some misconceptions
about what is and what isn't possible in Lisp.
> I suggest you take a closer look at Seed7. May be there are
> things you like, and if not you can send me patches with
> improvements. :-) This is open source everybody is welcome.
I think you did a great job making Seed7 flexible and powerful. Still, I
probably wouldn't like programming in it, because it's syntax is too
verbose for my liking (although I guess this could be redefined using
syntax declarations), and the need to declare types everywhere.
Some things that might be interesting for you to investigate:
- Common Lisp Object System. It's very powerful and flexible, although
I find the class declaration syntax painfully verbose. A few macros
solve that problem, of course.
- Common Lisp's package system. Some people hate it, other people love
it. I only know it provides namespaces, mechanisms to prevent and
resolve name clashes, and mechanisms to hide symbols.
- Common Lisp's condition system. Like exceptions, but generally
offering more options for recovery, including an interactive
- Common Lisp's numeric tower: arbitrary precission arithmetic,
rational and complex numbers, and all using a unified interface.
- Scheme's first class continuations (call/cc).
- First class, higher order, and anonymous functions (does Seed7 have
- Type inference (as in ML)
- Lazy evaluation (as in Haskell) or lazy data structures (e.g. as
discussed in "How to Add Laziness to a Strict Language Without Even
- Parallel programming
- Distributed programming
Just some things that I find interesting. I don't know how much you have
looked into any of these.
Q: Why is it that programmers always confuse Halloween with Christmas?
A: Because 31 OCT = 25 DEC.