Open cdsmith opened 9 years ago
At least the latter of these could be replaced by pre-checking the source code. Using haskell-src-exts, it shouldn't be too difficult to parse the source code and verify that parentheses are used for every function application.
The analogous technique for binary operators would be far more complicated, since it would require a significant rewriting of the source code before compiling. Then we'd have to match up source locations in resulting error messages, and perform the inverse rewriting when appropriate. This is probably too complex to consider.
There's already a bug open for requiring parentheses on function application. Seems best to solve that with a separate pass outside of GHC, so I'll defer to that one.
The remaining work here, then, is about currying and operators. In a recent email conversation with Richard Eisenberg, he expressed some hope that we could propose this as a GHC feature in a somewhat more general way. The idea would be to propose a feature to overload application. In other words, we'd do the following substitutions: f x
to apply f x
and a + b
==> applyInfix (+) a b
. This is similar to the existing if a then b else c
to ifThenElse a b c
that is already implemented by -XRebindableSyntax
.
Then in codeworld-base, I would just define apply f x = f x
and applyInfix op a b = op (a, b)
.
Ideally, we could tweak GHC to make a few changes that support CodeWorld's dialect of Haskell:
NoCurriedOperators
: The expressionx + y
should desugar to(+)(x, y)
instead of(+) x y
. Operator sections remain unchanged.ApplicationRequiresParentheses
: Makes it an error to writef x
, requiringf(x)
instead. Tuples should not require additional parentheses. Also pretty-prints error messages asf(x)
instead off x
orf (x)
, and disables the logic that uses phrases like "in the first parameter" in error messages.