June 2017 - Haskell-Cafe

Call for participation: Trends in Functional Programming in Education 2015 (in association with TFP 2017)
by Simon Thompson 07 Jun '17

07 Jun '17

Trends in Functional Programming in Education, 2017 Call for participation https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ Programme timings https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/TFPIE_2017/Programme.h… The sixth workshop on Trends in Functional Programming in Education, 2017, which is to be held on the Canterbury campus of the University of Kent on Thursday, 22 June. Registration is included with that for TFP 2017, 19–21 June. Morning: functional programming and online learning A particular topic of this year's TFPIE will be MOOCs and other online learning and we've managed to gather people from most of the current MOOCs in functional programming to come to an informal symposium. Keynote: Heather Miller of EFPL and Northeastern University will begin the symposium by giving a keynote on this topic. Heather works on and around the Scala programming language and is Executive Director of the Scala Center. This will be followed by a presentation from Yann Régis-Gianas and Benjamin Canou about the MOOC on OCaml, and a round table discussion including Heather, the OCaml MOOC team, Jeremy Singer (Haskell), and Simon Thompson (Erlang). The morning will conclude with two regular presentations: - Stephen Adams. Teaching Erlang through the Internet: An Experience Report - Jeremy Singer and Blair Archibald. Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers Afternoon: TFPIE regular programme The afternoon will begin with a best lecture: Colin Runciman (York) on the topic of Purely Functional Queues The meeting will then have four regular presentations: - Marco T. Morazan. Vector Programming Using Structural Recursion - Curtis d'Alves, Tanya Bouman, Christopher Schankula, Jenell Hogg, Levin Noronha, Emily Horsman, Rumsha Siddiqui and Christopher K. Anand. Using Elm to Introduce Algebraic Thinking to K-8 Students - Hans-Wolfgang Loidl, Phil Barker and Sanusi Usman. Enhancing the Learning Experience on Programming-focused Courses via Electronic Assessment Tools (Extended Abstract) - Juan Carlos Saenz-Carrasco and Mike Stannett. Overcoming Non Distributivity: A Case Study in Functional Programming The meeting will conclude with a lightning talks session for attendees and others to give short talks about work in progress or projects that they would like to get started, followed by a plenary discussion on future directions for the community and the workshop. Programme committee Dr Laura Castro, University of A Coruña Prof Ralf Lämmel, University of Koblenz-Landau Dr Elena Machkasova, University of Minnesota, Morris Prof Michel Mauny, Inria, Paris Dr Jeremy Singer, University of Glasgow Prof Simon Thompson, University of Kent (chair) Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

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 23:27, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: > > versionBranch is still in base, but it is not compatible with Cabal 2. You mean it isn't re-exported by Cabal-2? Then maybe wxc's Setup.hs needs to explicitly import Data.Version from base rather than relying upon the re-export. > > Regards, > Henk-Jan van Tuyl > > > > > On Tue, 06 Jun 2017 14:32:45 +0200, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: > >> On 6 June 2017 at 21:13, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: >>> >>> >>> You are right, versionBranch is from originally from base, but you are >>> missing the point: >>> package wxc compiles perfectly the first time, but, without anything >>> being >>> changed, does not compile the second time. By the way, I am using a cabal >>> sandbox and as I said earlier, I am using a GHC release candidate. >> >> >> And in that release candidate, does the version of base have >> versionBranch in it? >> >> My guess is that a new version of Cabal is being used the second time, >> which is compiled against the base that comes with that RC which is >> missing versionBranch. >> >> (But since I don't have any GHC RC's I can't check it myself.) >> > > > >>> >>> Regards, >>> Henk-Jan van Tuyl >>> >>> >>> >>> On Tue, 06 Jun 2017 00:33:40 +0200, Ivan Lazar Miljenovic >>> <ivan.miljenovic(a)gmail.com> wrote: >>> >>>> 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

1 0

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

06 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 05 Jun '17

05 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