- ghc-devs - Haskell.org

RFC: Phabricator for patches and code review
by Austin Seipp 25 Jun '14

25 Jun '14

Hello all, Recently, while doing server maintenance, several of the administrators for Haskell.org set up an instance of Phabricator[1], located at https://phabricator.haskell.org For those who aren't aware, Phabricator (or "Phab") is a suite of tools for software development. Think of it like a polished, semi-private GitHub with a lot of applications and tools for all kinds of needs. We've been using it to do issue tracking for Haskell.org maintenance and like it a lot so far. One very nice aspect of Phabricator though is it has a very nice code review tool, called 'Differential', that is very useful. For people who have used a tool like Review Board, it's similar. Furthermore, it has a very convenient userland tool called 'Arcanist' which makes it easy for newcomers to post a review and get it merged when it's ready all from the command line. I'd like to see if people are interested in using Phab _strictly_ for code review of GHC patches. It is a dedicated tool specifically for this, and I think it works much better than Trac or inline GitHub comments. Also, Phab can also support post-commit reviews. So if I touch something in the runtime system and just push, perhaps Simon or Edward would like to look, and they can be alerted right when I do this, and then yell if I did something stupid. Before I go much further, I'd like to ask: is there *any* interest in this? Or are people satisifed with Trac? The primary motivations are roughly, in no particular order: 1) Code review is good for everyone, a good way for people to learn the code and ask questions, and useful to give feedback to newcomers. And even experienced GHC hackers can learn things from reading code, as we all do regularly, or find things that need cleanup. 2) Phabricator in particular makes it very easy to submit patches for review. To submit a patch, I just run the command 'arc diff' and it Does The Right Thing. It also makes it easy to ensure people are *alerted* when a patch might be relevant to them. 3) They can be uploaded and created from the command line, and merged easily afterwords the same way. This is particularly useful for newcomers, and for me. :) 4) Differential is dedicated to code review, and much better at it than just reading patches on Trac IMO. 5) It supports both post-commit code review, as well as pre-commit review. Post commit would be especially useful for us too, I think. Point #2 and #3 are mostly relevant for me, because I mostly handle incoming patches. But I think in general it would be nice, and make it a lot easier for newcomers to submit patches, and us to look over them. Here's an example of a Differential code review: https://phabricator.haskell.org/D4 This is a demo using my 'wip/ermsb' patch. You'll need to create an account to login, but it shouldn't be much trouble, you can login several ways. I'll fix the login requirement soon. Feel free to read the code, comment on it, and play around. It's more of a demonstration, but real code review would be welcome too. :) If people are interested in doing this, I can add notes to the wiki pages for newcomers, and I'll send another email about Phab so people can understand it a little better. But I want to ask first. There is an argument that our team is so small, code review has unnecessary burdens. But I think Phab could help a lot with tracking outside patches and getting good reviews for incoming patches, and it'll make it easier for newcomers. And experienced pros can probably learn a thing as well. Again, to be clear, I don't propose we migrate anything to Phabricator from, say, Trac. There's no real pressure to do so and it would be tons of work. I only propose we use it for code review, which is perfectly fine, and how other projects like LLVM do code review (they use Bugzilla). I also don't think the usage of Phabricator should be mandatory (unless we decide that later because we like it), but I would like to see people use it if possible. [1] http://phabricator.org -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

12 32

Re: validator1-linux-x86-head (Linux/x86 HEAD (Mateusz Kowalczyk)), build 18, Failure
by Herbert Valerio Riedel 25 Jun '14

25 Jun '14

Fyi, this also broke on the nightly PPA builds (which made me notice it): https://launchpadlibrarian.net/178475113/buildlog_ubuntu-precise-i386.ghc-h… Cheers, hvr On 2014-06-25 at 05:42:57 +0200, Builder wrote: > validator1-linux-x86-head (Linux/x86 HEAD (Mateusz Kowalczyk)), build 18 > > Build failed > Details: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > booting | Success > configuring | Success > compiling | Failure: Just (ExitFailure 2) > > Build failed > Details: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18.html [...] > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140624 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1Q6 > assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 > libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed > Makefile:64: recipe for target 'all' failed > make: *** [all] Error 2

