🚀 go-pugleaf

In article <BvGz2u.2rv.1@cs.cmu.edu> spot@CS.CMU.EDU (Scott Draves) writes:

   [about SLM syntax ...]

   but the answer to your question isn't important.  real programs aren't
   that short.  large lisp functions retain their clarity.  large SML
   functions are horrid messes.  this is taken from the compiler itself
   (something i work on).  i didn't even have to try and find something
   bad...  (* Copyright 1989 by AT&T Bell Laboratories *).

       and getroot(APP(VAR f,wl)) = (f,mix(wl,standardformals wl))

   [...etc...]

With all due respect to the NJ programmers (who have, after all,
provided us with the best free compiler) the compiler is well known
among SML hackers as one of the least legible, least well-structured
large pieces of SML code in existence. It's dying from mouldiness and
sagging under the weight of hacked-on pieces. It's _very_ difficult to
understand or maintain, but this is not a consequence of it being
written in SML. I have worked on other SML systems, at least one of
which is larger than the NJ compiler, and in comparison they are
simple, legible, and maintainable (and _commented_!).

   [...]

   where's the obvious syntax error in this:

   datatype foo = FOO of x
   fun bar FOO x = x

          (     )
Missing parens, of course; you didn't really want a curried function
of type (x -> foo) -> 'a -> 'a, did you? What's the problem? Anyone
who's done much work in SML should recognise immediately that

	fun bar x y = 

defines a curried function. The real problem with the fun syntax is
with infix functions (which IMO are a mistake in the design).

As a hacker who's worked specifically with syntax and parsing problems
in SML, I will be the first to agree that it is not syntactically
perfect. But it's problems are minor compared to a language in which
_every_ structure looks the same. I have also worked with very large
LISP systems and much prefer coding in SML.

Nick Haines nickh@cmu.edu