June 2014 - ghc-devs - Haskell.org

Help needed: parsing pattern synonym contexts
by Dr. ERDI Gergo 02 Jul '14

02 Jul '14

Hi, I'm working on adding type signatures to pattern synonyms. The syntax I'm after would look something like, e.g.: pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] My problem is with parsing the two contexts. I wrote the parser in the following way, which I felt natural (actions omitted for brevity) pattern_synonym_sig :: { LSig RdrName } : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context type patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType RdrName)) } : constr_stuff patsyn_context :: { LHsContext RdrName } : {- empty -} | forall context '=>' However, this doesn't work, no matter if those contexts are present or not. If I remove both contexts from the rules, i.e. if I replace pattern_synonym_sig with : 'pattern' patsyn_stuff '::' type then parsing succeeds when there are no contexts on either side. I've also tried : 'pattern' patsyn_stuff '::' ctype with the intention of recovering the required context from the ctype (and I could do similar tricks to get the provided context from the patsyn_stuff by using a modified version of constr_stuff); however, even that doesn't work as I expected it, i.e. with this latter version, this: pattern Single a :: (Eq a) => [a] fails with a parse error on "::". Can someone help me out here please? Thanks, Gergo

4 8

Fixing Trac #9046 (Panic in GHCi when using :print).
by Vitaly Bragilevsky 02 Jul '14

02 Jul '14

Hello, I am trying to fix the bug #9046 (Panic in GHCi when using :print). I've discovered that It was introduced by this SPJ's commit (25 Nov 2013): https://ghc.haskell.org/trac/ghc/changeset/a8ac471d435214dbdc1fa70f938c6312… and especially by this change: -type QuantifiedType = ([TyVar], Type) -- Make the free type variables explicit +type QuantifiedType = ([TyVar], Type) + -- Make the free type variables explicit + -- The returned Type should have no top-level foralls (I believe) quantifyType :: Type -> QuantifiedType --- Generalize the type: find all free tyvars and wrap in the appropiate ForAll. -quantifyType ty = (varSetElems (tyVarsOfType ty), ty) +-- Generalize the type: find all free and forall'd tyvars +-- and return them, together with the type inside, which +-- should not be a forall type. +-- +-- Thus (quantifyType (forall a. a->[b])) +-- returns ([a,b], a -> [b]) + +quantifyType ty = (varSetElems (tyVarsOfType rho), rho) + where + (_tvs, rho) = tcSplitForAllTys ty While this change looks reasonable to me it breaks exploiting thunks created by `:print` ghci's command from polymorphic values. Before this change we could have: $ ghci -fprint-explicit-foralls GHCi, version 7.6.3.20130421: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::forall a. [a] -> Int) > _t1 [1,2,3] 3 And now we have: $ ghci -fprint-explicit-foralls GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::[a] -> Int) > _t1 [1,2,3] ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails a{tv arw} [tv] This particular panic is caused by unification (compiler/typecheck/TcUnify.lhs line 1042). In case of `read` instead of `length` we get panic even earlier in simplification (compiler/typecheck/TcSimplify line 85). The concrete reason for the panic is wrong constructor used for tyvar (TyVar instead of TcTyVar). I see several ways to fix this: 1) rollback to forall-types in `:print` (requires change in cvObtainTerm, RtClosureInspect.hs); 2) skolemise free tyvar to RuntimeUnk (it becomes TcTyVar then): a) in cvObtainTerm; b) somewhere before typechecking. I can't decide the correct way to fix this bug or maybe there are other alternatives. Anyway I am ready to work on this though I need some advice. With best regards, Vitaly Bragilevsky

2 1

the case of the missing Cabal doc
by Mark Lentczner 01 Jul '14

01 Jul '14

In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? - Mark

2 2

HEADS-UP: Git submodule conversion imminent
by Herbert Valerio Riedel 01 Jul '14

01 Jul '14

