Hello,
Another design-pattern which sometimes works pretty well is to
encapsulate commonly used polymorphic types in ordinary data-types
(i.e., use the rank-2 style). Then, the data-type constructors provide
a quick way to---essentially---write a type signature. It seems that
this should work well in combination with mono-bindings.
Unfortunately, I am not sure that this would work for HOOPL (I
haven't looked at the code in detail), so apologies if this is a
red-herring.
-Iavor
On Fri, Dec 10, 2010 at 4:52 AM, Simon Peyton-Jones
Yes, argument to higher rank functions are probably the top reason why MonoLocalBinds is a nuisance.
As of now I think the best thing is to do (1), but define type synonyms that abbreviate the oft-repeated signatures. That should make the signatures much onerous.
Simon
| -----Original Message----- | From: Edward Z. Yang [mailto:ezyang@MIT.EDU] | Sent: 09 December 2010 15:28 | To: glasgow-haskell-users; Simon Peyton-Jones | Subject: MonoLocalBinds and hoopl | | Hello all, | | Here's an experience report for porting hoopl to manage MonoLocalBinds. The | Compiler.Hoop.XUtil module has a rather interesting (but probably common) | style of code | writing, along the lines of this: | | fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) | block | where f n = FF3 $ ff n | m n = FF3 $ fm n | l n = FF3 $ fl n | FF3 f `cat` FF3 f' = FF3 $ f' . f | | f, m, l and cat are polymorphic functions that are only used once in the | main expression, and are floated outside to improve readability. However, | when | MonoLocalBinds is turned on, these all become monomorphic and the definitions | fail. In contrast, this (uglier) version typechecks: | | fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 | . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block | | One suggestion that I had was that we should generalize local bindings that | are only used once, but Marlow pointed out that this would make the | typechecker | more complex and I probably would agree. | | As a userspace developer, I have two options: | | 1. Bite the bullet and put in the polymorphic type signatures (which | can be quite hefty) | 2. Inline the definitions | 3. Move the polymorphic functions into the global namespace | | (3) and (2) are not so nice because it breaks the nice symmetry between these | definitions, which always define f, m, l for the many, many definitions in | Hoopl of this style. | | Cheers, | Edward
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users