Well, that might also be surprising, unless ($) is also magically made to work like a standard operator (just off the top of my head; there may be other confusing aspects). Really, I think the least ad-hoc solution (other than a hypothetical best-of-both-worlds inference algorithm) would be to allow code like: runST do ... where you can apply expressions directly to certain syntactic constructs without an operator in between. I suspect the majority of cases where 'runST $' is used are followed by a 'do,' and not having the remaining ones wouldn't be nearly as painful to use with parentheses (since they likely wouldn't be multi-line). And this extension is desirable for other reasons as well (though I can't recall any specifics off the top of my head). But I wouldn't hold your breath for that. On Tue, Feb 10, 2015 at 4:37 PM, David Feuer <david.feuer@gmail.com> wrote:
On Tue, Feb 10, 2015 at 4:28 PM, Dan Doel <dan.doel@gmail.com> wrote:
Also, I think ($) is the way it is specifically because 'runST $ ...' is considered useful and common enough to warrant an ad-hoc solution. There have been other ad-hoc solutions in the past, but redesigning inference to not be ad-hoc about it would be very difficult at best.
-- Dan
Of the ad-hoc solutions available, I'd personally think the least surprising would be to make f $ x special syntax instead of an operator. The main tricky bit would be preserving source for error messages; the type checker would have to keep track, for each application, of whether it was a standard juxtaposition or whether it used $.