[MLton] can mlbasis rename the top-level?

[Vesa Karvonen]

Quoting Matthew Fluet <fluet@cs.cornell.edu>:

> [MLB] is not there to be your default programming 
> environment.  So, you pay a small cost (in this case, the visual 
> delimiter) to use it for a secondary purpose.

I see what you mean, but I still think prettier syntax is prettier syntax.
Who knows what happens in the future. Maybe someone designs some really nice
SML libraries for doing what traditional scripting languages do and everyone
starts using MLBs for scripting. ;-)

> But, think of it from the user's point of view.  Suppose I have:
[...]
> Did you catch the unclosed parethesis?

About 5 seconds after reading your question, but...

> If so, then you are a better reader than I.  (And, yes, emacs would give a
> hint as well.)

I wouldn't have made the error in Emacs (as I use expression highlighting).

In all fairness, if we agree that people would mostly be using the feature to
embed short snippets of SML, then I don't find this a convincing argument. The
shorter the snippet of code is, the faster you can spot unbalanced parentheses.

I would also expect that parentheses would be relatively rare in embedded SML.
The reason for this is that you would mostly be dealing with modules and renaming
top-level declarations. Not much need to use parentheses there.

> But, suppose you sent this to mlton.  What's likely to happen is that you
> completely throw the parser off.  Worse, if you had an extra close parenthesis
> in the middle of the SML code (i.e., ending the embedded SML early), then
> you're likely to have a horribly opaque MLB parse error pointing into the
> middle of what is manifestly SML code.

Isn't that (having too many/few parens inside the SML code) also possible
with the {<{ and }>} delimiters?

Unless I'm mistaken, use of {<{ and }>} only makes it easier to see that the
MLB delimiters are in place. It doesn't seem to help with delimiters inside
the embedded SML code.

> Similarly, if you try counting {local,let,sig,struct}...end blocks, an SML 
> parse error might manifest itself as an inexplicable MLB parse error.

That seems preferable to me. To be more precise, I think that it would be
better to get a parse error while parsing the MLB file rather than possibly
much later while parsing the embedded SML code. It seems to me that counting
blocks would allow earlier reporting of errors.

-Vesa Karvonen