Re: language design tradeoffs

jlg@cochiti.lanl.gov (Jim Giles) writes:
[... on statement termination: what if a prefix of a valid expression
is a valid expression, e.g. from SML ...]


      Exactly. That's the purpose of the rule (1) I stated above: to explicitly
      state what should be done with a language in order to avoid this problem.
      In the above, you can't automatically detect the common error 'missing
      statement terminator'. In fact, if you make that common error, you will
      have a `correct' program which does something unintended - a fault which
      may be hard to find in a large program.


But in SML, making an appropriate change would mean getting rid of
currying, and therefore of first order functions. Are you serious?


If "f x" is a valid expression, then "f x y" _must_ be, for the language
to be at all natural. And so must be "f x y z", which immediately gives us
the problem: "f x y z" might be missing an expression separator (;)
between the x and the y. If the type of f is a subtype of


'a -> ('b -> 'c) -> 'b -> 'd


then the typechecker (salvation of all SML hackers) will not catch this
error, since (f x) will be a valid expression and so will (y z).


[... about long expressions, continuation markers etc ...]


      Yes, I do mean the dreaded continuation marker. See my earlier article on
      this question. Continuation is rare and no one does it unless there is no
      other choice. What's wrong with an explicit marker which emphasizes that
      something unusual is afoot?


What's wrong is that in some languages (such as SML) _very_ long
expressions are the norm. Not just one-liners, but twenty-liners. Here's
a short example from code I've been working on lately:


fun skein_uncheckpoint () =
case (SID.get_venari sid) of
NONE => (UndoC.c_uncheckpoint();
raise Skein.Abort) (* indicates bug *)
| SOME SID.OTHER =>
(UndoC.c_uncheckpoint();
raise Skein.Abort) (* indicates bug *)
| SOME (SID.UNDO p) =>
(if within_undo (SID.get_parent sid) then
UndoC.c_anti_inherit (p, active)
else ();
UndoC.c_uncheckpoint ();
UndoC.restore_state p;
UndoC.forget_state active
)


Now the text between (and including) the "(if" and the "active\n)" in that
last case is a single expression. This whole example is actually part of a
larger expression (a let ... in ... end construct) which covers about 50
lines. Almost everything in SML is an expression. There's no way that
this language would be improved by EOL becoming syntactically significant.
(n.b. this piece of code is extremely imperative, I don't want to give the
impression that it's typical of SML).


I think that most of your remarks are doubtless good design for some
languages (I hack C too :-(, and think maybe they could be applied very
successfully there) but there are classes of language to which they don't
seem to apply. (where EOL is significant, in Haskell, I find the so-called
"offside rule" confusing).


Nick Haines nickh@cs.cmu.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.