Interesting example! | Coincidentally, I tripped over this subtlety myself just last night. (I, | too, often use '$' to avoid nested parentheses.) I concluded it was an | instance of the "partial-application restriction" that I found described in | section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the GHC web | site if you look carefully enough). No, that's not the reason. That restriction has been lifted. Consider this simpler program; foo = id runST Now we have id :: forall a. a -> a So to apply 'id' to 'runST' we'd have to instantiate the type variable 'a' to runST's type 'forall b. (forall s. ST s b) -> b' But GHC only implements predicative polymorphism; it does not allow you to instantiate a type variable with a for-all type. It would be nice to lift this restriction, but I don't know how do to so without losing type inference. Now, the error message you get is deeply obscure, I grant you. Trouble is, this variant IS ok: foo = id wibble wibble :: ((forall s. ST s b) -> b) -> b Why? For the same reason that this is OK foo = id reverse That, is we can instantiate the type of the argument to a monotype (a type without for-alls). So it's not easy to see how to spot the bad case and give a better message. If this comes up again I'll think about it again. Meanwhile, I'm going to put it under "higher-rank polymorphism gives strange error message" file. Simon | -----Original Message----- | From: Dean Herington [mailto:heringto@cs.unc.edu] | Sent: 13 February 2003 14:54 | To: Keean Schupke | Cc: Simon Marlow; glasgow-haskell-users | Subject: Re: MArray and runST | | Keean Schupke wrote: | | > Ahh, I see, perhaps you could give me a clue as to why (or how) this | > works... | > I have probably become a little over keen on using '$' as a general | > replacement for | > braces '(' ')' - the '$' was there because the actual wrapper function | > takes arguments and | > it looks neater not to have too many nested braces. I thought this could | > be something to do | > with runST enforcing strictness, but '$!' causes the same problem, only | > runST (wrapper x y z) | > appears to work - if its not too much trouble, how does runSTs type | > enforce this, and why does | > using '$' and '$!' cause type leakage? | | Coincidentally, I tripped over this subtlety myself just last night. (I, | too, often use '$' to avoid nested parentheses.) I concluded it was an | instance of the "partial-application restriction" that I found described in | section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the GHC web | site if you look carefully enough). | | [Simon: With a few minutes scanning, I couldn't find the same text in the | current online User's Guide. Can you point out where it is?] | | -- Dean | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Peyton-Jones wrote:
Interesting example!
| Coincidentally, I tripped over this subtlety myself just last night. (I, | too, often use '$' to avoid nested parentheses.) I concluded it was an | instance of the "partial-application restriction" that I found described in | section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the GHC web | site if you look carefully enough).
No, that's not the reason. That restriction has been lifted.
Consider this simpler program;
foo = id runST
Now we have id :: forall a. a -> a
So to apply 'id' to 'runST' we'd have to instantiate the type variable 'a' to runST's type 'forall b. (forall s. ST s b) -> b'
But GHC only implements predicative polymorphism; it does not allow you to instantiate a type variable with a for-all type. It would be nice to lift this restriction, but I don't know how do to so without losing type inference.
Now, the error message you get is deeply obscure, I grant you. Trouble is, this variant IS ok:
foo = id wibble
wibble :: ((forall s. ST s b) -> b) -> b
Why? For the same reason that this is OK
foo = id reverse
That, is we can instantiate the type of the argument to a monotype (a type without for-alls).
Sorry, I don't understand yet. Why isn't the "forall s" in wibble's type a problem?
So it's not easy to see how to spot the bad case and give a better message. If this comes up again I'll think about it again. Meanwhile, I'm going to put it under "higher-rank polymorphism gives strange error message" file.
Simon
-- Dean
participants (2)
-
Dean Herington -
Simon Peyton-Jones