[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NOISE] Curly braces [was Re: Curl]
- To: <address@hidden>
- Subject: Re: [NOISE] Curly braces [was Re: Curl]
- From: "Oliver Steele" <address@hidden>
- Date: Sun, 2 Dec 2001 19:56:14 -0500
- Sender: address@hidden
- Xref: oroboros.ai.mit.edu ll1-discuss:244
[Second try, with a From: that the mailing list will accept.]
Olin Shivers <firstname.lastname@example.org> writes:
> And yet... ML's syntax *is* annoying. It's a real pain to indent
> well, not only by emacs mode, but even when choosing a good layout
> by hand. Experienced ML programmers complain about this. The
> problems emacs has parsing ML, and ML fragments, mean that moving
> around code buffers, or selecting syntactic chunks of code, is not
> very good. This is also quite annoying. The token "=" is used in
> about three different syntactic contexts; urk.
All indentation schemes are not created equally. I've found Haskell to be
relatively difficult to indent (in emacs, with or without haskell-mode),
while Python is easy (in emacs and a variety of lesser editors). (C, Lisp,
and Java are also easy, although they're a different category of language in
that the indentation is redundant with the syntax.) I suspect it's because
the rules for increasing/decreasing indentation levels in the "easy"
languages are so simple: in Python, for example, a test for ':\s*(#.*)\n' is
almost sufficient to indicate an increased level on the following line. In
Haskell, on the other hand, the possibility of nested 'with', 'do', and
'let...in' expressions requires a CF parser.
One could draw various morals for language designers, some of which converge
to the pro-S-expression arguments already discussed.
> I find paren-haters are always people that haven't done much or any
> programming in Scheme or Lisp. Once you've done it, you see the power
> and beauty of the s-expression syntax framework. GLS described this
> journey in an earlier msg, when he talked about Lisp programmers who,
> as beginners, implement and then subsequently abandon, infix syntaxes.
> It's not just an oversight that Lisp syntax is the way it is!
I wonder if this is sampling bias --- people who hate parentheses don't go
on to do much programming in Scheme or Lisp.
Anyway, I've been programming Lisp for about fifteen years, about half of
that (non-contiguous) professionally, and I still haven't acclimated --- I
still prefer infix, although not enough to maintain my own syntactic
dialect. (I'm therefore also in the category of programmers who has
implemented and abandoned an infix syntax.) Maybe I'm just missing some
crucial neural substrate, and therefore shouldn't be qualified over by the
"always" statements that come up in these syntax discussions --- nor should
I appreciate the power of macros and cps (and there used to be some other
advantages of Lisp and Scheme before pure functional languages became
marginally usable for real-world programs and before Python picked up
lexical scoping and generators) but now I find myself considering the
tradeoff for each project: will the domain language I end up building be
sufficiently different from a general-purpose computing language that it's
worth starting out with Lisp so I can build it more easily, or will Python
get me 90% of the way there, or Haskell all the way there, with less effort.
> S-expression syntax rocks. If it looks ugly to you, then, to me, that just
> means you haven't yet had the full experience.
Dan Weinreb <email@example.com> writes:
> How many of you actually know
> by heart the complete ranking of operator precedence in, say, C or C++
> or Java or any of these lanaguges that use infix math syntax? The
> last time I looked, one usually ends up with something like twenty
> levels of precedence. I put in parens rather than try to memorize all
> that or, perhaps more to the point, assume that the reader of my code
> have memorized it.
Indeed, style guides for C++ suggest only relying on a few levels of
operator precedence and using parentheses to disambiguate the rest. So the
criticism of this family of languages as having too many levels of operator
precedence is valid when applied to the language design and misuse, but not
to the subset recommended by current practice.