Hello GHC Devs! In order to not drag this out any longer, I'll completing the submodule conversion in the next few hours by converting the remaining sub-repo packages into proper submodules. This is represents phase 1 of the reorganization (phase 2 comprises officially transitioning the push-urls of *some* the packages to github.com/haskell as happened with haddock). However, this phase 1 is important to get done early (ideally half a year ago) in order to make 'ghc-complete' bit more redundant (I hope Joachim doesn't mind... :-) ) and allow to properly 'git bisect' as far back as possible into the past. While the workflow changes[1] to additionally have the sub-repo change also registed in ghc.git, practically, this should affect only a minority of you, as the remaining packages (see list at the bottom of this mail) to be converted into submodules are modified *very* seldom. This will be similiar to the conversion of haddock.git into a proper submodule of which you read up in * <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4049> * <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4072> * <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4077> List of packages converted into proper submodules: * libffi-tarballs libffi-tarballs.git * utils/hsc2hs hsc2hs.git * libraries/array packages/array.git * libraries/deepseq packages/deepseq.git * libraries/directory packages/directory.git * libraries/filepath packages/filepath.git * libraries/haskell98 packages/haskell98.git * libraries/haskell2010 packages/haskell2010.git * libraries/hoopl packages/hoopl.git * libraries/hpc packages/hpc.git * libraries/old-locale packages/old-locale.git * libraries/old-time packages/old-time.git * libraries/process packages/process.git * libraries/unix packages/unix.git * nofib nofib.git * libraries/parallel packages/parallel.git * libraries/stm packages/stm.git * libraries/dph packages/dph.git Ideally, you won't have any outstanding changes in those repos (hint, hint!) to make the transition for your GHC clones easier. I'll follow up with more specific instructions as soon as I've pushed the changes. N.B.: ghc-tarballs will *not* become a submodule, as it would impose a non-neglible cost on everyone, not only the developers on windows and, moreover, the plan is to turn ghc-tarballs into a scripted download (or maybe something git-annex based) as Git is not really suited for such large blobs. See also discussion at <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4895> [1]: For the new workflow in case you really happen to have to touch one of the affected modules, see the work-in-progress Wiki entry at https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Mak…

8 20

Re: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea)
by Herbert Valerio Riedel 01 Jul '14

01 Jul '14

Hi, Fyi, this changeset seems to have broken ./validate: utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning: Fields of ‘ClsInstDecl’ not initialised: cid_overlap_mode In the first argument of ‘return’, namely ‘(ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})’ In a stmt of a 'do' block: return (ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) In the expression: do { ltype' <- renameLType ltype; lATs' <- mapM (mapM renameTyFamInstD) lATs; lADTs' <- mapM (mapM renameDataFamInstD) lADTs; return (ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) } <no location info>: Failing due to -Werror. make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o] Error 1 make: *** [all] Error 2 On 2014-06-30 at 02:37:52 +0200, git-4Dsf34iY/NkouOHNgZ69ag(a)public.gmane.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/6290eeadf61a40f2eb08d0fd7ef1f3b7f… > >>--------------------------------------------------------------- > > commit 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > Author: Iavor S. Diatchki <iavor.diatchki(a)gmail.com> > Date: Sun Jun 29 17:22:16 2014 -0700 > > Overlapable pragmas for individual instances (#9242) > > Programmers may provide a pragma immediately after the `instance` keyword > to control the overlap/incoherence behavior for individual instances. > For example: > > instance {-# OVERLAP #-} C a where ... > > I chose this notation, rather than the other two outlined in the ticket > for these reasons: > > 1. Having the pragma after the type looks odd, I think. > 2. Having the pragma after there `where` does not work for > stand-alone derived instances > > I have implemented 3 pragams: > > 1. NO_OVERLAP > 2. OVERLAP > 3. INCOHERENT > > These correspond directly to the internal modes currently supported by > GHC. If a pragma is specified, it will be used no matter what flags are > turned on. For example, putting `NO_OVERLAP` on an instance will mark > it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on for the > module. > > >>--------------------------------------------------------------- > > 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > compiler/hsSyn/Convert.lhs | 2 +- > compiler/hsSyn/HsDecls.lhs | 24 ++++++++++++++++---- > compiler/parser/Lexer.x | 6 +++++ > compiler/parser/Parser.y.pp | 21 +++++++++++++----- > compiler/rename/RnSource.lhs | 7 ++++-- > compiler/typecheck/TcDeriv.lhs | 46 +++++++++++++++++++++++++-------------- > compiler/typecheck/TcInstDcls.lhs | 5 ++++- > 7 files changed, 82 insertions(+), 29 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 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 -- "Elegance is not optional" -- Richard O'Keefe

3 3

Two days old build breakage on i386.
by Karel Gardas 30 Jun '14

30 Jun '14

Hello, builders running on i386 building for this platform caught issue which shows as a build breakage: 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 Have a look for example on linux-i386 buildot log here: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so it's OS independent and probably 32bit/i386 platform specific and it's two days old breakage now. The last two night builds fail on all mentioned buildbots. I'm not sure but perhaps: commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell <johan.tibell(a)gmail.com> Date: Mon Jun 9 11:43:21 2014 +0200 triggers that issue? I'm not claiming that the commit is actual culprit, this may be just recently un-hidden issue in linear regs allocator on i386! Thanks! Karel

7 21

Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index
by Gabor Greif 30 Jun '14

30 Jun '14

I succeeded to solve all of them :-) But now I am blocked on on a panic "not in scope during type checking, but it passed the renamer". I suspect that while "deriving Generic" some instances are defined in some empty TcEnv, which does not contain my definition in context. Is there a way to inject some type constructor into the TcEnv? Thanks, Gabor On 6/27/14, Gabor Greif <ggreif(a)gmail.com> wrote: > Hello devs, > > I have > > {{{ > data D (n :: Symbol) > }}} > > in my module, and I want to obtain a type > > {{{ > D "YAY!" > }}} > > programmatically. Where can I find code that performs this (or > something similar)? > > 1) I have to look up |D| in the current TyEnv (what if it is in a > specific module?), > 2) I have to build the type index (of kind Symbol), this involves > FastString, looks non-trivial, > 3) Apply 1) on 2), this is easy. > > Any hints welcome! > > Thanks and cheers, > > Gabor > > > PS: some morsels I have so far: > > for 1) > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit > "GHC.Generics") >

