- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 07 Jun '17

07 Jun '17

> On Mon Jun 5 03:15:32 UTC 2017, Richard Eisenberg wrote: > > On Jun 4, 2017, at 4:06 AM, Anthony Clayden wrote: > ... I find these examples are clearest when they > include code that you want to write, but can't; Haskellers are a bright bunch. If there's code they want to write but can't, they'll find a work-round; bless it as an 'idiom'; publish a couple of papers; and make a virtue out of necessity. Looking at the HList library as is today. It's almost unrecognisable compared to the 2004 paper. It is in fact using the same techniques, but they're entirely obscured in work-rounds. There's no longer overlapping instances except in one class/in its own module. viz the type-level type equality test, returning Boolean. > ... I was expecting an example of how today's > TypeError doesn't work for you. The classic place in HList where TypeError (used to be) unavoidable is the `Lacks` predicate. Validate that an HList does _not_ contain element type `e`: > class HLacks e l > instance HLacks e HNil > instance (TypeError e) => HLacks e (HCons e l') > instance (HLacks e l') => HLacks e (HCons e' l') The sole purpose of that type-equal/TypeError instance, is to 'shadow' the type-different instance. That's nowadays avoidable: > -- class and HNil instance same > instance (TypeEq e e' b, HLacksCase b e l') > => HLacks e (HCons e' l') -- catch-all HCons > class HLacksCase b e l' > instance (HLacks e l') => HLacksCase False e l' > instance (TypeError e) => HLacksCase True e l' -- this now optional So every class in the HList library now has a catch-all HCons instance, with a call to the type equality test, and a case-despatching auxiliary class. It is semantically robust. I suppose you get used to the idiom. But in terms of helping type-level programming look like term-level programming, it's obtuse. (All that InstanceGuards are aimed at is blessing this idiom with some syntax sugar, so it looks like term-level guards.) And HList is working one element at a time, as it recursively descends into the list. The TypeError technique doesn't scale. What I really want to do is use 'flat' tuples as type-indexed anonymous/extensible records, putting newtypes to label the payloads: > me = (PersonId 41, PersonName "AntC") Again we must prevent repeated types: > notme = (PersonId 41, PersonName "AntC", PersonId 72) > class TIPle t -- Type Indexed Product tuples > instance TIPle (e1, e2) -- I just want e1 /~ e2, so: > instance (TypeError e1) => (e1, e1) -- exclude repeats This approach doesn't scale. Take the threeple: > instance (TypeError e1) => TIPle (e1, e1, e3) > instance (TypeError e1) => TIPle (e1, e2, e1) > instance (TypeError e2) => TIPle (e1, e2, e2) > instance TIPle (e1, e2, e3) -- OK, elements distinct by elimination Arguably I should also have > instance (TypeError e1) => (e1, e1, e1) The fourple case needs 6, arguably 9 exclusionary instances. I could use the nowadays HList idiom: > instance (TypeEq e1 e2 b1, TypeEq e1 e3 b2, TypeEq e2 e3 b3, > TIPleCase (b1, b2, b3) (e1, e2, e3) ) > => TIPle (e1, e2, e3) > instance TIPleCase (False, False, False) (e1, e2, e3) > -- TypeError instance(s) optional Perhaps I could use a type family with (~) constraint > instance (Equal e1 e2 ~ False, Equal e1 e3 ~ False, Equal e2 e3 ~ False) > => TIPle (e1, e2, e3) Note I've only talked so far about validating a TIPle, we want a whole bunch of methods for extending/projecting/ merging and comparing TIPles, and the classic record subtype relationship. With classes over two TIPLes there's a combinatorial explosion. So what you do is convert tuples to HLists, do all the operations on the HList, convert the result back to tuple. > > OK, concrete example: > > I'm afraid I don't see the concrete example. > But it looks like the example you give is one > motivating instance guards... It was trying to show: with CTFs (and presumably closed classes) there's an explicit or implicit TypeError catch-all instance at the end of the chain of `else`s. (It seems InstanceChain `fails` doesn't suffer this.) So the example showed I _didn't_ want that behaviour. AntC

2 1

Re: [Haskell-cafe] STG Program to invoke rule 17?
by Kei Davis 06 Jun '17

06 Jun '17

On 06/06/2017 06:00 AM, haskell-cafe-request(a)haskell.org wrote: > [Haskell-cafe] STG Program to invoke rule 17? This isn't a proper answer to your question, but I found the "fast curry" paper to be more useful for understanding STG http://community.haskell.org/~simonmar/papers/evalapplyjfp06.pdf -- Kei Davis Applied Computer Science Group CCS-7, Mail Stop B287 Los Alamos National Laboratory Los Alamos, NM 87545, U.S.A.

1 0

Re: [Haskell-cafe] Bug in GHC or cabal-install?
by Ivan Lazar Miljenovic 06 Jun '17

06 Jun '17

On 6 June 2017 at 07:55, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: > > wxc/setup.hs uses versionBranch from Cabal[0]; the function versionBranch is > not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When > installing wxc the first time, the right version of Cabal is picked, when > "cabal install" is invoked a second time, GHC tries to compile wxc/setup.hs > again, but with the wrong version of Cabal (note: the release candidate of > GHC comes with Cabal 2) > > [0] > https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.h… If you look at the source for this module, you'll see that it isn't defined in there; it's actually from Data.Version in base. > > > > On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: > >> I don't think it's a problem with Cabal, but the version of base going >> by the error: versionBranch is from base, and that error message is >> talking about compiling the setup.hs from wxc. >> >> On 5 June 2017 at 12:03, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: >>> >>> >>> The strange thing is, that the right version of Cabal is picked, the >>> first >>> time wxc is compiled. But when invoking cabal-install the second time, >>> the >>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>> part). >>> This does not happen with GHC 8.0.2 >>> >>> (By the way, cabal-install tries to compile setup.hs again, even though >>> nothing has changed.) >>> >>> Regards, >>> Henk-Jan van Tuyl >>> >>> >>> >>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>> <ivan.miljenovic(a)gmail.com> wrote: >>> >>>> This is from a limitation/bug with Cabal-the-library, in that there >>>> are typically no dependency checks for custom Setup.[l]hs >>>> configurations. >>>> >>>> wxc has such a custom one: >>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>> >>>> versionBranch is from Data.Version in base, and it appears that the in >>>> this GHC pre-release there's been a change in base that removed this >>>> function. >>>> >>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: >>>>> >>>>> >>>>> >>>>> L.S., >>>>> >>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>> >>>>> I adapted wxHaskell to the new packages that come with the new GHC and >>>>> it >>>>> compiles now, but only the first time. If I compile it a second time, >>>>> even >>>>> if nothing has changed, the information from the custom-setup section >>>>> of >>>>> the wxc.cabal file seems to be forgotten. This section looks like this: >>>>> >>>>> custom-setup >>>>> setup-depends: >>>>> base, >>>>> Cabal < 2, >>>>> containers, >>>>> bytestring, >>>>> split, >>>>> process, >>>>> directory, >>>>> filepath >>>>> (I am using cabal-install 1.24.0.2) >>>>> >>>>> Output from the second time I try to install wxHaskell: >>>>> >>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>>>> >>>>> >>>>> >>>>> [1 of 1] Compiling Main ( >>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>> [1 of 1] Compiling Main ( >>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>> >>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>> Variable not in scope: versionBranch :: Version >>>>> -> >>>>> [a0] >>>>> | >>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>> versionBranch) ver >>>>> | >>>>> ^^^^^^^^^^^^^ >>>>> >>>>> This error message indicates that the wrong version of Cabal (2.0) is >>>>> used >>>>> to compile the wxcore setup.hs >>>>> It looks like a cabal-install bug, but this does not happen when I >>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>> >>>>> Regards, >>>>> Henk-Jan van Tuyl > > > -- > Folding@home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://foldingathome.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

2 3

Collecting examples where GHC generates unintuitive error messages
by Siddharth Bhat 06 Jun '17

06 Jun '17

Hello all, A discussion of GHC and error messages came up on ghc-devs. I'd like to give back to the community and try to improve this part of GHC. So, I created a repo to collect error messages ( https://github.com/bollu/hask-error-messages-catalog) That way, there's some concrete context for anyone who's working on the error messages subsystem of GHC. Elm does this as well (https://github.com/elm-lang/error-message-catalog) though they catalogue *all* errors. I'd be grateful for short examples where GHC generates unintuitive error messages, and perhaps a short explanation of what *would* be useful if possible. If you do have certain examples, please either open a pull request against the repository, or post a snippet on the mailing list. Thanks for the help, ~Siddharth -- Sending this from my phone, please excuse any typos!

2 2

[ANN] Schedule for Haskell Hackathon in Freiburg, Germany
by Alexander Thiemann 06 Jun '17

06 Jun '17

Dear Haskellers, the schedule for the Haskell Hackathon taking place in Freiburg, Germany this year is now online ( https://wiki.haskell.org/HacFreiburg2017 ) and we still have spots available. Register here: https://goo.gl/LDIQlw == Details: When: Friday 4 August 2017 - Sunday 6 August 2017 Where: Faculty of Engineering, University of Freiburg, Germany (https://goo.gl/maps/ZcHWLpMPhtj)Info page: https://wiki.haskell.org/HacFreiburg2017 Organizers: Peter Thiemann, Alexander Thiemann, Stefan Wehr == HacFreiburg is another Haskell Hackathon, where Haskell programmers from all around the world meet in Freiburg, Germany, to discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! The Haskell Hackathon in Freiburg is part of the "Sommercampus 2017" (https://sommercampus.fachschaft.tf/en/) organized by the Faculty of Engineering at the University of Freiburg. Hope to see you there, Alex (with Peter and Stefan)

1 0

[ANN] mercury-api-0.1.0.0 (for RFID readers)
by Patrick Pelletier 06 Jun '17

06 Jun '17

https://hackage.haskell.org/package/mercury-api https://github.com/ppelleti/hs-mercury-api This package is a Haskell binding to the "Mercury API" C API for ThingMagic RFID readers. It is especially geared toward the SparkFun Simultaneous RFID Reader board, which uses ThingMagic's M6e Nano module, but it should work with other ThingMagic readers. (Though currently, only support for serial readers is compiled in.) Most of the function and type names are the same as their counterparts in the C API, with the TMR_ prefix dropped. For more in-depth, language-independent documentation of Mercury API, see Mercury API Programmers Guide, available from the "Manuals & Firmware" page, below. This package includes a copy of the Mercury API C library, so no external libraries are necessary. Several small bug fixes have been applied to the included version of the library. (I have submitted these patches upstream, but I don't know if or when they will be included in the official version.) The Haskell binding doesn't support background reads. I recommend that you just spawn a new Haskell thread and do foreground reads instead. Currently, only support for the serial reader is compiled in, but it probably wouldn't be too hard to enable LLRP support. (I don't have any way to test LLRP, however, as the M6e Nano doesn't support it.) On Mac OS X, be sure to use the serial device that starts with "/dev/cu.", not the serial device that starts with "/dev/tty.". Only some parameters and some tagops are currently supported in the Haskell binding. (There are a lot of them, and I only implemented the ones I needed.) If you need support for additional parameters or tagops, please file an issue in GitHub and I will add them. I have tested this package on Linux, Mac OS X, and Windows, using the SparkFun board. Additional resources: SparkFun Simultaneous RFID Reader: https://www.sparkfun.com/products/14066 ThingMagic Manuals & Firmware: http://www.thingmagic.com/index.php/manuals-firmware

1 0

STG Program to invoke rule 17?
by Siddharth Bhat 05 Jun '17

05 Jun '17

I'm reading the original STG paper <https://www.dcc.fc.up.pt/~pbv/aulas/linguagens/peytonjones92implementing.pdf> and implementing it along the way. (Raw link to paper: https://www.dcc.fc.up.pt/~pbv/aulas/linguagens/peytonjones92implementing.pdf ) I'm not able to figure out how to invoke rule 17 at all. This rule is to update a function call which calls another function. I've tried creating examples, but all of them wind up invoking the constructor update rule. ╰─$ cat stg-programs/updatable-fn-calls.stg define nu = {} \n {x, y, w, z} -> x {}; define main = {} \n {} -> let x = {} \n {} -> One {}; y = {} \n {} -> Two {}; // closure to update update = {x, y} \u {} -> nu {x, y, y, y}; // have something in argument stack kickstart = {update} \n {a, b} -> update {}; // make sure this is never evaluated bottom = {} \n {} -> bottom {} in case (kickstart {bottom, bottom}) of One {} -> Done {}; This was a program I tried, hoping that the "kickstart" function would ensure that there is something on the argument stack, so that when "nu" is entered, the rule would trigger. However, in my toy STG implementation here (simplexhc link) <https://github.com/bollu/simplexhc> (Raw: https://github.com/bollu/simplexhc) the rule is not triggered. You can run it with: $ stack build && stack exec simplexhc -- stg-programs/updatable-fn-calls.stg I believe I have either misunderstood the rule or mis-implemented it. So if someone could point me to a reference of how to trigger the rule, I'd be very thankful. I'd like to have some intuition on the rule and "why it works". Cheers, ~ Siddharth -- Sending this from my phone, please excuse any typos!

1 0

Re: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 05 Jun '17

05 Jun '17

> > On Sun Jun 4 13:11:47 UTC 2017, J. Garrett Morris wrote: > > ... > > You keep talking about guarding instances or equations. > > Guards are equivalent to closed type families, > > I think not. They're somewhere between CTFs and Instance > Chains. > In that guarded instances are not closed. > Which also appears to be your claim wrt Instance Chains. > A further difference is wrt class instances and FunDeps. AFAICT, the closed class instances/Partiality paper is expecting no FunDeps, but using Assoc types within the class to achieve the same effect. I agree with that long-term aim, so the following applies to both guarded class instances and guarded type instances. The dreaded "Instances inconsistent with FunDeps" error can be boiled down to: > class TypeEq a b p | a b -> p > instance TypeEq a a HTrue > instance TypeEq a b HFalse The check for FunDep consistency unifies the class parameters on LHS of FunDep, yielding subsititution { a ~ b }. Then applies that substitution to rhs. yielding { HTrue ~ HFalse } doesn't hold, so inconsistency. GHC allows you to put this instead: > instance TypeEq a a HTrue -- same > instance (p ~ HFalse) => TypeEq a b p The consistency test compares { p ~ HTrue }, and apparently sees those as unifiable, despite the (~ HFalse) constraint. There are those [for example, Iavor], who think this should still count as inconsistent. So it works (and has consistently since 2004), but seems iffy. Furthermore the bare typevar `p` breaks the Coverage Conditions, (again despite the (~ HFalse) constraint grr! So you need UndecidableInstances, which apparently is not as benign as heretofore thought. With InstanceGuards it goes like this: class {-# INSTANCEGUARDS #-} TypeEq a b p | a b -> p instance TypeEq a a HTrue -- same instance TypeEq a b HFalse | a /~ b Now the consistency check: unifies the class parameters on lhs of FunDep, yielding { a ~ b } as before; then substitutes into the guard, yielding { a /~ a } -- a contradiction. So it doesn't need to check the consistency of the result. Because the 'arguments' to the FunDep are apart. Notice the side-benefit: by putting explicit HFalse, we haven't broken the Coverage Conditions, so don't need UndecidableInstances. The guarded type family goes likewise: > type family {-# INSTANCEGUARDS #-} Equals a b :: Bool > type instance Equals a a = True > type instance Equals a b | a /~ b = False AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 05 Jun '17

05 Jun '17

> On Fri Jun 2 13:20:13 UTC 2017, Richard Eisenberg wrote: > > On Jun 2, 2017, at 3:22 AM, Anthony Clayden wrote: > >> I hereby pronounce > >>> instance TypeError ... => C Int Bool > >> > >> as "not an instance". ... > > > > Hmm. I'd be interested how you're going to stop > > the compiler matching some usage site to it. > > That's what TypeError does. When the compiler matches a > use site, it issues an error. I would imagine that's the > behavior you want. No. I want to leave the class open, so I can add other instances (possibly in a different module). If I protect instances in this module with guards, the compiler can satisfy itself that the other modules' instances do not overlap. > Can you write a concrete example of something you'd like > to do that the current machinery doesn't? > OK let's recap the Expression Problem first. There are two legs: * We want to freely add methods over a set of datatypes. (Problematic in OOP, because the methods are embedded in the objects.) In Haskell we can declare a new class with new method(s), and give instances over those datatypes. * We want to freely add constructors, and expand existing classes/methods to cover. That's not so easy in Haskell. The usual work-round is to make each constructor a new datatype. Then we can use the instance mechanism to extend classes/methods. ("Usual" for example with DSL's to expand the AST.) If you have closed type families/classes (esp in an imported/library module), you're blocked from extending it for new datatypes. Now apparently Instance Chains don't suffer this, the `fails` triggers a search for other instances in other chains. Garrett in an earlier message quoted section 3.1.1 of the paper "a class can be populated by multiple, non-overlapping instance chains, where each chain may contain multiple clauses". Unfortunately I can find no examples of using this feature, so I'm a bit unsure how it goes. We'd know the chains are non-overlapping because they'd chain over distinct datatypes, I imagine. And I thought that's what we were getting with CTFs, but the implementation fell short of my expectations. I wanted (when I suggested the `where`-style syntax): > module A > type family F a b -- full stop! > type instance F (T1 a) b where > ... -- overlapping equations within T1 > > module B > type instance F (T2 c) d where > ... -- overlapping equations within T2 Those closed instances in distinct modules are provably non-overlapping, because of the different type constructor. (By the same rules as currently, for apartness of instance heads. All equations within the where-group must unify with the instance head.) So then this (current) syntax would be a shorthand: > type family G e f where > ... -- total equations for G for the author of `G` who deliberately wanted to prevent anybody expanding the family. i.e shorthand for > type family G e f > type instance G e f where > ... Fair enough, that's a common requirement. But all we got in the implementation was that blitz-all style. (I'm grumpy.) And according to Garrett's survey, 15% of Hackage would be grumpy too. OK, concrete example: within the HList framework > data HNil = HNil > data HList e l = HList e l > -- deliberately not using DataKinds the Hlist paper discusses various approaches for indexing the payloads `e` within the list. Suppose (eliding a lot of detail) I choose Type-Indexed Products like > newtype PersonId = PersonId Int > newtype PersonName = PersonName String > ... > me = HCons (PersonId 41) $ HCons (PersonName "AntC") HNil And type indexed `Has` predicate needing overlaps: > class Has e l ... > -- no instance for HNil > instance Has e (HCons e l) ... > instance (Has e l') => Has e (HCons e' l') ... That's standard HList TIP, let's assume it's in a library/module. Another style of carrying the payload is type labels. To mix these styles, I need a way to cons a labelled element: > data AstroSign = AstroSign > ... > data HConsLab lab e l = HConsLab lab e l > > me2 = HConsLab AstroSign 12 me This deliberately allows the payload to be an ad-hoc type. Now I need a Has instance: > instance Has lab (HConsLab lab e l) ... > instance (Has lab l') => Has lab (HConsLab lab' e' l') ... Again relies on overlap. No danger of clashing with the vanilla HCons style, because labels are a distinct set of types. IOW this is fine: > you = HCons (PersonId 73) $ HCons (PersonName "rae") > $ HConsLab AstroSIgn 7 HNil > -- instances for the type of `you` > -- (Has you PersonId, Has you PersonName, Has you AstroSign) I can do all this now with stand-alone instances. But I have to be careful to keep my overlaps well-behaved. With closed Type Families/the proposed Classes, I can't add those HConsLab instances. I want to continue current support for freely adding instances, but provide a mechanism to enforce no-overlaps. And I think guards achieve that with relatively lightweight syntax, avoiding hard-to-follow sequences of `else` ... AntC

2 1

Re: [Haskell-cafe] Bug in GHC or cabal-install?
by Ivan Lazar Miljenovic 05 Jun '17

05 Jun '17

I don't think it's a problem with Cabal, but the version of base going by the error: versionBranch is from base, and that error message is talking about compiling the setup.hs from wxc. On 5 June 2017 at 12:03, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: > > The strange thing is, that the right version of Cabal is picked, the first > time wxc is compiled. But when invoking cabal-install the second time, the > setup-depends section seems to be ignored (or at least the Cabal < 2 part). > This does not happen with GHC 8.0.2 > > (By the way, cabal-install tries to compile setup.hs again, even though > nothing has changed.) > > Regards, > Henk-Jan van Tuyl > > > > On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: > >> This is from a limitation/bug with Cabal-the-library, in that there >> are typically no dependency checks for custom Setup.[l]hs >> configurations. >> >> wxc has such a custom one: >> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >> >> versionBranch is from Data.Version in base, and it appears that the in >> this GHC pre-release there's been a change in base that removed this >> function. >> >> On 4 June 2017 at 19:45, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: >>> >>> >>> L.S., >>> >>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>> >>> I adapted wxHaskell to the new packages that come with the new GHC and it >>> compiles now, but only the first time. If I compile it a second time, >>> even >>> if nothing has changed, the information from the custom-setup section of >>> the wxc.cabal file seems to be forgotten. This section looks like this: >>> >>> custom-setup >>> setup-depends: >>> base, >>> Cabal < 2, >>> containers, >>> bytestring, >>> split, >>> process, >>> directory, >>> filepath >>> (I am using cabal-install 1.24.0.2) >>> >>> Output from the second time I try to install wxHaskell: >>> >>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>> >>> >>> [1 of 1] Compiling Main ( >>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>> [1 of 1] Compiling Main ( >>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>> >>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>> Variable not in scope: versionBranch :: Version -> >>> [a0] >>> | >>> 505 | full_ver = (concat . intersperse "." . map show . >>> versionBranch) ver >>> | >>> ^^^^^^^^^^^^^ >>> >>> This error message indicates that the wrong version of Cabal (2.0) is >>> used >>> to compile the wxcore setup.hs >>> It looks like a cabal-install bug, but this does not happen when I >>> use GHC 8.0.2; should I write a GHC bug ticket? >>> >>> Regards, >>> Henk-Jan van Tuyl > > > > -- > Folding@home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://foldingathome.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0