RE: MonoLocalBinds and hoopl
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:ezy...@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
Re: New codegen failing test-cases
Ok, I've got a patch that fixes this segfault. In the process I looked at all patches to Cg* modules after Nov 2009 and looked for changes that weren't applied to the new codegen. I skipped the LLVM patch, but picked up the rest of the blackhole changes. There are, however, two hunks that I am not 100% sure how to translate. hunk ./compiler/codeGen/CgClosure.lhs 477 - stmtC (CmmStore (CmmReg nodeReg) bh_info) + stmtsC [ + CmmStore (cmmOffsetW (CmmReg nodeReg) fixedHdrSize) + (CmmReg (CmmGlobal CurrentTSO)), + CmmCall (CmmPrim MO_WriteBarrier) [] [] CmmUnsafe CmmMayReturn, + CmmStore (CmmReg nodeReg) bh_info +] (the new code uses emits and a different format) hunk ./compiler/codeGen/CgStackery.lhs 20 - pushUpdateFrame, emitPushUpdateFrame, + pushUpdateFrame, pushBHUpdateFrame, emitPushUpdateFrame, A new pushBHUpdateFrame function was added, but I'm not sure how to translate this because the new codegenerator only reads out the offset from the FCode monad and there's no label to speak of. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
build issue: * Missing header file: HsBase.h
Hello, I'm trying to recover my opensolaris builder machine after disk crash, but after reinstall I'm not able to build any GHC there. I'm trying head and now also 6.12.3 as a reference (as I'm able to build it on my workstation with the same OS). The problem I see here is when I invoke `gmake' then the process continues up to configuration of base library which fails with: checking value of ETIMEDOUT... 145 checking value of ETOOMANYREFS... 144 checking value of ETXTBSY... 26 checking value of EUSERS... 94 checking value of EWOULDBLOCK... 11 checking value of EXDEV... 18 checking value of ENOCIGAR... -1 checking value of SIGINT... 2 checking value of O_BINARY... 0 checking for library containing iconv... none required configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h configure: WARNING: unrecognized options: --with-compiler ghc-cabal: Missing dependency on a foreign library: * Missing header file: HsBase.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. gmake[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 gmake: *** [all] Error 2 The problem is HsBase.h is where it is on my reference build tree on workstation: -bash-4.0$ find . -name 'HsBase.h' ./libraries/base/include/HsBase.h -bash-4.0$ I suppose some external library might be missing, but here the error is quite misleading and I cannot find which one might be the culprit of this error. Do you have any idea what to install in order to proceed? Thanks! Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and hoopl
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 simo...@microsoft.com wrote: 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:ezy...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Type families status
Is it safe to consider type families and associated type families extensions for ghc as stable ? Wich related extensions (flexible contexts, undecidable instanses and so on) may be deprecated or changed in near (2-3 years) future and wich may not? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
