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.fe...@gmail.com> wrote:
> On Tue, Feb 10, 2015 at 4:28 PM, Dan Doel <dan.d...@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 $.
>
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
