-fno-monomorphism-restriction makes type-inference ambiguous?
Hi, thanks for the last help and hints. I have encountered an other problem, and again I don't quite understand the reason why I get the results I get. ghci seems to infer different types for the same expression. Consider that I have disabled the monomorphism restriction in module AGC.lhs (which is attached). and I have a toplevel definition of:
mylength = synAttr listLength
loding the module in ghci (6.4) gives (beside some correct warnings): $ Ok, modules loaded: Main. $ *Main> :type synAttr $ synAttr :: (Data b) => ((?stack::[Dyn]) => b -> a) -> Attr a $ *Main> :type listLength $ listLength :: (?stack::[Dyn]) => List -> Float $ *Main> :type (synAttr listLength) $ (synAttr listLength) :: Attr Float $ *Main> :type mylength $ mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float $ *Main> let mylength = synAttr listLength $ *Main> :type mylength $ mylength :: Dyn -> Dyn -> [Dyn] -> Maybe Float where
type Attr a = Dyn -> Dyn -> [Dyn]-> Maybe a
the problem I have is that inferred types for the toplevel declaration mylength differ from the verbatim equal definition in the Let experssion. for the toplevel it infers: mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float for the let-Binding mylength :: Dyn -> Dyn -> [Dyn] -> Maybe Float and this is what I expected. Has anyone an Idea, why this happens? best regards, Eike Scholz PS: Beware of the comments in the attached file. This file is under heavy development. I am dyslexic and don't correct the comments while continuously rewriting code and comments. I hope that the comments are useful anyway. The (+>) (~>) (#>) operators are broken at the moment and don't work the way intended.
Implicit parameters are *evil*. They seem to simplify programs but they make reasoning about them much harder. To an extent, they can be simulated with type classes, because dictionaries are also implicit (you don't see them in the code but you see them in the type declaration - same as for implicit parameters). Of course reasoning about programs with typeclasses is hard as well, but at least at the moment all instances (dictionaries) are global. On the other hand, this also limits the usefulness of type classes. In all, it's a design choice. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Mon, Feb 27, 2006 at 04:42:32PM +0100, Johannes Waldmann wrote:
Implicit parameters are *evil*. They seem to simplify programs but they make reasoning about them much harder.
Indeed. We really need some big caveats in the manual. I find a lot of new users think they are what they need and just end up frustrated and don't like to hear "Oh, you shouldn't have used those" after the fact.
To an extent, they can be simulated with type classes, because dictionaries are also implicit (you don't see them in the code but you see them in the type declaration - same as for implicit parameters).
I think a Reader monad is the best way to do this sort of thing, converting to real parameters is as simple as 'ask' and even better yet when you realize you need something trickier like the ability to collect values or a unique name supply, stacking a WriterT or a StateT or whatever is simple after the fact. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
Eike Scholz -
Johannes Waldmann -
John Meacham