The difference between ($) and application
On Mon, Dec 13, 2004 at 07:49:00PM -0800, oleg at pobox.com wrote:
The operator ($) is often considered an application operator of a lower precedence. Modulo precedence, there seem to be no difference between ($) and `the white space', and so one can quickly get used to treat these operators as being semantically the same. However, they are not the same in all circumstances. I'd like to observe an important case where replacing the application with ($) in a fully-parenthesized expression can lead to a type error.
I think this post should go under the heading "($) considered harmful". I've been bitten by this, and I never use ($) anymore in place of parentheses because it's too tempting to think of it as syntax. (Of course, it's still useful, by itself or in a slice, as a higher-order operator.)
Andrew
I find this position ridiculous. I don't recall anyone ever posting a message about this (though I'd be far from surprised if someone did). It seems that the people who decide they need higher-rank types are capable of handling type errors involving them, and they certainly don't confuse ($) for syntax. Unless there's a realistic scenario where one suddenly decides one needs some higher-rank types and has to remove a bunch of uses of ($) but otherwise make no changes, I don't see any reason not to use ($) when you can (if you like) and not when you can't. If you ever make a mistake one way the type checker will tell you.
Derek Elkins wrote:
Andrew Pimlott wrote:
I think this post should go under the heading "($) considered harmful". I've been bitten by this, and I never use ($) anymore in place of parentheses because it's too tempting to think of it as syntax.
I find this position ridiculous. [...] If you ever make a mistake one way the type checker will tell you.
For what it's worth, this is not true in the presence of implicit parameters: f :: ((?p :: Int) => Int) -> Int f g = let ?p = 1 in g x,y :: Int x = let ?p = 2 in (f ?p) ==> 1 y = let ?p = 2 in (f $ ?p) ==> 2 I wouldn't mind ($) being magical, along the lines of the magical runST in a rank-1 type system. It would be nice to be able to use it in patterns too. -- Ben
On Tue, Dec 14, 2004 at 01:49:57PM -0500, Derek Elkins wrote:
On Mon, Dec 13, 2004 at 07:49:00PM -0800, oleg at pobox.com wrote:
The operator ($) is often considered an application operator of a lower precedence. Modulo precedence, there seem to be no difference between ($) and `the white space', and so one can quickly get used to treat these operators as being semantically the same. However, they are not the same in all circumstances. I'd like to observe an important case where replacing the application with ($) in a fully-parenthesized expression can lead to a type error.
I think this post should go under the heading "($) considered harmful".
I find this position ridiculous.
By "considered harmful", I mean roughly "shouldn't be taught to beginners". Something that doesn't seem problematic at first, but almost inevitably leads to trouble. I think ($) fits this description. When I first saw the use of ($), I automatically thought of it as syntax. When I saw its definition, I thought it was cool that I could create "syntax" in this way. This is a precarious position. It didn't bite me for a long time, but when it finally did, it took a while to figure out what went wrong, and I had to disband an old idea. To continue using it when it is safe, I would either have to keep thinking of it as syntax, which could lead me into another mistake, or repeatedly verify that it is safe, which would be a drag. Even if I were happy with one of those alternatives, I might be setting a trap for anyone reading my code. So I think ($) as syntax shoud generally be avoided.
I don't recall anyone ever posting a message about this (though I'd be far from surprised if someone did).
I believe I first learned about this issue from a posting. If I hadn't, I may have had even more trouble diagnosing it when it happened to me!
It seems that the people who decide they need higher-rank types are capable of handling type errors involving them, and they certainly don't confuse ($) for syntax.
I doubt that's true. Applications of higher-rank types are pretty common, and I think many people start using them without understanding all the implications. On Tue, Dec 14, 2004 at 07:27:51PM +0000, Ben Rudiak-Gould wrote:
I wouldn't mind ($) being magical, along the lines of the magical runST in a rank-1 type system.
That would be fine. I like a touch of syntactic sugar when it's pure sugar. Andrew
participants (3)
-
Andrew Pimlott -
Ben Rudiak-Gould -
Derek Elkins