May 2017 - Haskell-Cafe

OverloadedRecordFields in GHC 8.2.1-rc2
by aditya siram 21 May '17

21 May '17

Hi, I'm trying out the GHC 8.2.1 release candidate [1], added 'OverloadedRecordFields' and I get an error saying it's an 'Unsupported Extension'. Am I doing something wrong? Thanks! -deech [1] https://mail.haskell.org/pipermail/ghc-devs/2017-May/014197.html

2 4

Re: [Haskell-cafe] Type Instance Partiality [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 21 May '17

21 May '17

> On Wed May 17 11:58:24 UTC 2017, Anthony Clayden wrote: >> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: >> ... >> See my recent draft paper ... > Yes I can see the sense in grounding type family > instances with class instances as Associated Types. Errk I see a fly in the ointment with these 'closed classes'/associated types. Suppose: A class with two assoc types * One assoc type needs the instances in a specific sequence. * The other assoc type needs the instances in a different sequence. Here's a simple (as in daft!) example: > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, FlexibleInstances #-} > > class (Flip a ~ b, Flop b ~ a) => FlipMaybe a b where > type Flip a > type Flop b > instance (a' ~ b) => FlipMaybe (Maybe a') b where > type Flip (Maybe a') = a' > type Flop b = Maybe b > instance (a ~ b') => FlipMaybe a (Maybe b') where > type Flip a = Maybe a > type Flop (Maybe b') = b' (If we wrote a closed class in that sequence, it would get `Flip` right but `Flop` wrong.) Those instances overlap at `FlipMaybe (Maybe a') (Maybe b')`, but we can't write a coherent instance for that overlap. (Using Instance Chains, we'd want a `Fail`.) This is how the instances would go with guards: > {-# LANGUAGE ..., InstanceGuards #-} > > instance (a' ~ b) > => FlipMaybe (Maybe a') b | b /~ (Maybe _) where > type Flip (Maybe a') = a' > type Flop b | b /~ (Maybe _) = Maybe b > instance (a ~ b') > => FlipMaybe a (Maybe b') | a /~ (Maybe _) where > type Flip a | a /~ (Maybe _) = Maybe a > type Flop (Maybe b') = b' Note these don't overlap (taking guards into account). IOW we get no available instance for the overlap above. >> it's really proposing dropping type families in favor of >> functional dependencies -- but only for partial type families. ... BTW, while exploring that daft example, I kinda got it to work by declaring `Flip`, `Flop` as stand-alone closed families. But had trouble with the (~) constraints on the class. I changed them to bidirectional FunDeps | a -> b, b -> a and all worked OK. With superclass `(Flop b ~ a)` ghc 8.0.1 complained Couldn't match type Flop b with Maybe b arising from the superclasses of an instance declaration In the instance declaration for FlipMaybe (Maybe a') b and contrariwise for `(Flip a ~ b)` This is perhaps similar to trac #9918 that you mention in the partiality paper. AntC

1 0

Haskell for Mac
by Dennis Raddle 19 May '17

19 May '17

Discovered an amazing $24.99 app: Haskell for Mac. IDE with playgrounds, I expect my small personal projects to work fine with this program, and development should proceed faster now. However I can't find documentation. For instance I'm not getting auto indentation to work for me, and I don't know how to create new modules. There is a community forum, but currently broken - can't log in. Wondering if anyone here has used this app and could direct me to docs. D

2 1

Reminder: Call for Presentations: CUFP 2017, September 7-9, Oxford, UK
by Alex Lang 19 May '17

19 May '17

This is just a reminder that there are 3 weeks until the deadline for CUFP 2017 submissions. I'll be at Compose conference today if anybody wants to ask me any questions. My badge reads "Alexandre Lang". The CFP and the form for submitting presentations proposals can be found at: http://cufp.org/2017/call-for-presentations.html ------------------------------------------------------------------------ > 2017 Call for Presentations > > Workshop for Commercial Users of Functional Programming 2017 > Sponsored by SIGPLAN > CUFP 2017 > Co-located with ICFP 2017 > Oxford, UK > September 7-9 > Talk Proposal Submission Deadline: 9 June 2017 > > The annual CUFP event is a place where people can see how others are > using functional programming to solve real world problems; where > practitioners meet and collaborate; where language designers and users > can share ideas about the future of their favorite language; and where > one can learn practical techniques and approaches for putting functional > programming to work. > > ------------------------------------------------------------------------ > > Giving a CUFP Talk > > If you have experience using functional languages in a practical > setting, we invite you to submit a proposal to give a talk at the event. > We're looking for two kinds of talks: > > Retrospective reports are typically 25 minutes long. Now that CUFP has > run for more than a decade, we intend to invite past speakers to share > what theyâ€™ve learned after a decade spent as commercial users of > functional programming. We will favour experience reports that include > technical content. > > Technical talks are also 25 minutes long, and should focus on teaching > the audience something about a particular technique or methodology, from > the point of view of someone who has seen it play out in practice. These > talks could cover anything from techniques for building functional > concurrent applications, to managing dynamic reconfigurations, to design > recipes for using types effectively in large-scale applications. While > these talks will often be based on a particular language, they should be > accessible to a broad range of programmers. > > We strongly encourage submissions from people in communities that are > underrepresented in functional programming, including but not limited to > women; people of color; people in gender, sexual and romantic > minorities; people with disabilities; people residing in Asia, Africa, > or Latin America; and people who have never presented at a conference > before. We recognize that inclusion is an important part of our ission > to promote functional programming. So that CUFP can be a safe > environment in which participants openly exchange ideas, we abide by the > SIGPLAN Conference Anti-Harassment Policy: > > http://www.sigplan.org/Resources/Policies/Anti-harassment > > If you are interested in offering a talk, or nominating someone to do > so, please submit your presentation before 09 June 2017 via the CUFP > 2017 Presentation Submission Form: > > https://goo.gl/forms/KPloANxHHwdiaoVj2 > > You do not need to submit a paper, just a short proposal for your talk. > There will be a short scribe's report of the presentations and > discussions but not of the details of individual talks, as the meeting > is intended to be more of a discussion forum than a technical > interchange. > > Nevertheless, presentations will be recorded and presenters will be > expected to sign an ACM copyright release form. > > Note that we will need presenters to register for the CUFP workshop and > travel to Oxford at their own expense. There are some funds available to > would-be presenters who require assistance in this respect. > > ------------------------------------------------------------------------ > > Program Committee > > Alex Lang (Tsuru Capital), co-chair > Rachel Reese (Mulberry Labs), co-chair > Garrett Smith (Guild AI) > Danielle Sucher (Jane Street) > Jasper Van der Jeugt (Fugue) > Yukitoshi Suzuki (Ziosoft) > Evelina Gabasova (University of Cambridge) > Brian Mitchell (Jet.com) > > ------------------------------------------------------------------------ > > More information > > For more information on CUFP, including videos of presentations from > previous years, take a look at the CUFP website at http://cufp.org. Note > that presenters, like other attendees, will need to register for the > event. Acceptance and rejection letters will be sent out by July 15th. > Guidance on giving a great CUFP talk > > Focus on the interesting bits: Think about what will distinguish your > talk, and what will engage the audience, and focus there. There are a > number of places to look for those interesting bits. > > Setting: FP is pretty well-established in some areas, including formal > verification, financial processing, and server-side web services. An > unusual setting can be a source of interest. If you're deploying > FP-based mobile UIs or building servers on oil rigs, then the challenges > of that scenario are worth focusing on. Did FP help or hinder in > adapting to the setting? > > Technology: The CUFP audience is hungry to learn about how FP techniques > work in practice. What design patterns have you applied, and to what > areas? Did you use functional reactive programming for user interfaces, > or DSLs for playing chess, or fault-tolerant actors for large-scale > geological data processing? Teach us something about the techniques you > used, and why we should consider using them ourselves. > > Getting things done: How did you deal with large-scale software > development in the absence of pre-existing support tools that are often > expected in larger commercial environments (IDEs, coverage tools, > debuggers, profilers) and without larger, proven bodies of libraries? > Did you hit any brick walls that required support from the community? > > Don't just be a cheerleader: It's easy to write a rah-rah talk about how > well FP worked for you, but CUFP is more interesting when the talks also > cover what doesn't work. Even when the results were all great, you > should spend more time on the challenges along the way than on the parts > that went smoothly.

1 0

exporting Constructors as pattern-only
by Andrew Butterfield 19 May '17

19 May '17

All, is there any way in Haskell to export a *data* type so that importing modules can pattern match, but not use the constructors to build anything? My use case is an AST with invariant - I want the convenience of pattern matching with the safety of having to build using functions exported by the model rather than the constructors directly. e.g given data T = T1 Bool | T2 Int | TT T T t1 :: Bool -> T t2 :: Int -> T tt :: T -> T -> T from outside I can write f(T1 False) = tt (t1 True) (t2 42) but not f(T1 False) = TT (T1 True) (T2 42) ? Regards, Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland

2 2

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

19 May '17

> On Fri May 12 17:22:35 UTC 2017, Richard Eisenberg wrote: > > ... [in] closed type families. (We > would also have to eliminate non-linear patterns, > replacing them with some other first-class test for > equality. > AntC's proposed disequality constraints then become > straightforward pattern guards. Guards don't have to be just disequalities. If you want to eliminate non-linear patterns, use _equality_ guards. Full example: > type family F a b where > F a a = a > F Int b = b > F a Bool = a > Translates to: > type instance F a b | a ~ b = a > type instance F a b | a ~ Int, a /~ b = b > type instance F a b | b ~ Bool, a /~ Int, a /~ b = a (Each instance after the first has disequality guards to negate the earlier instances' equalities., i.e. the earlier instances 'shadow' the overlap.) > It's currently unclear to me how to do this > right. ... > Assuming we have a primitive type-level equality test (?~), returning type-level Bool; we can use helper functions. The first instance desugars to a call > ... = F_a_b_Eq (a ?~ b) a b > type instance F_a_b_Eq True a b = a (Needs UndecidableInstances.) > Section 5.13.2 of my thesis dwells on this, without > much in the way of a concrete way forward.) We use type equality testing all the time. In fact instance selection relies on it. 5.13.2 says: "they [equality testing rules] cannot handle the case where Equals a a reduces to True, where a is locally bound type variable." ?? I thought GHC's equality test requires types to be grounded, i.e. not merely type vars, in order to be judged equal. Or did that change recently? Isn't that to do with impredicativity and the dreaded monomorphism: the same typevar might get a different forall-qualified type in different use sites. Contrast types can be judged dis-equal without necessarily being grounded. [HList paper section 9 refers.] AntC

3 3

parallel package, rts ROOT vs WEAK policy and reachable sparks
by Ruben Astudillo 18 May '17

18 May '17

Dear list This mail is long, but only the 3 last paragraphs are questions, the rest is context. Recently started reading the history of the parallel package. On the changelog of version 2.2 says (I quote) "This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously a -> Done and is now a -> Eval a. This change helps to fix the space leak described in "Runtime Support for Multicore Haskell". The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a "new" value after applying a Strategy, so that the application can evaluate each spark created by the Strategy." I know where are currently on version 3.3. Yet I decided to research a little more on the paper cited. On it is discussed the issue of policy for when to GC sparks. Around page 7 of the paper (I quote) ROOT: Treat (non-fizzled) sparks as roots for the garbage col- lector. That is, retain all such sparks and the graph they point to. WEAK: Only retain (non-fizzled) sparks that are reachable from the roots of the program. The problem is, neither of these policies is satisfactory. WEAK seems attractive, because it lets us discard sparks that are no longer required by the program. However, the WEAK policy is completely incompatible with strategies. Consider the parList strategy: parList :: Strategy a -> Strategy [a] parList strat [] = done parList strat (x:xs) = strat x ‘par‘ parList strat xs Each spark generated by parList is a thunk for the expression “ strat x ”; this thunk is not shared, since it is created uniquely for the purposes of creating the spark, and hence can never fizzle. Hence, the WEAK policy will discard all sparks created by parList , which is obviously undesirable(*). Question 1: Under WEAK policy, On (*) I understand the sparks cannot be fizzle'd, but how are the parList spark not reachable from the roots of the program? surely this function doesn't exist on its own. Somewhere in the program I must be a function that is executed that has an let val = ... `using` parList ... in ... val ... which would make the sparks reachable. Making it a *good* policy to have IMHO. This probably has to do with my understanding of reachable sparks. Question 2: The ROOT policy is discuted to be better, because it supports parList (and old parallel library versions). Yet, the old docs of parallel recomend to that "if you are gonna spark, make sure you use the result to avoid space leaks" ie filter you data before and only spark on that. Is this intuition correct? Question 3: What is the current situation of this? have weak pointers helped in this regard? -- Ruben

2 1

Happy Parsers and constraints
by Alan & Kim Zimmerman 18 May '17

18 May '17

Hi all If I have a happy parser for an AST that is polymorphic, is there any way to put constraints on the individual rules? e.g. if I have data Foo a = Foo String a and a rule something like foo :: { (Show a) => Foo a } foo : otherrule { Foo (show $1) $1 } Because of the way the tables are constructed in happy, the Show constraint is not attached to the point where the rule RHS is applied. Is this simply impossible? Alan

1 0

Digital Asset is hiring Haskell programmers in NYC
by Francesco Mazzoli 18 May '17

18 May '17

TL;DR: We are hiring Haskell programmers in New York City. Feel free to talk to me about it at the NYC Compose conference, if you are around. My badge reads "Francesco Mazzoli" :). Or send me an email at <francesco.mazzoli(a)digitalasset.com>. Digital Asset is a FinTech startup developing distributed ledger technology. Functional programming, and in particular Haskell, play a major role in our tech stack, specifically in the implementation of our smart contract language, DAML. DAML is a functional, typed, total programming language implementing a very general way to formally encode contracts. The designers of DAML all come from the Haskell community, with several members having a history of research in functional programming languages. Thus, we care deeply about principled solutions and formal methods. The team is currently based in Zurich and Sydney, and we're looking to expand to New York City, where the company headquarters are located. The job is on-site in Manhattan. The open role focuses on the development of the tooling supporting DAML, which is written in Haskell. The role can also involve development of production- related components operated by our customers, which are written in Scala. You can find a more corporate job posting here <https://boards.greenhouse.io/digitalasset/jobs/493155#.WR2lfBOGOHo>, although it does not reflect precisely the nature of this role. You can also find a more corporate article about DAML here <https://digitalasset.com/press/introducing-daml.html>. If you're at the NYC Compose conference, then feel free to talk to me (Francesco Mazzoli) about this job posting or about anything else you like. Thanks, Francesco -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

1 0

Why is GHCi so hard to kill?
by Jeremy Henty 18 May '17

18 May '17

If I put ghci into a loop by entering "last $ repeat ()" then the process is impossible to interrupt or kill except with "kill -KILL". (Although it can be stopped with Ctrl-Z.) "kill -TERM" does not work. The same is true if I run a runhaskell script containing "main = putStrLn $ show $ last $ repeat $ ()". Is there a reason for ghci being so unkillable? It is generally considered a bad idea for a program to ignore the TERM signal. (Details: Debian Linux Jessie 8.8, GHC 8.0.2 (built from source).) Regards, Jeremy Henty

3 2