- Haskell-Cafe - Haskell.org

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

matrix package maintenance
by Daniel Díaz Casanueva 17 May '17

17 May '17

Hallo Haskell-Cafe! I am the author and maintainer of the matrix package: http://hackage.haskell.org/package/matrix https://github.com/Daniel-Diaz/matrix For several reasons, mostly time related, I can't give this package the attention it deserves. GitHub issues are not being properly taken care of, and development stopped long time ago. Instead of leaving the package in this state, I thought about giving maintenance powers to anybody interested in continuing this work, or even change its direction in any (reasonable) way. I know the package has some users, so maybe any of you wants to do it. Otherwise, I guess I should try to allocate some time to at least fix some of the issues posted in GitHub. Meanwhile, sorry for the long waiting time that I have imposed on the users of this package that have reported problems or submitted PRs. King regards, Daniel Díaz.

3 2

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

17 May '17

> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: > ... > See my recent draft paper (expanding on the "What are type families" blog post) here: > http://cs.brynmawr.edu/~rae/papers/2017/partiality/partiality.pdf .. > it's really proposing dropping type families in favor of functional dependencies > -- but only for partial type families. ... Thanks for the paper - hard going for me! Yes I can see the sense in grounding type family instances with class instances as Associated Types. I'm not finding it helpful to bring in Functional Dependencies. Your paper only mentions them towards the end [Related Work]; it might be "inspired by" FunDeps, but they don't appear in the paper as such. I'm also not finding it helpful to bring in Instance Chains [despite Garrett's involvement]. There's one major attractive feature of Instance Chains that you kinda mention ["negations" in Related Work], but which closed classes can't support. I see this as a major weakness of your proposal. > The key observation is this: partiality in types is bizarre, and we don't want it. ... Huh? Nearly all type families (and class instances) are partial. You perhaps mean "don't want it" as purist type-theoreticians(?) As a developer of applications I definitely do want it: I want to write instances only for 'sensible' patterns, and have the compiler catch usages not supported by declared instances. Your examples include many from HList: all of those are partial. I mean there's instances (eliding some details): > instance HOccurs e (HCons e l') -- found the element > instance (HOccurs e l') -- search the tail > => HOccurs e (HCons e' l') -- not this element There's deliberately not: > -- instance HOccurs e HNil -- Fail: not found Let alone: > -- instance HOccurs e (Maybe a) -- not an HList! Even if we rewrite to DataKinds, GHC has no knowledge that there's a closed set of type constructors. The only type family that usually is total is the type equality test (yielding a type-level Boolean), and your Introduction tells me that's problematic. sheesh > So, any time we use a partial type family, > you need to have a class constraint around. > The class constraint ensures that we evaluate the type family > only within its defined domain. OK. Good. > Now tied to classes, partial type families are more like > convenient syntax for functional dependencies. You perhaps mean the effect achieved by declaring > class (F a b ~ c) => C a b c where ... constraints with Type Families on a class context? OK yes that achieves the effect of FunDeps. And it's more convenient syntax. > There is also treatment of partial closed type families > via a new construct, closed classes > (somewhat like instance chains but weaker). As you predicted, I dislike closed classes even more than closed families. Let me explain what feature of Instance Chains you've left out. [Section 3.1.2 "Explicit Failure" of the 2010 paper] Sometimes I deliberately want there to be no instance for some specific pattern. I typically can't achieve that with Overlapping Instances. So: * Instance Chains have an explicit `Fail` case. [good] * HList has an instance with a Fail constraint. [clumsy] (I.e. an instance constraint to a class with no instance. See HOccursNot with class Fail in the HList paper section 6 at "Static look-up") * Type family instances (currently) don't have constraints, so this is hard work to arrange. IOW what's going on is _deliberately_ a partial type function. > > I expect AntC would prefer disequality guards over closed classes. Yes. Because I can 'precision control' which instances are available. Take HOccursNot (validates an HList to make sure some element does not occur, typically in combo with making sure the list has exactly one occurrence): > class HOccursNot e l -- no methods! use for constraint only > instance HOccursNot e HNil > -- instance omitted, see below > instance (HOccursNot e l') > => HOccursNot e (HCons e' l') | e /~ e' -- guarded Without disequality guards, the HList paper has to insert a bogus overlapping instance for a matched element type: > instance (Fail (TypeFound e)) => HOccursNot a (HCons e l') > ... The big problem with branched instances is that it was > awkward to describe the overlap between two branched instances. > AntC might argue that, if we just had disequality guards, > it would all be much simpler. He might be right. This is an important point; we must be careful. The rule for instances with guards is: no overlaps! (That is, after taking guards into account.) That is how "to describe the overlap between two branched instances": there is no overlap. The heads might overlap, but the guards force them apart. Any sort of attempt to control overlap can be stymied by imports. A closed set of instances avoids that. (I would say at cost of needing to read all preceding instances to understand the conditions for a later instance.) With guards, I can attach all the conditions to the instance itself. And then compare to each other instance to validate no overlaps -- even for imports. How would I describe the semantics, within the formalism in your partiality paper? Section 6.3: "we use axioms [xi] to witness type family reductions. That is, if there is an equation `type F Int = Bool` in scope, then we have an axiom [xi] that proves `F Int ∼ Bool`." Ok for in scope > type F a | a /~ Int = Char we get an axiom: (F a ~ Char <=> a /~ Int) -- bi-implication. [Unashamedly stolen from the CHR work.] This axiom system is coherent providing there are no other equations for `F`. Note also with disequalities we get an inference rule: a /~ b, b ~ c ===> a /~ c AntC

1 0