2 3

Cleanup of RnExpr, RnEnv and RnSource
by Jan Stolarek 30 Jun '14

30 Jun '14

Dear all, RnExpr, RnEnv and RnSource (in compiler/renamer) declare locally: \begin{code} -- XXX thenM :: Monad a => a b -> (b -> a c) -> a c thenM = (>>=) thenM_ :: Monad a => a b -> a c -> a c thenM_ = (>>) \end{code} and then use these aliases instead of >>= and >>. These were introduced by Ian in 6c7b41cc2b24f533697a62bf1843507ae043fc97 in 2008 and later partially cleaned up by Simon in f0c99958649b8909612b1b9c9b48aad970dfce05 in 2009. Would there be objections if I cleand this up (ie. remove thenM and thenM_ and use >>= and >>)? Is anyone doing any substantial changes on any of these files and suspects that this could introduce merge conflicts for him? I'm at the moment changing some things in RnExpr, so doing this will only add little extra work for me and I'd like to take this oportunity to have cleaner code. Janek

2 1

cc & ld extra flags
by Mark Lentczner 29 Jun '14

29 Jun '14

I'd like to build GHC, and all the base libs, with an extra flag supplied to cc (well gcc) and ld commands: I thought I could just add this to mk/build.mk: SRC_CC_OPTS = -mmacos-version-min=10.7 SRC_LD_OPTS = -mmacos-version-min=10.7 But this seems very inconsistently applied. For example: This part of the build of the RTS gets it: "inplace/bin/ghc-stage1" -optc-m64 -optc-fno-stack-protector *-optc-mmacosx-version-min=10.7* -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DBE_CONSERVATIVE -optc-DDTRACE -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Hash.c -o rts/dist/build/Hash.o But this part doesn't: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.1 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.2.20140623 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Utf8.hs -o utils/haddock/dist/build/Haddock/Utf8.dyn_o I think it might have to do with the dyn_o and thr_o targets? So - Is there a better way to ensure these flags are applied? I suppose I could wrap gcc (clang) and ld.... but that seems ham-handed. - Mark

2 2

Re: New GHC feature proposal: Pattern families
by Baldur Blöndal 29 Jun '14

29 Jun '14

