- ghc-devs - Haskell.org

Cleaning up rather silly static arguments
by David Feuer 16 Sep '14

16 Sep '14

Aside from anything having to do with the foldrW/buildW stuff, I decided to try a little experiment using fusing scanl and reverse (implementations at http://lpaste.net/2416758997739634688 ) When I define scanr f b = reverse . scanl (flip f) b . reverse I get this: scanr1 scanr1 = \ @ a_akP _ eta_Xb -> eta_Xb scanr scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> letrec { go_amb go_amb = \ ds_amc eta1_Xa eta2_B2 eta3_Xc -> case ds_amc of _ { [] -> eta1_Xa eta2_B2 eta3_Xc; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) eta2_B2 eta3_Xc }; } in go_amb eta_B1 (scanr1) b_ah9 (: b_ah9 ([])) go_amb takes four arguments, two of which, eta2_B2 and eta3_Xc, are static. What makes this seem particularly silly is that we already have all the structure we need to get rid of them—all that remains is to actually delete them and replace them with the values they take: scanr1 scanr1 = \ @ a_akP _ eta_Xb -> eta_Xb scanr scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> let { listend listend = : b_ah9 ([])} in letrec { go_amb go_amb = \ ds_amc eta1_Xa -> case ds_amc of _ { [] -> eta1_Xa b_ah9 listend; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) }; } in go_amb eta_B1 (scanr1) Now I certainly wouldn't claim this is particularly *good* code, but it seems significantly more reasonable than before. If I were to try to find a way to get rid of these things, should I try hacking on the static argument transformation, or would it fit better in the simplifier, or somewhere else? David

2 1

Building on Windows
by Neil Mitchell 16 Sep '14

16 Sep '14

Hi, I just successfully built GHC on Windows. Last time I tried (5 years ago) it took days. This time, it took hours, plus a bit of waiting for a Windows specific breakage to be fixed. I made a log of what happened, what confused me, what wasn't clear etc - hopefully these provide suggestions for improving the wiki (if my thoughts are actually correct). The worst aspect is that the Windows wiki page has 6 sets of instructions, with no obvious way to pick the right one - everything else was pretty minor. Thanks, Neil My first step was to Google "build ghc on windows", which took me to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows "The instructions are current for GHC 7.6" - so they are not current. "Other documentation for Windows includes:" - here are 5 alternate links, any of which may be better/worse than this one. I have no way to tell. As a piece of documentation, giving the uninformed user 6 options with no sensible way to make a decision is awful. Simon PJ had said "MSYS2" works well, so I clicked that one. Even though it appears to be the "wrong" one according to the wiki. Is it the correct one? If so, replace the Windows page with it. If not, perhaps indicate which one is. "It should get you running in ~5 minutes, modulo download speeds." - nice! It's a long way from being true, since you also need to include extraction times and build times (which on my machine far outweight download times). There were also enough hiccups that it took me about an hour of clicking/typing, excluding the Windows specific bug I ran into. If I have 64bit OS, should I pick 64bit Windows? Or only if I want to develop 64bit Windows, which isn't the default? Fortunately my machine is old enough to be 32 bits so I didn't have the difficult question. It's far easier to edit the PATH file manually with $ cygpath -w ~, which returns C:\msys32\home\Neil, than to echo stuff to it. In particular, if you echo anything wrong, you need to edit it anyway. "Do not install python, python2 or gcc!" - it's not entirely clear how to achieve that. It installed gcc-libs, is that a problem? I'd have liked a better "check" step, e.g. run "gcc --version", "ghc --version" and exactly what I should expect, what indicates a problem etc. e.g what should i be on the lookout for to say Python doesn't build. I followed the step to upgrade my system, but it failed: :: Starting full system upgrade... :: Replace msys2-base with msys/filesystem? [Y/n] (55/55) checking for file conflicts [######################] 100% error: failed to commit transaction (conflicting files) bash-completion: /etc/profile.d/bash_completion.sh exists in filesystem coreutils: /etc/DIR_COLORS exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/java/cacerts exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists in filesystem filesystem: /etc/profile.d/lang.sh exists in filesystem filesystem: /etc/profile.d/tzset.sh exists in filesystem filesystem: /etc/skel/.inputrc exists in filesystem filesystem: /mingw32_shell.bat exists in filesystem filesystem: /mingw64_shell.bat exists in filesystem filesystem: /msys2_shell.bat exists in filesystem grep: /usr/bin/egrep exists in filesystem grep: /usr/bin/fgrep exists in filesystem rebase: /autorebase.bat exists in filesystem Errors occurred, no packages were upgraded. I just ignored that, and continued, and that seemed to go OK... /ghc-7.6.3/ didn't work, I needed to go /c/ghc/ghc-7.6.3/ for the paths. Perhaps make it clear which are absolute paths, and which you have to edit. Perhaps you were hoping I'd symlink the GHC path? Any reason for the && commands in the final list of commands? isn't one per line cleaner? It also lets you retry the right bit when something fails. checking for version of happy... 1.18.4 configure: error: Happy version 1.19.4 or later is required to compile GHC. Nice - this was a useful check that made it easy to fix and continue. $ make -j3 + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk 2 [main] make 6024 child_info_fork::abort: C:\msys32\bin\msys-unistring-2.dll: Loaded to different address: parent(0x250000) != child(0x7C0000) make: fork: Resource temporarily unavailable This error repeated. On a hunch I ran "autorebase.bat" from msys32, and restarted my shell, then it worked - I have no idea which fixed it. "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) I fixed that by applying the patch from https://ghc.haskell.org/trac/ghc/ticket/9598. With that, I could build to completion. An empty build (nothing to do) takes 1m50s which is a bit sad, but it does work. After all this there are exactly two things I want to know (both of which would be useful links from the bottom of the building on Windows page): * How do I update to the next day, resync and rebuild. In particular, should i sync-all or not (a link to another page is fine) * How do I run the tests.

1 0

Shake based build system for GHC
by Thomas Miedema 15 Sep '14

15 Sep '14

Hello SPJ (cc Neil Mitchell), on IRC it was brought up that there will be someone at GHC headquarters working on a Shake based build system. Can you tell us a little bit more about these plans. I wanted to try implementing this as well, but am happy to work on something else. Kind regards, Thomas Miedema

2 2

in ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it
by George Colpitts 15 Sep '14

15 Sep '14

In ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it. ghc-pkg check shows I have no issues, e.g.: bash-3.2$ cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ ghc-pkg check bash-3.2$ Other packages that have this problem include alex, and an example of a package that doesn't have this problem is vector. Should I file a bug? bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3") ,("Global Package DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d") ] bash-3.2$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d: Cabal-1.18.1.4 GLURaw-1.4.0.1 GLUT-2.5.1.1 HTTP-4000.2.10 HUnit-1.2.5.2 OpenGL-2.9.2.0 OpenGLRaw-1.5.0.0 QuickCheck-2.6 array-0.5.0.0 async-2.0.1.5 attoparsec-0.10.4.0 base-4.7.0.1 bin-package-db-0.0.0.0 binary-0.7.1.0 rts-1.0 bytestring-0.10.4.0 case-insensitive-1.1.0.3 containers-0.5.5.1 deepseq-1.3.0.2 directory-1.2.1.0 fgl-5.5.0.1 filepath-1.3.0.2 (ghc-7.8.3) ghc-prim-0.3.1.0 hashable-1.2.2.0 haskeline-0.7.1.2 haskell-src-1.0.1.6 (haskell2010-1.1.2.0) (haskell98-2.0.0.3) hoopl-3.10.0.1 hpc-0.6.0.1 hscolour-1.20.3 html-1.0.1.2 integer-gmp-0.5.1.0 mtl-2.1.3.1 network-2.4.2.3 old-locale-1.0.0.6 old-time-1.1.0.2 parallel-3.2.0.4 parsec-3.1.5 pretty-1.1.1.1 primitive-0.5.2.1 process-1.2.0.0 random-1.0.1.1 regex-base-0.93.2 regex-compat-0.95.1 regex-posix-0.95.2 split-0.2.2 stm-2.4.2 syb-0.4.1 template-haskell-2.9.0.0 terminfo-0.4.0.0 text-1.1.0.0 time-1.4.2 transformers-0.3.0.0 unix-2.7.0.1 unordered-containers-0.2.4.0 vector-0.10.9.1 xhtml-3000.2.1 zlib-0.5.4.1 /Users/gcolpitts/.ghc/x86_64-darwin-7.8.3/package.conf.d: Cabal-1.20.0.2 MonadRandom-0.3 aeson-0.6.2.1 auto-update-0.1.1.2 bifunctors-4.1.1.1 blaze-builder-0.3.3.3 cmdargs-0.10.9 comonad-4.2.2 conduit-1.2.0.2 contravariant-1.2 cpphs-1.18.5 data-ordlist-0.4.6.1 distributive-0.4.4 djinn-ghc-0.0.2.2 djinn-lib-0.0.1.2 dlist-0.7.1 either-4.3.1 exceptions-0.6.1 free-4.9 ghc-mod-5.0.1.2 ghc-paths-0.1.0.9 ghc-syb-utils-0.2.2 haskell-src-exts-1.15.0.1 hasktags-0.69.0 hlint-1.9.4 hoogle-4.2.34 http-date-0.0.4 http-types-0.8.5 io-choice-0.0.5 json-0.7 lifted-base-0.2.3.0 mmorph-1.0.4 monad-control-0.3.3.0 monad-journal-0.2.3.2 mwc-random-0.13.2.0 nats-0.2 polyparse-1.9 prelude-extras-0.4 profunctors-4.2.0.1 resourcet-1.1.2.3 safe-0.3.8 scientific-0.3.3.1 semigroupoids-4.2 semigroups-0.15.3 shake-0.13.2 simple-sendfile-0.2.17 streaming-commons-0.1.4.2 strict-0.3.2 stylish-haskell-0.5.10.2 tagged-0.7.2 tagsoup-0.13.2 text-1.2.0.0 transformers-base-0.4.3 transformers-compat-0.3.3.4 uniplate-1.6.12 unix-compat-0.4.1.3 unordered-containers-0.2.5.0 utf8-string-0.3.8 vault-0.3.0.3 vector-0.10.11.0 vector-algorithms-0.6.0.3 void-0.6.1 wai-3.0.1.1 warp-3.0.1.1 yaml-0.8.9.1 bash-3.2$

1 0

Compiling on Windows
by Neil Mitchell 15 Sep '14

15 Sep '14

Hi, At ICFP Simon Peyton Jones encouraged me to compile GHC on Windows. I did so in the past about 5 years ago, and it was a painful experience. To help improve the path for those who come after me, I kept a log (which I'll share after I get a working build). My current state is that I get an error while running make while building stage2: "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o on the commandline: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Any idea how to overcome that? I note from the weekly update email that there was an email on Windows last night, but a "./sync-all pull" doesn't make it go away. Thanks, Neil

2 1

Random infrastructure requests, questions and suggestions
by Jan Stolarek 15 Sep '14

15 Sep '14

Herbert, Austin, all, I have some questions and suggestions regarding our infrastructure: 1. Would it be possible to add a new custom field to Trac called "Wiki page"? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. 2. I often want to get from the ticket view to index of all wiki pages. Sadly, ticket view only has links to previous ticket/next ticket in the top right of the page. So to get to the index of wiki pages I need to go to any of the wiki pages in the left panel and only then the link to wiki index appears in the top right of the page. Would it be possible to have link to wiki index also in the ticket view? 3. Is it possible to enable tooltips in Phabricator? I'm not yet all that familiar with the interface and having icons that have no text and no tooltip is problematic. I need to actually click on it to see what it does (or figure it out from the link target). 4. When browsing the code in diffusion I see that my name is not linked to my phabricator account, for example here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/ Why is that happening? 5. I was thinking that perhaps harbormaster could also measure performance changes resulting from a patch, eg. by running nofib. I'm not sure if that's easy to implement or not and whether we have enough computing power to do that but I thought it's worth sharing that idea. Janek

5 6

Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
by Moritz Angermann 15 Sep '14

15 Sep '14

Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for arm-apple-ios): globalRegMaybe After some digging I found that a new call to globalRegMaybe was introduced here: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on 2014-04-29 in commit: http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf33534… In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was changed: http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a… introducing a set of new ifdef/elif/endif pairs. Especially for MACHREGS_NO_REGS, namely: -#endif globalRegMaybe _ = Nothing +#elif MACHREGS_NO_REGS +globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic "globalRegMaybe not defined for this platform" +#endif ARM.hs (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169e…) however, has: #define MACHREGS_NO_REGS 0 #define MACHREGS_arm 1 where MACHREGS_arm 1 has no effect on the subsequently imported CodeGen.Platform.hs. Therefore I propose that a change to ARM.hs is made to set MACHREGS_NO_REGS to 1. Cheers, Moritz

3 6

Preliminary proposal: Monoidal categories in base and proc notation support
by Sophie Taylor 15 Sep '14

15 Sep '14

>Hi Sophie, >In your proposal draft, I am missing the rationale part. Yeah, I'm still writing it - I definitely need to expand that a bit mor. >Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward.

3 4

Re: Preliminary proposal: Monoidal categories in base and proc notation support
by Edward Kmett 15 Sep '14

15 Sep '14

The current categories package tries to let you reuse bifunctors of the form c * d -> e across base categories, so that e.g. Kleisli m can use (,) for its product, etc. (in general it isn't a real product for Kleisli m, but let's pretend) this means we have to adopt a 3 for 2 policy wrt the categories involved. c e -> d, c d -> e, d e -> c, but when inferring from first or second you usually only know one, but also only need one other, but can't know the third from context, since no arrow is supplied. It is underdetermined. Hask avoids this by presupposing a single set of categories for every Bifunctor, but it is a conceit of the package that this is enough in practice, not something I know, and we pay a measurable price for this. A lot of stuff is more complex there! The current hask design, as opposed to the one I gave a talk on and the design of categories loses a lot of what powers lens and the like in exchange for this simpler story. I don't make that change lightly and I'd hesitate to make that change across the entire ecosystem. It hasn't proved it is worth the burden yet. In exchange for this complexity it is able to find simplicity elsewhere, e.g. Bifunctor in hask is a derived concept from a Functor to a Functor category, which models the curried nature of the arguments to a Bifunctor. My main point is there are a lot of points in the design space, and I don't think we're equipped to find a clear winner right now. Sent from my iPad > On Sep 15, 2014, at 3:53 PM, Sophie Taylor <sophie(a)traumapony.org> wrote: > > Oh darn, really? That is so disappointing. Why can't it maintain inference? :\ > >> On 15 September 2014 23:44, Edward Kmett <ekmett(a)gmail.com> wrote: >> I find PFunctor/QFunctor finer grained than is tasteful. Alas, they are necessary for inference for first/second in practice unless you require the Bifunctor to determine the category of both of its arguments. The hask package is exploring other ways to maintain inference. >> >> If you try to actually use the current categories package without them, well, nothing infers. >> >> Sent from my iPad >> >>> On Sep 15, 2014, at 11:32 AM, Sophie Taylor <sophie(a)traumapony.org> wrote: >>> >>> >Hi Sophie, >>> >>> >In your proposal draft, I am missing the rationale part. >>> Yeah, I'm still writing it - I definitely need to expand that a bit mor. >>> >Do we need *all* of these classes in base in order to desugar proc? Can >>> you demonstrate why they are needed? Or will something simpler suffice? >>> >>> I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. >>> With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

GHC Weekly News (was: Status updates)
by Austin Seipp 15 Sep '14

15 Sep '14

Hi *, Note the title change. After some discussion with Simon last week, we decided to change up the name a bit, since we want the discussion on - As Gabor mentioned on the list earlier, I accidentally broke the Windows build. I'm sorry. :( We really need to get Phab building Windows too ASAP... I'm working on a fix this morning. (There are still a lot of upstream changes waiting to go into the Phabricator code base.) - I sent out the HCAR draft this morning. Please edit it! I think we have a few weeks of lead time however, so we're not in a rush like last time. But I will remind you. :) - The server migration for ghc.haskell.org seems to have gone pretty smoothly in the past week. It's had plenty of traffic so far. The full migration is still ongoing and I want to complete it this week. - I've finished reorganizing some of the Git and Repository pages after some discussion. We now have the Repositories[1] page, linked to on the left side, which details some notes on the repositories we use, and links to other various pages. I'm thinking of replacing this side-bar "root" with a link to the main Git[2] page, perhaps. - Miscellaneous: ghc.haskell.org and phabricator.haskell.org now sets the "Strict-Transport-Security" header. This just means you always use SSL now when you visit those pages (so you can't be connection-hijacked via a 503 redirect). - I'm merging some patches at the moment, although the windows fix is currently what I'll push first: D205, D204, D203, D199, D194, D179, D174. Do let me know if there's anything you want me to look at. - GHC works on Wine apparently for all you Linux users - thanks Mikolaj![3] - Jan had some questions about infrastructure which I just followed up on this morning. In particular: does anyone feel strongly about his first question?[4] - Herbert committed the first part of the Traversable/Foldable changes, by moving the typeclasses to Prelude. This is part of an ongoing series of patches. Things like adding Bifunctor will finally come after this.[5] Also, added bonus: we'll start including some of the tickets we closed this week. Closed tickets for the past week include: #9585, #9545, #9581, #6086, #9558, and #3658. Please let me know if you have any questions. [1] https://ghc.haskell.org/trac/ghc/wiki/Repositories [2] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git [3] https://www.haskell.org/pipermail/ghc-devs/2014-September/006283.html [4] https://www.haskell.org/pipermail/ghc-devs/2014-September/006275.html [5] https://phabricator.haskell.org/D209 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0