MArray and runST

[Simon Peyton-Jones]

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 =3D id runST

Now we have=20
	id :: forall a. a -> a

So to apply 'id' to 'runST' we'd have to instantiate the type variable
'a' to runST's type=20
	'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 =3D id wibble

	wibble :: ((forall s. ST s b) -> b) -> b

Why?  For the same reason that this is OK

	foo =3D id reverse

That, is we can instantiate the type of the argument to a monotype (a
type without for-alls). =20

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
|=20
| Keean Schupke wrote:
|=20
| > 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?
|=20
| 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).
|=20
| [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?]
|=20
| -- Dean
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users