Yes I reported #9226 :) I created a wiki page for pattern families (https://ghc.haskell.org/trac/ghc/wiki/PatternFamilies) with a whole host of examples, trying to keep them simple so do let me know it anything is unclear. In the area of pattern synonyms I agree with testing the waters a bit, personally I'd like to change the syntax since it doesn't really scale for using complicated view patterns (forcing you to define auxiliary functions) and looks a bit awkward when adding type annotations and explicitely bidirectional patterns. I'd say explicitely bidirectional patterns are the next step forward but it depends on the priorities: · End users: Explicitely bidirectional patterns (#8581) and associated pattern synonyms (#8583) are the biggest two, although the latter can be ‘faked’ with type classes: If #8581/#8583 are implemented and if (:)/[] weren't built-in syntax libraries like Data.Text could be used as a drop-in replacement for String, currently users must change every pattern match to a case statement (but I digress) · Library authors: Exhaustiveness checks (#8779) are important for getting abstract data types on par with normal data types. Since you mentioned VPA (ViewPatternsAlternative) I took the liberty of using several examples from the VPA wiki page and contrasting them with the example found there, most of the ones I did not mention (like “join lists”) can be implemented using PatternSynonyms, I feel some of the VPA examples are better motivating examples than what I presented before. Best regards, Baldur 2014-06-29 9:40 GMT+02:00, Baldur Blöndal <baldurpet(a)gmail.com>: > Yes I reported #9226 :) > > I created a wiki page for pattern families > (https://ghc.haskell.org/trac/ghc/wiki/PatternFamilies) with a whole > host of examples, trying to keep them simple so do let me know it > anything is unclear. > > In the area of pattern synonyms I agree with testing the waters a bit, > personally I'd like to change the syntax since it doesn't really scale > for using complicated view patterns (forcing you to define auxiliary > functions) and looks a bit awkward when adding type annotations and > explicitely bidirectional patterns. > > I'd say explicitely bidirectional patterns are the next step forward > but it depends on the priorities: > · End users: Explicitely bidirectional patterns (#8581) and associated > pattern synonyms (#8583) are the biggest two, although the latter can > be ‘faked’ with type classes: If #8581/#8583 are implemented and if > (:)/[] weren't built-in syntax libraries like Data.Text could be used > as a drop-in replacement for String, currently users must change every > pattern match to a case statement (but I digress) > · Library authors: Exhaustiveness checks (#8779) are important for > getting abstract data types on par with normal data types. > > Since you mentioned VPA (ViewPatternsAlternative) I took the liberty > of using several examples from the VPA wiki page and contrasting them > with the example found there, most of the ones I did not mention (like > “join lists”) can be implemented using PatternSynonyms, I feel some of > the VPA examples are better motivating examples than what I presented > before. > > Best regards, > Baldur > > 2014-06-23 17:30 GMT+02:00, Edward Kmett <ekmett(a)gmail.com>: >> The main thing Baldur had asked me about was if it makes sense to talk >> about patterns that are parameterized by expressions in places. >> >> I agree that the thought is very poorly fleshed out, but as a motivation, >> in some sense the previous form of view patterns already do this. >> >> Consider (->), which takes in an expression to apply on the left and a >> pattern for what to match against the result of it on the right. >> >> The question then becomes can we allow this for arbitrary patterns? >> >> There are a number of use cases for these. For example, >> >> A pattern to match a regular expression might look like >> >> Foo (x :~= "ab*") >> >> where you want "ab*" to be passed as a parameter to the code for the >> pattern synonym (:~=), not be something it is binding. >> >> This then speaks to needing some notion of mode for the different >> parameters. >> >> One of the reasons I'm under-excited about pattern synonyms is we already >> built all the machinery for working with prisms in lens to generalize >> them. >> =) >> >> In lens we have a combinator 'preview :: Prism' s a -> s -> Maybe a'. >> >> As a straw man proposal: >> >> It'd be nice to be able to do something like >> >> pattern (Match p a) <- (preview p -> Just a) >> >> and have it take the arguments that go to the left hand side of the -> as >> expressions, not patterns so that that can compile. >> >> Now, I'm somewhat dubious that it worth the pain to embellish the pattern >> language with something this complicated, but in some sense we already >> have >> a lot of the machinery to support it. e.g. IIRC we parse patterns first >> as >> expressions then convert them. >> >> -Edward >> >> >> On Mon, Jun 23, 2014 at 4:39 AM, Simon Peyton Jones >> <simonpj(a)microsoft.com> >> wrote: >> >>> 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) >>> | | >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >

1 0