Oh my god, that was it?<br>I looked at your code for half an hour, and I've never thought about that... That is really misleading.<br>So vector forces you to use strict ST? (That's right: <a href="http://hackage.haskell.org/packages/archive/primitive/0.4.1/doc/html/Control-Monad-Primitive.html#t:PrimMonad">http://hackage.haskell.org/packages/archive/primitive/0.4.1/doc/html/Control-Monad-Primitive.html#t:PrimMonad</a> shows that only strict ST has a MonadPrime instance)<br>
<br>It's another plea against the "sames names/interface in different modules" pattern, that vector, ST, State, ByteString suffer from.<br>This (the error messages being misleading), as well as the document being hard to read (because you never know which type is mentionned, you have to see to check at the module from which the type comes. And even with that, it's just a matter of convention: for instance Control.Monad.State exports the lazy version, but <a href="http://Control.Monad.ST">Control.Monad.ST</a> exports the strict one (so that the default version is closer to IO's behaviour).<br>
<br>I really prefer the approach taken by repa 3: one data family, generic functions for every flavour and some specific functions for each flavour. It's not perfect (not standard for instance), but I think such an approach should be priviledged in the future, it makes things much clearer, and enable you to choose between working generically (on 'Stuff a' types) or specifically (either only on 'Stuff Strict' or only on 'Stuff Lazy').<br>
I would be interested to know if someone has other ideas in that respect in mind.<br><br><br><div class="gmail_quote">2012/6/9 Nicu Ionita <span dir="ltr"><<a href="mailto:nicu.ionita@acons.at" target="_blank">nicu.ionita@acons.at</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, the error was: I was using Control.Monad.ST.Lazy. Importing <a href="http://Control.Monad.ST" target="_blank">Control.Monad.ST</a> compiles immediately without problem. (Is this because I'm using unboxed mutable vectors?)<br>
<br>
Now, that's a little bit odd.<br>
<br>
It's clear that the strict and lazy forms of ST are different types. But unfortunately they are named the same! So actually any error message from the compiler drives you crazy, because it's refering to another type.<br>
<br>
Probably the reason to name the types with the same name is for easy interchangeability. But as we see, the types are not (always) interchangeable.<br>
<br>
Anyway, now it compiles.<br>
<br>
Thanks,<br>
Nicu<br>
<br>
Am <a href="tel:08.06.2012%2023" value="+33806201223" target="_blank">08.06.2012 23</a>:15, schrieb Nicu Ionita:<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I created a gist with a minimal (still 111 lines) module:<br>
<br>
<a href="https://gist.github.com/2898128" target="_blank">https://gist.github.com/<u></u>2898128</a><br>
<br>
I still get the errors:<br>
<br>
WhatsWrong.hs:53:5:<br>
Couldn't match type `s' with `PrimState (ST s)'<br>
`s' is a rigid type variable bound by<br>
a type expected by the context: ST s [Move] at WhatsWrong.hs:48:21<br>
In a stmt of a 'do' block: listMoves ml<br>
In the second argument of `($)', namely<br>
`do { v <- U.new maxMovesPerPos;<br>
let ml = ...;<br>
listMoves ml }'<br>
In the expression:<br>
runST<br>
$ do { v <- U.new maxMovesPerPos;<br>
let ml = ...;<br>
listMoves ml }<br>
<br>
WhatsWrong.hs:65:44:<br>
Couldn't match type `s' with `PrimState (ST s)'<br>
`s' is a rigid type variable bound by<br>
the type signature for nextPhaseOnlyCapts :: GenPhase s<br>
at WhatsWrong.hs:64:1<br>
Expected type: U.MVector (PrimState (ST s)) Move<br>
Actual type: U.MVector s Move<br>
In the return type of a call of `mlVec'<br>
In the third argument of `genCapts', namely `(mlVec ml)'<br>
<br>
Thanks,<br>
Nicu<br>
<br>
Am <a href="tel:08.06.2012%2002" value="+33806201202" target="_blank">08.06.2012 02</a>:47, schrieb Silvio Frischknecht:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now comes my question: in the impure values there is always that<br>
"s". I was thinking that the whole structure should have s as a<br>
parameter:<br>
</blockquote>
Yes<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
data MList s = MList { mlVec :: MVector s Move, mlNextPh :: MList<br>
-><br>
</blockquote>
ST s (Maybe (MList s)) }<br>
</blockquote>
you probably meant:<br>
<br>
data MList s = MList { ... , mlNextPh :: Mlist s -> ... }<br>
<br>
Now I'm not sure about your exact problem since the following compiles<br>
for me.<br>
<br>
import Data.Vector<br>
import Data.Vector.Mutable<br>
import <a href="http://Control.Monad.ST" target="_blank">Control.Monad.ST</a><br>
<br>
type Move = ()<br>
data MList s = MList {<br>
mvVec :: MVector s Move,<br>
mlNextPh :: MList s -> ST s (Maybe (MList s)) }<br>
<br>
splitMove :: MList s -> ST s (Maybe (Move, MList s))<br>
splitMove ml = do<br>
m<- unsafeRead (mvVec ml) 0<br>
undefined<br>
<br>
Something you always have to watch out for when dealing with ST is not<br>
to return something that depends on s in the last statement (the one<br>
you use runST on). In other words, if you want to return a vector you<br>
have to freeze it, so it's not mutable anymore.<br>
<br>
If you still can't figure it out paste some complete example that<br>
doesn't work.<br>
<br>
silvio<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iQIcBAEBAgAGBQJP0Uu5AAoJEDLsP+<u></u>zrbatWKFoP+<u></u>wYdmAwO3aKPIibOydDwPlcu<br>
GmwWLCDoylhBsA1swskPGZTlBevFFe<u></u>S0kzDMAhZ2dtR18HHf0TVLFCL6mljg<u></u>QGhu<br>
YLsT8a2Y5eepPd7CC0wHD7qLH0t6ln<u></u>/<u></u>urRhWNnVEGryVHmsIDCBzuKBzopsha<u></u>aOm<br>
8awNeEbmZApki193r/<u></u>YJ21Zsxidx4N2tSGCd712ka9Wr7l19<u></u>RzBukonTy/wNCTtN<br>
1sj54xCKap3MpnQe4L68nep6WjMovn<u></u>wn5ucPWlouPP5N99/<u></u>2umiEPDwX3y9moD/Q<br>
VkbYe0HzZtvSX7JJaDM/<u></u>hJ2dWKHsg5CLdO/aW7Uz3HttTy0/<u></u>FmvwhxaNAzkmQimw<br>
L4uakvyuw1EJuSAwB5XRfeUL6LDpka<u></u>165jb8V8Iy2gjYg3aGMwf9VVmObjEA<u></u>A93s<br>
nvQd+<u></u>iH1lDe38cbfz8dfQdTakDVYtFNnYL+<u></u>kXIF1Z7DiS25IThtS0RJRH//E+CZg<br>
MpOtW2LBfa3vwP9NqVryGTAhWFtWHX<u></u>OtpXfCXOa0+<u></u>pQNn1zHkTXtIDJ4XoT5qkmd<br>
6GDwFyGfkPZO01qNMoXwj/wBz/<u></u>eaSa4Vj0qb73jNdNH2MbJ13Ws9Jlp4<u></u>jwcxbG4a<br>
m/fYV0/6LmPEiV8H9+<u></u>4cG8nhUP2ie2DJqo8tzdjiaZ7C7TEy<u></u>m9jd6gsljMQ8qiAG<br>
Q7aAmMed/DBlY/Anh2xY<br>
=X9CL<br>
-----END PGP SIGNATURE-----<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>