merits of Lisp vs Python

[Jon Harrop]

Raffael Cavallaro wrote:
> On 2006-12-16 13:58:37 -0500, Jon Harrop <jon at ffconsultancy.com> said:
>> Why do you think that uniform syntax is necessary to provide new
>> paradigms when it is equivalent to infix syntax?
> 
> Because it doesn't require one to write a parser for each new syntax
> for each new paradigm.

Why not use a single, extensible parser, e.g. camlp4?

>> In what way is Haskell's support for imperative programming limited?
> 
> It requires one to frame everything in functional terms or to jump
> through the hoop of monads.

Can you give some example code demonstrating these hoops?

>> Can you give an example of a Lisp macro that does something useful that
>> you can't do in these other languages?
> 
> It isn't a question of "can't do in these other languages," it's a
> matter of "can't do as easily in these other languages."

Yes, absolutely.

> Look at kenny 
> tilton's cells. Its a dataflow paradigm built largely of macros. It 
> goes completely against the semantics of haskell - cells is all about
> the eager evaluation of side effecting state mutation.

Perhaps that is because Cells is written in a language (Lisp) that forces
you to jump through hoops to get lazy evaluation?

The Cells project appears to deal with a graph (in the graph-theoretic
sense). There is nothing inherently side-effecting about that and the
problem that Cells is trying to solve seems to be fundamentally lazy:
update cells only when necessary.

> Could you do it 
> in haskell? Yes, in the greenspun/turing-completeness sense, but not
> nearly as easily as in common lisp, because the very paradigm - eager
> evaluation combined with side effecting state mutation - goes against
> the basic semantics of haskell.

Can you give some evidence to back that up, e.g. a program that solves a
problem like this in Haskell but is more convoluted that the Lisp?

> You'd have to jump through extra hoops 
> to build a system whose very nature contradicts two of the semantic
> foundations of haskell - laziness and absense of side effects.

What if eager impurity isn't the "very nature" of the problem but, rather,
is the very nature of Tilton's chosen solution?

> Then there's the issue of the new syntax. Easy to build in lisp without
> learning another language - lisp macros use lisp.

You can use Lisp macros to add some of the features found in modern FPLs.
Once you've done that, users of your modern Lisp variant must learn how to
use your macros. How is that better than learning a modern FPL directly?

> What little I've seen 
> of caml4p looks like perlesque line noise. Ultimately I think that the
> defaults of both haskell and ocaml - functional, static typing,
> non-uniform syntax - are things I don't want as defaults, but as
> options for later in the development of only certain pieces of code. I
> don't want to be required to jump through the pure-functional,
> must-use-monads-for-any-side-effects, static-type, non-uniform-syntax
> hoops to express my ideas. It makes me less flexible in dealing with
> individual parts of a program differently.

You can use tools like camlp4 to generate uniform syntax from OCaml's
syntax. You can also use the -dlambda to output OCaml's Lisp-like
intermediate representation.

Why do you think that uniform syntax like this Lisp:

(defun intersect (orig dir scene)
  (labels ((aux (lam normal scene)
             (let* ((center (sphere-center scene))
                    (lamt (ray-sphere orig
                                      dir
                                      center
                                      (sphere-radius scene))))
               (if (>= lamt lam)
                   (values lam normal)
                   (etypecase scene
                     (group
                      (dolist (kid (group-children scene))
                        (setf (values lam normal)
                              (aux lam normal kid)))
                      (values lam normal))
                     (sphere
                      (values lamt (unitise
                                    (-v (+v orig (*v lamt dir))
center)))))))))
    (aux infinity zero scene)))

is better than syntax with conventional mathematical grammar, like this
equivalent OCaml:

  let rec intersect orig dir (lambda, _ as hit) (center, radius, scene) =
    let lambda' = ray_sphere orig dir center radius in
    if lambda' >= lambda then hit else match scene with
    | Sphere -> lambda', unitise (orig +| lambda' *| dir -| center)
    | Group scenes -> List.fold_left (intersect orig dir) hit scenes

>From my point of view, people started with Lisp and used its macros to add
new syntax to the language and they got Haskell and OCaml. After all,
Haskell and OCaml are more popular that any given Lisp variant with similar
features (e.g. pattern matching), AFAIK.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet