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 $.