1 0

Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
by Mateusz Kowalczyk 25 Jun '14

25 Jun '14

On 06/24/2014 07:47 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc… > >> --------------------------------------------------------------- > > commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > Author: Johan Tibell <johan.tibell(a)gmail.com> > Date: Mon Jun 9 11:43:21 2014 +0200 > > Add more primops for atomic ops on byte arrays > > Summary: > Add more primops for atomic ops on byte arrays > > Adds the following primops: > > * atomicReadIntArray# > * atomicWriteIntArray# > * fetchSubIntArray# > * fetchOrIntArray# > * fetchXorIntArray# > * fetchAndIntArray# > > Makes these pre-existing out-of-line primops inline: > > * fetchAddIntArray# > * casIntArray# > > >> --------------------------------------------------------------- > > d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > compiler/cmm/CmmMachOp.hs | 19 ++ > compiler/cmm/CmmSink.hs | 4 + > compiler/cmm/PprC.hs | 4 + > compiler/codeGen/StgCmmPrim.hs | 94 +++++++ > compiler/llvmGen/Llvm/AbsSyn.hs | 7 + > compiler/llvmGen/Llvm/PpLlvm.hs | 18 +- > compiler/llvmGen/LlvmCodeGen/CodeGen.hs | 71 ++++-- > compiler/nativeGen/CPrim.hs | 50 +++- > compiler/nativeGen/PPC/CodeGen.hs | 4 + > compiler/nativeGen/SPARC/CodeGen.hs | 4 + > compiler/nativeGen/X86/CodeGen.hs | 92 +++++++ > compiler/nativeGen/X86/Instr.hs | 38 ++- > compiler/nativeGen/X86/Ppr.hs | 8 + > compiler/prelude/primops.txt.pp | 76 +++++- > includes/stg/MiscClosures.h | 1 - > libraries/ghc-prim/cbits/atomic.c | 280 +++++++++++++++++++++ > libraries/ghc-prim/ghc-prim.cabal | 1 + > rts/Linker.c | 1 - > rts/PrimOps.cmm | 12 - > testsuite/tests/concurrent/should_run/.gitignore | 1 + > .../tests/concurrent/should_run/AtomicPrimops.hs | 245 ++++++++++++++++++ > .../concurrent/should_run/AtomicPrimops.stdout | 7 + > testsuite/tests/concurrent/should_run/all.T | 1 + > 23 files changed, 984 insertions(+), 54 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > I think the above killed compilation on 32-bit boxes. See the usually-green boxes turn red at [1], specifically validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The error looks like: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 It'd be great if the devs would look at [1] every day or so. [1]: http://haskell.inf.elte.hu/builders/ -- Mateusz K.

2 2

RE: Associated type instances
by Simon Peyton Jones 24 Jun '14

24 Jun '14

I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakravarty@me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs(a)haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#… All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

2 2

CmmLint error when doing safe ccall from cmm
by Yuras Shumovich 24 Jun '14

24 Jun '14

Hello, I'm trying to do safe ccall from cmm (see below for the code). It seems to work, but -dcmm-lint is not satisfied: /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint -fforce-recomp Cmm lint error: in basic block c4 in assignment: _c1::I32 = R1; Reg ty: I32 Rhs ty: I64 Program was: {offset c5: _c0::I64 = R1; _c2::I64 = c_test; _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); I64[(young<c4> + 8)] = c4; foreign call "ccall" arg hints: [] result hints: [] (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8; c4: _c1::I32 = R1; R1 = %MO_SS_Conv_W32_W64(_c1::I32); call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } <no location info>: Compilation had errors The same code without "safe" annotation passes cmm lint. Is it my error or ghc bug? How can I do safe ccall in cmm correctly? Here is the code: == c.c == #include <assert.h> int c_test(int i) { assert(i == 1); return 2; } == cmm.cmm #include "Cmm.h" cmm_test(W_ i) { CInt i1; (i1) = ccall c_test(W_TO_INT(i)) "safe"; return (TO_W_(i1)); } == hs.hs == {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} import GHC.Prim import GHC.Types import Control.Exception foreign import prim "cmm_test" test :: Int# -> Int# main :: IO () main = do let i1 = test 1# assert (I# i1 == 2) (return ()) Thanks, Yuras

