🚀 go-pugleaf

In article <DBM.92Sep28220940@ai.allegra.att.com> dbm@allegra.att.com (Dave MacQueen) writes:

   It is certainly nice to be able to manipulate programs in terms of a
   straightfoward structural representation.  However, this doesn't mean
   that one has to be content with a primitive concrete syntax such as
   Lisp's.  It suffices to have a parser that translates one's concrete
   syntax into a more convenient representation for manipulation by
   programs.

I agree, it doesn't mean that, but it makes it somewhat easier since
then both the reader and the machine have a better idea of what the
other is "talking about". In my case it's not a question of "being
content with a primitive concrete syntax", but actually preferring it.
But there are lots of people with either kind of taste, and it is
pointless to argue which is "better".

Still, I have yet to see tools that can indent SML code properly and
consistently; their lack already is an indication to me that there is
_some_ problem with the syntax as it is. I'd like to be proven wrong
in this perception...

I will admit, though, that I don't see how Lisp syntax goes in a
straightforward way with the way SML handles arguments, since one of
the things I like about SML syntax is the seamless way in which tuples
double as "first-class argument lists". Fortunately, thanks to the
availability of ast's in the next release of NJ/SML that you just
announced, we all will have ample opportunity to experiment.

   Actually, I would prefer to move further away from Lisp style syntax.
   One of the unfortunate aspects of SML syntax is the overloading and
   consequent over-use of parentheses.  Parentheses play three main
   roles:

    (1) grouping (this is the most fundamental role)

    (2) bracketing tuples as in (1, true, "abc")

    (3) bracketing sequence expressions, as in (print "a"; print "b")

   I would prefer to use different notations for (2) and (3).  Angle
   brackets would be appropriate for (2), but are unfortunately not
   available in ascii (maybe it's time to move on to the ISO Latin 8 bit
   character set?).  For (3) the traditional Algol "begin ... end"
   notation would probably be fine.

Well, I'm not so sure I agree. I think (3) should not matter, since
imperative programming is the exception, not the rule in SML (right?).
And I don't see much of a conflict between (1) and (2); in particular,
I like the fact that function calls with tupled arguments look
"normal" ("f(x,y,z)") right now.

Incidentally, instead of "begin ... end", you can use "let in ... end".

Also, ironically, if you use currying frequently, your expressions will
end up looking like Lisp expressions anyway:

	map (compose (invert f) (invert g))
            (sublist l (position l x) (3 + position l x))

"Asymptotically", the number of parens is the same...

					Thomas.