Multiline expressions
Posted: January 25th, 2012 | Author: Mars | Filed under: Uncategorized | 2 Comments »I had a few extra minutes last night and decided that it would make more sense to tackle something small and complete it than to simply peck away at the big async project. I cherry-picked something easy from the low end of my priority list and implemented support for multiple-line expressions.
Radian is a line-oriented language, not a curly-brace language, so end-of-line signals the end of a statement. This is awkward when you are composing a long expression; the line has to keep sprawling off toward the right.
Of course there are many places in an expression where end-of-line would always be an error. Once you’ve opened a parenthesis, for example, you must close the subexpression before the outer expression can end.
The scheme I chose was to skip any end-of-line which occurs after a binary operator token. That is, in any expression of the form exp 'foo' exp, you can insert an end-of-line after the ‘foo’ and continue the expression on the following line.
Another strategy might have been to focus on grouping tokens: parentheses, brackets, and braces. Any end-of-line found inside such a group must also be an error, no matter where in the expression it appears, so it could reasonably be stripped.
I chose the binop-focused syntax instead, though, because it makes life easier for editing tools. With the grouping approach, you’d need to identify the beginning of the statement – which may be an arbitrary number of lines above – before you can be certain whether the current line is the beginning of a statement or the continuation of some expression.
With the binop approach, you need only look at the last token of the previous line: if it is one of a known list of operators, then you know the target line is a continuation rather than a new statement. This will make life a lot easier on developers of syntax highlighters and code-formatting tools.
If the argument or list separator counts as a binop, then I think the simplification will not be unduly restrictive.
That is indeed the case.