3 4

GHC 7.10 plans
by Austin Seipp 24 Jun '14

24 Jun '14

Hello all, Let me redirect you to the following page, which lists out some of the plans for 7.10: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 The listing here is mostly based on what we had all put down during the May status reports. If you have something planned, please mention it with a paragraph on the page if you don't mind. Given the last release schedule, we'd like an RC by Christmas, and a release close to Feburary 2015. This will give the 7.10 branch a full year of changes. Do let me know if anything is unclear! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Phabricator gifs
by Simon Peyton Jones 24 Jun '14

24 Jun '14

Is it possible to not get the hugely distracting and pixel-consuming gifs in Phabricator displays. Eg see the one below. Simon [cid:image001.png@01CF8EE0.70DAF510]

3 2

Associated type instances
by Simon Peyton Jones 24 Jun '14

24 Jun '14

Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#… All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration

3 2

clang warnings
by Kazu Yamamoto 24 Jun '14

24 Jun '14

Hi, To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 branch. Unfortunately, on my Mac, I saw many warnings which are not displayed with GHC 7.8.2: clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' clang: warning: argument unused during compilation: '-I test' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' clang: warning: argument unused during compilation: '-I dist/build/autogen' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' Is this a known issue? --Kazu

5 9

RE: New GHC feature proposal: Pattern families
by Simon Peyton Jones 23 Jun '14

23 Jun '14

