🚀 go-pugleaf

In article <TMB.92Sep28223555@arolla.idiap.ch> tmb@idiap.ch writes:
>   >I think in order to fulfill their promise in this area, functional
>   >programming languages should probably go back to Lisp notation.
>
>   (I
>     (Don (' (t
>		(think
>		      (so)))))) (!).
>
>Well, in SML, that would be:
>
>   I(
>     Don( Q( t(
>		think(
>		      so()))))) (bang).
>
>That doesn't look any prettier to me.

Nor to me, but I think that it is a bad example to use anyway. So lets
try something to show the readability a bit better.  Consider the
factorial function. In scheme it would be:

(define fac
 (lambda (n)
  ( if (= 0 n)
    1
    (* n (fac (- n 1))))))

Is that enough brackets?! ;-)

In SML:

fun fac 0 = 1		   [ or  fun fac n = if n=0 then 1 else n*fac(n-1); ]
|   fac n = n * fac (n-1) ;

Now which is easier to read?!!!(Given that you are well versed in both
notations) Even with such a simple example, it's not obvious that the
close brackets at the end of the lisp version are enough, where it's
immediately obivous that the ML version has the correct syntax.
 
With long programs, the ease with which you can read them becomes very
important. I can imagine that with a long lisp program, checking that
all the brackets are in the right place could become a nightmare,(though
a good programming style would alleviate some of the worst cases), where
the ML equivalent would allow you to forget this particular gripe.

Also infix notation is nicer(though ML allows you to chose between infix
and prefix notation), though I won't make a major song and dance about
that as it is not difficult to get used to prefix notation.

>Seriously, I somehow doubt that the "gain in readability" from putting
>your parens after your function names, not having to put parens around
>"let" and "if", and using infix for the occasional numerical operation
>(NB, I write a lot of numerical code myself), is really worth it
>compared to the difficulties such irregularities in syntax cause for
>tools, tool writers, and simple-minded human readers like me. But, all
>these things are a matter of taste, and I don't want to start a flame
>war.

The original poster was talking about the ease with which one lisp
program could manipulate another(or itself), not readability as such.
I'm not well enough versed in either language to comment on this issue
save to say that a long SML program would be easier to read and debug
than a lisp equivalent IMHO. SML was developed as a theoretical language
with the aims being to make a good programming language that eliminated
the features of other languages that could lead to bugs(counting
brackets seemed to be regarded as such). It combined the powerful lambda
calculus of lisp and other functional languages with a strong datatyping
system with easily extensible datatypes and support for abstract
datatypes. As such many programs can be proven equivalent or correct
mathematically in SML, since the notation is highly mathematical.

In this I'm not saying SML is perfect though, just what it's strengths
are. One disadvantage(compared to Lisp) of it I can already think is that
all the elements of a list must be of the same type and this is probably
what leads to some difficulties in manipulating ML programs themselves with
ML where Lisp programs are Lisp lists. Another disadvantage caused by
the typing system is that functions can only return values of the one
type(in some cases this can be dodged by defining a new aggragate type
though). Of course this might be seen as theoretically 'good' by some
people though. I don't having seen OOP using scheme where the 'objects'
are functions which take messages which determine what happens and also
what messages are returned(which leads to functions returning other
functions or numbers or strings or anything really...).


James
-- 
  James Hammerton,2nd year Computer Science at University of Edinburgh
  Email: jamesh@uk.ac.ed.castle   Or: jh@uk.ac.ed.dcs