Baldur (My name is Simon, not Peyton, incidentally. "Peyton Jones" is my last name.) I'm glad you are enjoying pattern synonyms. Thanks for identifying #9226, which I guess is you. I honestly don't understand your pattern family proposal. Would you like to write a wiki page somewhere describing the syntax typing (static semantics) desugaring (dynamic semantics) as clearly and precisely as you can, independent of prisms, and using the simplest possible examples to illustrate. By all means say that prisms are a more advanced application, and give examples to show how. But in general to specify a language feature you need a lot more than a couple of examples! Then you can ask GHC users what they think. I have to say that I'm cautious about adding further features to pattern synonyms until we've gotten more user experience with what we have. (Do you think the explicitly bidirectional stuff on the wiki page is important? To me that seems like the first thing a user might stumble over.) Incidentally, I'd really like to replace view patterns with https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative, another thing that is awaiting cycles. Copying ghc-devs for interest Thanks Simon | -----Original Message----- | From: Baldur Blöndal [mailto:baldurpet@gmail.com] | Sent: 18 June 2014 04:31 | To: Simon Peyton Jones; gergo(a)erdi.hu | Subject: New GHC feature proposal: Pattern families | | Hello Peyton and Gergo, | | I'm a master's student at Chalmers, a minor GHC contributor and have | written about the pattern synonyms extension | (https://www.fpcomplete.com/user/icelandj/Pattern%20synonyms) and | included is a proposal for an extension I call “pattern families” | allowing users to create patterns parameterized by an expression. I feel | like patterns don't get nearly as much attention as the type system and | this is my attempt to balance things out :) | | I discussed the proposal with Edward Kmett who suggested an example with | prisms and that I contact you two for comments. The syntax is still in | flux. | | Some motivating examples for your consideration. | | PRISM PATTERNS | | Edward suggested a pattern to match a prism which would look like this: | <edwardk> an example where you want it is if you want to use a pattern | synonym to match a prism <edwardk> foo (Match _Left a) = ... | [...] | <edwardk> the example of a single pattern that can match every prism | would be a nice example | | which would be quite easy to implement: | | | pattern Match prism a ← ((^? prism) → Just a) | | | | bar :: Either c (Either a b) → a | | bar (Match (_Right._Left) a) = a | | bar _ = error "Not a Right (Left ...)" | | This can be used for any prism: | | jsonBlob = "[{\"someObject\": {\"version\": [1,0,3]}}]" | | | | foo (Match (nth 0) (Match (key "someObject") (Match (key "version") | (Match (nth 1) a)))) = a | | ghci> foo jsonBlob | | Number 0.0 | | and defining more specilized patterns we can make it terser: | | pattern Get i a ← ((^? nth i) → Just a) pattern Key str a ← ((^? key | | str) → Just a) | | | | baz (Get 0 (Key "someObject" (Key "version" (Get 1 a)))) = a baz (0 | | `Get` "someObject" `Key` "version" `Key` 1 `Get` a) = a baz (a :→ | | "someObject" :⇒ "version" :⇒ 1 :→ a) = a | where | | pattern i :→ a ← Get i a | | pattern str :⇒ a ← Key str a | | So this is excellent for pattern matching on any sort of nested | structure: records, JSON, XML, HTML, ASTs, … Since this also supports | pattern matching on any value that satisfies a predicate. | | N+K PATTERNS | Generalizing n+k patterns: We create a pattern family indexed by its | first argument: | | | pattern (a :+) :: Num a ⇒ a → a | | k :+ n ← (unSucc k → Just n) -- [1] unSucc defined below | | where (a :+) indicates that 'k' is an index of the pattern family | allowing it to be supplied to the view pattern. | The pattern can be used as follows: | | fact 0 = 1 | | fact m@(1 :+ n) = m * fact n | | PATTERN MATCHING REGULAR EXPRESSIONS The pattern (:=~) is inspired | by the operator (=~) from Text.Regex.Posix.Wrap (regex-posix), note that | its second argument is the index here: | | pattern (:=~ String) :: RegexContext Regex a c ⇒ a → c | | n :=~ pattern ← ((=~ pattern) → n) | | Used as: | | vowels :: RegexContext Regex src tgt ⇒ src → tgt vowels (n :=~ | | "[aeiou]") = n | | | | ghci> vowels "honorificabilitudinitatibus" ∷ Int | | 13 | | where you can of course pattern match on the resulting value: | | | has5Vowels :: String → Int | | has5Vowels (5 :=~ "[aeiou]") = True | | has5Voewls _ = False | | TYPE INFERENCE | Here is an example of a snippet inferring the type of an if expression: | | | infer Γ (If cond t e) = | | case (infer Γ cond, infer Γ t, infer Γ e) of | | (Just TBool, Just τ₁, Just τ₂) | | | τ₁ == τ₂ = Just t₁ | | Here is how it might look with pattern families: | | | infer Γ (If (Infer Γ TBool) (Infer Γ τ₁) (Infer Γ τ₂)) | | | τ₁ == τ₂ = Just τ₁ | | (or even nicer if we use (:⇑) = Infer) | | infer Γ (If (Γ :⇑ TBool) (Γ :⇑ τ₁) (Γ :⇑ τ₂)) … | | IMPLEMENTATION | From what I can see this is a relatively straight-forward translation | into view patterns where a variable bound by a view pattern is an | “index” to the pattern family and unbound variables are regular | patterns. In the examples above I use special syntax for the index where | the type is included but even without any annotation it can be inferred | from context. | | If the proposal is fine by you I offer to do the implementation work, | all feedback welcome! | | Best regards, | Baldur Blöndal | | APPENDIX | | unSucc :: Int → Int → Maybe Int | | unSucc k n | | | n - k < 0 = Nothing | | | otherwise = Just (n - k) | |

2 1