- Haskell-Cafe - Haskell.org

Munich Haskell Meeting, 2018-10-30 @ 19:30
by Leah Neukirchen 28 Oct '18

28 Oct '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 30 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-oct-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

mfix for a nested monad
by Benjamin Redelings 25 Oct '18

25 Oct '18

Hi, I'm trying to implement mfix for a monad that is nested inside another monad. I came up with the following logic for how to implement this, but I suspect there are some things I'm missing. My conclusion is that I want interpret (MFix f) = mfix (interpret.f) Does this seem right? Has this situation been discussed somewhere? -BenRI P.S. Here's what I mean by the monad being nested in another monad. Let's say that the monad M2 has interpreter i2, with type i2 :: M2 a -> M1 a and then M1 is the other monad, and has interpreter i1: i1 :: M1a -> a I suppose that the nesting is really a nesting of interpreters. P.P.S. I came up with some equational reasoning for how to treat mfix in the i2 interpreter. (a) For some interpreters `i`, it makes sense to require i (mfix f) = let x = (i . f) x in x (b) I want the composition of interpreters (i1.i2) to act like (a) above: (i1 . i2) (mfix f) = let x = (i1 . i2 . f) x in x (c) Rearranging, and then substituting using (a): i1 (i2 (mfix f)) = let x = i1 . (i2 . f) x in x = i1 (mfix (i2 . f)) (d) Therefore, we could set i2 (mfix f) = mfix (i2 . f) I'm probably going to make a `data` declaration for M2 so I could actually write i2 (Mfix f) = mfix (i2 . f) -BenRI

2 1

Re: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined]
by Anthony Clayden 25 Oct '18

25 Oct '18

Transferring from https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html On Sat, 13 Oct 2018 at 4:04 AM, <camarao(a)dcc.ufmg.br> wrote: > > Consider for example: > > class F a b where f:: a → b > class X a where x:: a > fx = f x > > The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in > distinct contexts, fx can have distinct types (if ambiguity, and > 'improvement', are as defined below). [See the -prime message for the "defined below".] I'm just not seeing why you think any Haskell should accept that. What value could inhabit `fx` except bottom? And indeed no Haskell does accept it, not even GHC with all sorts of nasty extensions switched on, including `AllowAmbiguousTypes`. GHC will accept class `F` with a Functional Dependency `b -> a`, but still I can't 'poke' any value into the `x` argument to `f` in the equation for `fx`. Note: agreeing with this view can lead to far-reaching consequences, e.g. > support of > overloaded record fields [1,Section 7], ... There are other ways to support overloaded/duplicate record fields, without doing this much violence to the type system. Look at the `HasField` class using Functional Dependencies, in Adam Gundry's work. polymonads [2] etc. > Note that's from a Trac ticket asking for 'dysfunctional' Functional Dependencies. There's a long discussion from the type-inference brains trust coming to no discernable conclusion as to whether it's broken type safety. (Catching incoherence in the Core lint typecheck is not a good look.) a) You've not shown any detailed working of how your proposal gives the type improvement required without also descending into incoherence. b) The combination of Functional Dependencies+Overlapping Instances+Undecidable Instances might be able to cover just enough, but not too much of the requirements (which were never made clear). See my worked examples on that ticket -- some of which are really quite scary. See some of Oleg's work on his ftp site with multi-directional FunDeps and overlaps to achieve injectivity. To try to tame the scariness while still supporting enough power, see the suggestion here https://ghc.haskell.org/trac/ghc/ticket/15632 > Further examples can be discussed I have yet to see a convincing use case (from the very lengthy discussions) which couldn't be handled already in GHC. I agree the combination of extensions in GHC (including its bogus consistency check/Trac #10675) can give alarming surprises; but they don't quite break type safety. but this example conveys the > main idea that ambiguity should be changed; unlike the example > of (show . read), no type annotation can avoid ambiguity of > polymorphic fx in current Haskell. Since `fx` is not accepted in current Haskell, whether you can put a type annotation seems beside the point. AntC [1] Optional Type Classes for Haskell, Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano Vasconcellos, SBLP'2016 (20th Brazilian Symposium on Programming Languages), Marília, SP, September 19-23, 2016. [2] https://github.com/carlos1camarao/ghc-proposals/blob/d81c1f26298961ac635ce0…

2 2

property testing with context
by Ben Franksen 24 Oct '18

24 Oct '18

Hi everyone it seems to be the season for new variations on the "property testing" theme, so I would like to chime in... not to announce a new library, sadly, but with a rough idea how the existing ones could perhaps be improved, based on practical experience in Darcs. The problem I have is that there is a tension between (a) stating a property in a clear and simple way, so its code doubles as a formal specification and (b) writing the property in such a way that when it fails, the reported value(s) give enough information about the context to be useful for finding the cause of the problem. Let me give an example to demonstrate what I mean. There is a simple law that says if a sequential pair of patches A;B commutes to B';A' then B';A' commutes back to A;B. In code this looks (more or less) like this: prop_recommute :: Commute p => (p :> p) wA wB -> Bool prop_recommute (x:>y) | Just (y':>x') <- commute (x:>y) = case commute (y':>x')of Just (x'':>y'') -> x==x'' && y==y'' Nothing -> False | otherwise = True This is a bit more verbose than the informal spec but still quite readable. Now suppose this property fails. So quickcheck reports the counter example pair (X:>Y) for some X and Y. But that isn't too useful in itself. We'd like to know a bit more: * did the second commute fail? * or did it succeed but x/=x'' or y/=y''? * and in the latter case, which of the two? So in practice our property code looks more like this: prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool prop_recommute (x :> y) | Just (y' :> x') <- commute (x :> y) = case commute (y' :> x') of Nothing -> failed (redText "failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x') Just (x'' :> y'') -> if y'' /= y then failed (redText "y'' =/\\= y failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else if x'' /= x then failed (redText "x'' /= x, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else True | otherwise = True Now this code tells us exactly what went wrong when the property fails but it is ugly and repetitive and the additional code obscures the simple logical content. So this is no longer quite as suitable for a (human readable) formal spec. I wonder if displaying (1) all relevant contextual variables and (2) "where in the code it fails" could be automated away, somehow. I guess this is not trivial and may require syntactic analysis, so perhaps expecting a /library/ to solve the problem is unrealistic, except perhaps by using Template Haskell. I'd also go with a separate tool that extracts properties from a module and enriches them with code that displays the additional information. Tackling this problem might be an interesting theme for a master thesis... ;-) Cheers Ben

4 7

Has twidge stopped working?
by Rider of Giraffes 24 Oct '18

24 Oct '18

Greetings, New on the list, apologies if I break any traditions. Sent here from https://github.com/jgoerzen/twidge/wiki with the question in the header. I sent a tweet via twidge on Oct 22, but since then nothing has got through. Has twidge stopped working? Has Twitter made yet another change to the API, this one incompatible? All assistance and advice welcome. Thank you. -- I don't suffer from stress - I'm a carrier.

2 1

Re: [Haskell-cafe] property testing with context
by Olaf Klinke 24 Oct '18

24 Oct '18

Ben, the solution might be simple: Don't express the property as an atomic function (a -> Bool). This reminds me a bit of the Cutty-Howard correspondence, only that proofs are replaced by counterexamples. A testing library should have an operator for each of the logical connectives, where - a counterexample to True is never found - a counterexample to False is () - a counterexample to (not x) is an example for x - a counterexample to (x && y) is either a counterexample to x or a counterexample to y, whichever is found first - a counterexample to (x || y) is a pair of counterexamples to both x and y - a counterexample to (x ==> y) is an example for x together with a counterexample for y Then, if you build your property out of smaller properties and the connectives above, the counterexample-finder would be able to inform you which part of the property failed. I'm pretty sure at least one of the testing libraries has a system like this. Cheers, Olaf

2 1

ANN: Yampa-0.12 and yampa-test (QuickCheck-based FRP testing)
by Ivan Perez 22 Oct '18

22 Oct '18

Dear all, I am please to announce version 0.12 of Yampa! Yampa is a mature and robust FRP implementation that has been used to create mobile, desktop, and web games and applications, including commercial mobile games available on iTunes and Google Play, and open source games that use devices like wiimotes and kinect [1-2]. This version comes with an accompanying library, yampa-test, which includes QuickCheck-based testing with LTL-based signal predicates. These features are described in the ICFP 2017 paper "Testing and Debugging Functional Reactive Programming" [3]. Thanks to Christina Zeller for reporting bugs. Both libraries can be found here: http://hackage.haskell.org/package/Yampa http://hackage.haskell.org/package/yampa-test This version has been tested against all major GHC versions from 7.6 to 8.6. Some legacy code has been deprecated, which has triggered a major version bump (0.12). I would expect all projects that use Yampa to work by, at most, adapting the version constraints in the cabal files. New versions of Yampa will present a simpler API, better documentation and benchmarks [4]. As always, contributions are welcome. There are a number of issues on the github page that are particularly suitable for beginners [5]. Happy Haskelling! Ivan [1] https://github.com/ivanperez-keera/Yampa#other-examples [2] https://haskell.games [3] https://dl.acm.org/citation.cfm?id=3110246 [4] https://github.com/ivanperez-keera/Yampa/milestones [5] https://github.com/ivanperez-keera/Yampa/labels/help%20wanted

1 0

(Sample) bioinformatics applications
by Vasili I. Galchin 22 Oct '18

22 Oct '18

Hello, Do any of these beasts exist for reference? Regards, Vasily

1 0

Well typed OS
by Yotam Ohad 22 Oct '18

22 Oct '18

Hi, In the last couple of days, I've been toying with the thought of an operating system in which programs (or more accurately, any process) has a distinct type which limits its use of the machine. For example, `echo` (String -> String) won't be able to print an output without a second program which would handle changing stdout. I think it could "break down" the IO monad into other structures that are better at specifying what is changing: A file is read / memory written / etc. I do, however, not sure how to incorporate drivers (which handles IO and external devices) into this. Giving them an `IO a` type feels like cheating. I would be much cooler if there was a way to treat them like the `echo` function from earlier. What are your thoughts/suggestions? I'll be happy to hear them. Yotam

13 26

Why is the Cabal User's Guide left outdated?
by Yuji Yamamoto 20 Oct '18

20 Oct '18

Getting interested in the features since Cabal 2.2 (esp. common stanzas), I looked up with the User's Guide <https://www.haskell.org/cabal/users-guide/>, which is (and should be) listed in the search result first, but can't find because the User's Guide is still about Cabal 2.0. Why is it left outdated? Actually User's Guide (HEAD) <https://cabal.readthedocs.io/en/latest/> is kept updated, but it's hard to find, and can include some information too new to release. Thanks in advance. -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep

2 2

"Update
by Nikita Fufaev 20 Oct '18

20 Oct '18

-- Nikita Fufaev, +7 999 825-95-07

1 0

BOB - Call for Contributions 2019
by Matthias Fischmann 19 Oct '18

19 Oct '18

Subject: Call for Contributions: BOB 2019 - Berlin, Mar 22, 2019 BOB Conference 2019 "What happens when we use what's best for a change?" http://bobkonf.de/2019/en/cfc.html Berlin, March 22 Call for Contributions Deadline: November 23, 2018 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Speaker Grants BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------- We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Submit here: https://bobcfc.active-group.de/en/bob2019/cfp Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 23, 2018 - Notification: December 7, 2018 - Program: December 21, 2018 Program Committee ----------------- (more information here: http://bobkonf.de/2019/en/programmkomitee.html) - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0

Fwd: [Haskell] Help inform GHC's development priorities
by Takenobu Tani 19 Oct '18

19 Oct '18

(It is sending to the correct address of haskell-cafe ML.) ---------- Forwarded message --------- From: Ben Gamari <ben(a)well-typed.com> Date: Fri, Oct 19, 2018 at 4:45 AM Subject: [Haskell] Help inform GHC's development priorities To: GHC developers <ghc-devs(a)haskell.org>, <haskell(a)haskell.org>, Haskell Cafe <haskell-cafe(a)googlegroups.com>, GHC users < glasgow-haskell-users(a)haskell.org> tl;dr. Please a take a minute to express your thoughts on GHC's development priorities via this survey [1]. Hello everyone, The GHC developers want to ensure that we are working on problems that of most importance to you, the Haskell community. To this end we are surveying the community [1], asking how our users interact with GHC and which problems need to be addressed most urgently. We hope you will take a few minutes to give us your thoughts [1]. Thanks in advance for your time and, finally, thanks to the financial supporters that make our work GHC possible. Cheers, - Ben and the rest of the GHC developers [1] https://docs.google.com/forms/d/e/1FAIpQLSdh7sf2MqHoEmjt38r1cxCF-tV76OFCJqU… _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

1 0

ANN: Extrapolate: generalized QuickCheck-style counterexamples.
by Rudy Matela 17 Oct '18

17 Oct '18

Hello Haskell-Café, A new version of Extrapolate is out: v0.3.5. Since the last announcement here improvements have been made in performance and stability. In addition, the IFL revised accepted paper is finally out (see end of the e-mail). For those who don't know Extrapolate, it is a property testing library capable of reporting generalized counterexamples to properties. Here is a simple example: $ ghci > import Test.Extrapolate > import Data.List (nub) > check $ \xs -> nub xs == (xs :: [Int]) *** Failed! Falsifiable (after 3 tests): [0,0] Generalization: x:x:_ Conditional Generalization: x:xs when elem x xs The above property not only fails for the list `[0,0]` but also for any list of the form `x:x:_`. This hints that the above property fails whenever the argument list has repeated elements. The above example is perhaps artificial: the property is obviously wrong! But it does illustrate what Extrapolate is able to produce: aside from the fully defined counterexample it reports a conjectured generalization with some parts of the counterexample replaced by variables or holes. Generalization is particularly helpful when dealing with bigger counterexamples. The following fully-defined counterexample to one of XMonad's properties StackSet { current = Screen { workspace = Workspace { tag = 0, layout = 0, stack = Just ( Stack { focus = 'a', up = "", down = "" } ) }, screen = 0, screenDetail = 0 }, visible = [], hidden = [], floating = fromList [] } is reported by Extrapolate alongside a much simpler generalization: StackSet (Screen (Workspace _ _ (Just _)) _ _) _ _ _ Full details for the above example are given in the research paper. Get Extrapolate with: $ cabal install extrapolate See the Haddock documentation and the project README for more details. I'm interested in input from the Haskell community about Extrapolate. Please let me know if it works (or not) for you. Links: * Research paper (link 1): https://matela.com.br/paper/extrapolate.pdf * Research paper (link 2): https://dl.acm.org/citation.cfm?id=3205371 * Hackage: https://hackage.haskell.org/package/extrapolate * GitHub: https://github.com/rudymatela/extrapolate Best Regards, Rudy

1 0

ANN: DBFunctor – Functional Data Management / ETL Data Processing in Haskell
by Nikos Karagiannidis 16 Oct '18

16 Oct '18

Dear all, I am pleased to announce the release on Hackage of a new Haskell ETL Library, namely DBFunctor-0.1.0.0. (“ETL” stands for Extract Transform and Load and is the standard technology for accomplishing data management tasks in Data Warehouses / Data Marts and in general for data migrations, or for preparing data for any analytic purpose (Ad hoc queries, data exploration/data analysis, Reporting and Business Intelligence, feeding Machine Learning algorithms, etc.)) Version 0.1.0.0 can be used for **in-memory** data processing without the need of some external database. It is just a Haskell library linked in your Haskell program that enables full SQL functionality over tabular data (e.g., CSV files) but also the ability to write a full ETL data processing flow. Key features of this release are: 1. ** Julius DSL ** : A Type-Level Embedded Domain Specific Language (EDSL) for ETL 2. Supports all known relational algebra operations 3. Implements the ETL Mapping and other typical ETL constructs and operations 4. Applicable to all kinds of tabular data 5. In-memory, database-less data processing For more information please check out the project homepage: https://github.com/nkarag/haskell-DBFunctor Also there is a tutorial that can help you to easily get started with Julius DSL: https://github.com/nkarag/haskell-DBFunctor/blob/master/doc/JULIUS-TUTORIAL… * Learn how to implement your ETL flows with Julius DSL * Learn how to implement common ETL operations (e.g., append a delta to some target table, or create a surrogate key column etc.) * Build your own aggregate or analytic functions (e.g., string_agg, or a montlhy running total) * Express complex queries with Julius (equivalent to the WITH-clause in SQL) * and many more ... For any issues/problems with the DBFunctor package please open an issue on github. Happy data processing! Thank you. Best Regards, Nikos

1 0

Re: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined]
by Anthony Clayden 15 Oct '18

15 Oct '18

Transferring from https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html Second instalment. On Sat, 13 Oct 2018 at 4:04 AM, <camarao(a)dcc.ufmg.br> wrote: > ... > Ambiguity should be a property of an expression, defined as > follows: if a constraint set C on the constrained type C∪D⇒t of > an expression has unreachable variables, then satisfiability is > tested for C (a definition of reachable and unreachable type > variables is at the end of this message), and: > > - if there is a single unifying substitution of C with the set > of instances in the current context (module), then C can be > removed (overloading is resolved) and C∪D⇒t 'improved' to > D⇒t; > > - otherwise there is a type error: ambiguity if there are two > or more unifying substitutions of C with the set of instances > in the current context (module), and unsatisfiability > otherwise. > > 2. Allow instances to be imported (all instances are assumed to be > exported): > > import M (instance A τ₁ ⋯ τₙ , … ) > > specifies that the instance of τ₁ ⋯ τₙ for class A is > imported from M, in the module where the import clause > occurs. > > In case of no explicit importation, all instances remain > imported, as currently in Haskell (in order that well-typed > programs remain well-typed). > Consider some typical Read instances from the Haskell Prelude > instance Read a => Read [a] where ... > instance Read a => Read (Maybe a) where ... Suppose I have `show . read` where the 'piggy in the middle' type is unreachable (by your definition below); but I want it to be taken as `(Maybe [Int])`. Then I arrange my imports of instances to make visible only ... what? `(Maybe a)` ? Then how do I read the `[a]`? The only instance in scope is `(Maybe a)`. `(Maybe [Int])` ? Then how do I decompose the structure to call the overloads for `read` of the list and of the `Int`? Instance `(Maybe a)` is not in scope, neither is `[a]` nor `Int`. And what if in the same module/same scope I want `show . read` where 'piggy in the middle' is `[Maybe Int]` or `(Maybe [Bool])` ? Then instead of `Read`, I could create a whole swag of specialised classes/methods: ReadMaybeListInt, ReadListMaybeInt, ReadMaybeListBool, ... ? But those could just be regular functions with an explicit signature. Putting an explicit type annotation on each expression seems a whole lot more convenient than mucking around with specialised classes or scope of instances. Before you answer, consider this very common pattern. It's so common there's a base library operator for it: type-level `==` https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.12.0.0…; but the technique dates back to 2004/the HList paper at least: > class TypeEq a a' (b :: Bool) | a a' -> b > instance TypeEq a a True > instance (b ~ False) => TypeEq a a' b Then an example usage > instance (TypeEq e e' b, TypeIf b This That) => instance Elem e (Cons e' tail) where ... Rubric: `Elem` is searching for type `e` in some type-level heterogeneous list; if found (i.e. `TypeEq` returns `True`), the `TypeIf` despatches to `This`, else to `That`. It's crucial for `TypeEq` that both instances are in scope in all places. Ah, but I see the `TypeEq` example does not contain any "unreachable" tyvars by your definition below. In which case your specification is silent as to how type improvement is to behave. (But you claim your approach is instead of FunDeps; then what is to happen with both instances being able to unify with the type of some expression?) Then do you want to change the spec? This was the experience with the github rounds: the spec kept changing; the examples we'd worked through in earlier rounds then didn't work with the new spec. Therefore the claims were impossible to verify with any certainty. > > (Definition: [Reachable and unreachable type variables in constraints] > Consider a constrainted type C∪D⇒τ. A variable a ∈ tv(C) is reachable > from V = tv(τ) if a ∈ V or if a ∈ tv(π) for some π ∈ C such that there > exists b ∈ tv(π) such that b is reachable from V; otherwise it is > unreachable. > For example, in (F a b, X a) ⇒ b, type variable 'a' is reachable from > { b }, because 'a' occurs in constraint F a b, and b is reachable. > Similarly, if C = (F a b, G b c, X c), then c is reachable from {a}.) > > AntC

1 0

[ANNOUNCE] GHC 8.4.4 released
by Ben Gamari 14 Oct '18

14 Oct '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.4, a patch-level release in the 8.4 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.4 This release fixes several bugs present in 8.4.3 These include, - A bug which could result in memory unsafety with certain uses of `touch#` has been resolved. (#14346) - A compiler panic triggered by some GADT record updates has been fixed (#15499) - The `text` library has been updated, fixing several serious bugs in the version shipped with GHC 8.4.3 (see `text` issues #227, #221, and #197. - A serious code generation bug in the LLVM code generation, potentially resulting in incorrect evaluation of floating point expressions, has been fixed (#14251) As always, the full release notes can be found in the users guide, https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here:

1 0

ANN: DBFunctor – Functional Data Management / ETL Data Processing in Haskell
by Nikos Karagiannidis 14 Oct '18

14 Oct '18

Dear all, I am pleased to announce the release on Hackage of a new Haskell ETL Library, namely DBFunctor-0.1.0.0. (“ETL” stands for Extract Transform and Load and is the standard technology for accomplishing data management tasks in Data Warehouses / Data Marts and in general for data migrations, or for preparing data for any analytic purpose (Ad hoc queries, data exploration/data analysis, Reporting and Business Intelligence, feeding Machine Learning algorithms, etc.)) Version 0.1.0.0 can be used for *in-memory data processing* without the need of some external database. It is just a Haskell library linked in your Haskell program that enables full SQL functionality over tabular data (e.g., CSV files) but also the ability to write a full ETL data processing flow. Key features of this release are: 1. *Julius DSL*: A Type-Level Embedded Domain Specific Language (EDSL) for ETL 2. Supports all known relational algebra operations 3. Implements the ETL Mapping and other typical ETL constructs and operations 4. Applicable to all kinds of tabular data 5. In-memory, database-less data processing For more information please check out the project homepage: https://github.com/nkarag/haskell-DBFunctor Also there is a tutorial that can help you to easily get started with Julius DSL: https://github.com/nkarag/haskell-DBFunctor/blob/master/doc/JULIUS-TUTORIAL… * Learn how to implement your ETL flows with Julius DSL * Learn how to implement common ETL operations (append a delta to some target table, or create a surrogate key column etc.) * Build your own aggregate or analytic functions (string_agg, or a montlhy running total) * Express complex queries with Julius (equivalent to the WITH-clause in SQL) * and many more ... For any issues/problems with the DBFunctor package please open an issue on github. Happy data processing! Thank you. Best Regards, Nikos

1 0

Creating the network-bsd package
by Kazu Yamamoto 12 Oct '18

12 Oct '18

Hi, We the network package maintainers are planning to release network v3.0.0.0 which enables extending socket addresses. In this version, we will remove the Network.BSD module which version 2.7 already deprecates. Unfortunately, it appeared that many users use Network.BSD and there is no good alternative. So, I would like to split it into another package, say, network-bsd. Some years ago, the same thing happened to Network.URI, resulting in the network-uri and network-uri-flag packages. Currently, I'm planing to take the same approach: ---- flag network-bsd library -- ... if flag(network-bsd) build-depends: network-bsd >= 3.0, network >= 3.0 else build-depends: network-bsd < 3.0, network < 3.0 --- Or ---- build-depends: network >= 2.5 && < 2.7, network-bsd >= 2.5 && < 2.7, network-bsd-flag == 0.1.* --- Question: is this a correct appoarch? Or are there any better ways to split Netwrok.BSD? --Kazu

2 1

NYC Haskell Developer Position
by Christopher Lewis 11 Oct '18

11 Oct '18

Karamaan Group is an investment firm based in Manhattan. We are looking for an outstanding software developer to develop tools for financial analysis and knowledge management. Since we are investors and not traders, our focus is not on building trading systems, but on business and data analysis. We strongly value people who take pride in their work and have a craftsman’s dedication to building bespoke products. Our ideal candidate is an experienced software developer with a penchant for abstraction and analysis, a solid sense of organization, and an ability to communicate and persuade. While we are looking for a candidate who demonstrates an intense focus on quality, she also needs a master engineer’s intuition for how to make trade offs that are a necessary part of day-to-day software development. Candidates should have some formal training in a quantitative field and a keen interest in building robust and elegant software. This is a high-impact, high-visibility position where successful candidates will be entrusted with a lot of responsibility for products that have a direct effect on the P&L of the firm and influence on our workflow. The ideal candidate will have production experience with Haskell or another functional language, relational databases and relational data modeling, Python, and Java. Additionally, as this is a startup environment, the ideal candidate will be comfortable filling many different technology roles, and contributing to the success of the firm wherever they can, not just in agreement with their job description. Karamaan Group is an investment adviser and manager catering to family offices and institutional investors. We value innovative thinking, encourage an entrepreneurial atmosphere, and enjoy spirited discussions. Please send your CV and cover letter to recruitment at karamaan dot com. Please do not reply to the original poster.

1 0

What is the best way to search information on Haskell Cafe?
by Rodrigo Stevaux 09 Oct '18

09 Oct '18

I am new to mailing lists. Like really new.

10 10

Re: [Haskell-cafe] Well typed OS
by Barak A. Pearlmutter 08 Oct '18

08 Oct '18

At a high level, you seem to be proposing encoding and enforcing safety properties of executables using a type system. One instantiation of this idea is proof-carrying-code (Necula and Lee, 1996, see https://en.wikipedia.org/wiki/Proof-carrying_code) which ensures safety properties of machine code. The spin-off Cedilla Systems built a mobile OS (intended for phones) around this, with the idea that third-party apps would run unprotected with safety guaranteed solely by sophisticated use of types. The Fox Project, http://www.cs.cmu.edu/~fox/, was philosophically similar, and their web page contains a bunch of interesting pointers to relevant work. For whatever reason, this stuff never got much penetration. But in today's Internet of Things, with malware being injected into mobile phones and cars and light bulbs and toothbrushes and smart dust, it may deserve another look.

7 11

Looking for maintainers for all my packages
by John Goerzen 07 Oct '18

07 Oct '18

Hi folks, I would like to hand over my remaining Haskell packages to good hands. Please reply, CCing me, if you would like to volunteer. Thanks! These packages are: Libraries: ConfigFile HSH MissingH MissingPy (looks like MattBrown uploaded it a bit in 2012) anydbm ftphs hslogger magic testpack Programs: datapacker gtkrsync hpodder twidge txt2rtf Obsolete, no maintainer needed: darcs-buildpackage dfsbuild gopherbot hg-buildpackage srcinst - John

1 0

[Call for Contributions] Haskell Communities and Activities Report, November 2018 edition (35th edition)
by Mihai Maruseac 06 Oct '18

06 Oct '18

Dear all, We would like to collect contributions for the 35th edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 4 November 2018 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac FAQ: Q: What format should I write in? A: Any format is ok, I will transpose the submission to the format in use at the time of publication. Previous editions have used a LaTeX format, with the template that is available at: http://haskell.org/communities/11-2018/template.tex And the associated LaTeX style file at http://haskell.org/communities/11-2018/hcar.sty You can use those to edit and preview your entry, but it is very likely that by the time of publication the entire HCAR pipeline would be changed to a more modern one. You will receive a copy of the draft, prior to publication, to ensure that everything looks ok. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. If using LaTeX, you can use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/) The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then. PNG is preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachments are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

1 0

Which pretty print library?
by waldmann 04 Oct '18

04 Oct '18

Dear Cafe, what is today's answer to this old question: https://stackoverflow.com/questions/9761507/which-pretty-print-library In particular, I agree with author's: "The thing that worries me about these [many pretty-printing libraries] is that many of them have many releases. This implies they've had features added, bugs fixed, etc. But have they all had the same bugs fixed?" Meanwhile, there's https://hackage.haskell.org/package/prettyprinter "This package solves all these issues, and then some." (clearly an instance of https://xkcd.com/927/ ) GHC is using pretty-1.1.3.6 ? - J.W.

3 2

[JOB] Haskell job opportunity at RELEX Solutions in Helsinki, Finland
by Mats Rauhala 02 Oct '18

02 Oct '18

Would you like to get paid for writing Haskell? And do you live in Europe, preferably in Helsinki, Finland? If yes, please read on. RELEX Solutions is Europe's fastest growing provider of integrated retail and supply chain planning solutions. We are looking for a few Haskell developers to join our small, but impactful group of Haskellers to develop our internal tools. In this position you will be exposed to various technologies, such as Haskell, Servant, Elm, GHCJS, Terraform, Ansible, Nix, RHEL/CentOS, AWS etc. Your own interests are influential in what your daily work will consist of. Your main responsiblities will be some mix of development, operations and support of and around our coordination system. Interested in applying? Follow the link: https://relex.recruiterbox.com/jobs/fk01gjr/ Full remote for this position is negotiable, but you should be able to be present at the Helsinki office at least for a couple of weeks, preferably longer. Details of your contract are largely negotiable. Please note that the available position will be filled as soon as suitable candidates are found, so don't wait too long ;). I'm also available for questions: - 'masser' at functionalprogramming slack - 'MasseR' at freenode - 'mats.rauhala(a)gmail.com' email or on this mailing list. -- Mats Rauhala

2 1

Internship at Tsuru
by Mikhail Baykov 02 Oct '18

02 Oct '18

Hi Cafe Tsuru Capital is looking for interns. Haskell knowledge is required, experience with pricing futures/options would be nice but not necessary. Located in Tokyo, company language is English. Casual environment, nice monitors and a big coffee machine. Duration 3-4 months, starting at your convenience. We will help you with visa and looking for a place to stay. There's some salary. Details how to apply are on our website. https://www.reddit.com/r/haskell/comments/9knxtu/tsuru_is_looking_for_more_… Feel free to ask questions here, in email or #tsurucapital on freenode.

1 0

Natural Deduction
by Yasuaki Kudo 02 Oct '18

02 Oct '18

Hi, I have already sent similar questions to other forums but am still looking. Would you please advise where I can find a good explanation of Natural Deduction? I have been reading the link below so far. http://www.cs.cmu.edu/~fp/courses/atp/handouts/ch2-natded.pdf Cheers! Yasu

1 0

ANN: hledger-1.11 released
by Simon Michael 01 Oct '18

01 Oct '18

Short announcement this quarter. Pleased to announce the release of hledger 1.11 on schedule! Thanks to release contributors Joseph Weston, Dmitry Astapov, Gaith Hallak, Jakub Zárybnický, Luca Molteni, and SpicyCat. stack users will need to get a copy of hledger source and do stack install from there, due to the recent GHC 8.6 release. cabal install hledger-1.11 should work normally. From http://hledger.org/release-notes.html#hledger-1.11 <http://hledger.org/release-notes.html#hledger-1.11> : hledger 1.11 The default display order of accounts is now influenced by the order of account directives. Accounts declared by account directives are displayed first (top-most), in declaration order, followed by undeclared accounts in alphabetical order. Numeric account codes are no longer used, and are ignored and considered deprecated. So if your accounts are displaying in a weird order after upgrading, and you want them alphabetical like before, just sort your account directives alphabetically. Account sorting (by name, by declaration, by amount) is now more robust and supported consistently by all commands (accounts, balance, bs..) in all modes (tree & flat, tabular & non-tabular). close: new –opening/–closing flags to print only the opening or closing transaction files: a new command to list included files prices: query arguments are now supported. Prices can be filtered by date, and postings providing transaction prices can also be filtered. rewrite: help clarifies relation to print –auto (#745) roi: a new command to compute return on investment, based on hledger-irr test: has more verbose output, more informative failure messages, and no longer tries to read the journal csv: We use a more robust CSV lib (cassava) and now support non-comma separators, eg –separator ‘;’ (experimental, this flag will probably become a CSV rule) (#829) csv: interpolated field names in values are now properly case insensitive, so this works: fields …,Transaction_Date,… date %Transaction_Date journal: D (default commodity) directives no longer break multiplier amounts in transaction modifiers (AKA automated postings) (#860) journal: “Automated Postings” have been renamed to “Transaction Modifiers”. journal: transaction comments in transaction modifier rules are now parsed correctly. (#745) journal: when include files form a cycle, we give an error instead of hanging. upper-case day/month names in period expressions no longer give an error (#847, #852)

1 1

Status of Cloud Haskell
by Alejandro Serrano Mena 28 Sep '18

28 Sep '18

Dear Café, I was wondering what is the current status of Cloud Haskell. Their website only mentions things until 2016, but I see that the 'distributed-process' library is itself well-maintained. It Cloud Haskell still the way to go for distributed processes in Haskell? Regards, Alejandro

2 1

Where is "minimumsBy"?
by Tom Ellis 28 Sep '18

28 Sep '18

Data.List.minimumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a https://www.stackage.org/haddock/lts-12.1/base-4.11.1.0/Data-List.html#v:mi… but there are many cases where that's quite unhelpful. Actually what we want is more like minimumsBy :: ... => (a -> a -> Ordering) -> t a -> [a] There can be many distinct minimizers. For example when I want to get the collection of the youngest people from [(Age, Person)] I want minimumsBy (compare `on` fst) [(12, alice), (15, balaji), (12, cho)] to return [(12, alice), (12, cho)] Does "minimumsBy" exist somewhere reasonably standard? Hoogle doesn't throw up anything obvious https://www.stackage.org/lts-12.1/hoogle?q=%28a+-%3E+a+-%3E+Ordering%29+-%3… Thanks, Tom

8 11

Suppress re-exported module's docs ...
by aditya siram 27 Sep '18

27 Sep '18

Is there any way to have Haddock ignore a re-exported module without hiding it? eg. here all of `B`'s exports/docs show up in `A`'s Haddock page and I don't want to see them there: module A ( ... module B ) import B ...

2 1

Re: [Haskell-cafe] clonetype
by Oleg Grenrus 26 Sep '18

26 Sep '18

The problem is that "All instances" is hard to pin point. We have open world assumption, so instances can be added later (in the dependency tree). Should they be cloned too? And even of you restrict to "instances visible at clonetype definition", that's IMHO not a good idea either, as it's implicit and volatile set (editing imports changes may change the set). So use either tagged-trick/pattern or GND. Haskell's heavy type machinery exists so we can explicitly and exactly say what we need or want. Tagged/phantom-pattern and GND are different, they have different pros & cons. Having `clonetype-fits-all` seems non-trivial to me. Sent from my iPhone > On 24 Sep 2018, at 15.25, Harendra Kumar <harendra.kumar(a)gmail.com> wrote: > > That comes close, but Haskell having such a heavy type machinery to do all the esoteric type stuff in the world, but not allowing you to express such a simple day to day programming thing in a simpler manner is not very satisfying. > > -harendra > >> On Mon, 24 Sep 2018 at 16:16, Oleg Grenrus <oleg.grenrus(a)iki.fi> wrote: >> data MyStringTag >> type MyString = Tagged MyStringTag String >> >> Sent from my iPhone >> >>> On 24 Sep 2018, at 13.42, Harendra Kumar <harendra.kumar(a)gmail.com> wrote: >>> >>> Often, we need to create a newtype that is equivalent to a given type for safety reasons. Using type synonym is useless from type safety perspective. With newtype, we have to add a "deriving" clause to it for deriving the required instances, to make it practically useful. >>> >>> Does it make sense, and is it possible to have something like a "clonetype" that creates a new type and derives all the instances of the parent type as well? It will be quite helpful in creating equivalent newtype synonyms quickly. Almost always, I do not use a newtype where I should just because of the inconvenience of deriving the instances. Ideally, we should just be able to say something like: >>> >>> clonetype MyString = String >>> >>> and we are good to go. What is the shortest possible way to achieve this with currently available mechanisms, if any? >>> >>> -harendra >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post.

7 10

Re: [Haskell-cafe] Is it possible to change the environment (reader) in applicative style?
by Rodrigo Stevaux 25 Sep '18

25 Sep '18

Hi, I found a paper from the Greats exactly about desugaring monads into applicatives: The type of >>= allows the second computation (f b) to depend on the result a of the first, whereas <*> does not. This is the essence of the difference between Monad and Applicative; Monad allows dependencies on previous results, whereas Applicative does not. "Desugaring Haskell’s do-Notation into Applicative Operations" by marlow, SPJ, kmett and mokhov

1 0

clonetype
by Harendra Kumar 24 Sep '18

24 Sep '18

Often, we need to create a newtype that is equivalent to a given type for safety reasons. Using type synonym is useless from type safety perspective. With newtype, we have to add a "deriving" clause to it for deriving the required instances, to make it practically useful. Does it make sense, and is it possible to have something like a "clonetype" that creates a new type and derives all the instances of the parent type as well? It will be quite helpful in creating equivalent newtype synonyms quickly. Almost always, I do not use a newtype where I should just because of the inconvenience of deriving the instances. Ideally, we should just be able to say something like: clonetype MyString = String and we are good to go. What is the shortest possible way to achieve this with currently available mechanisms, if any? -harendra

3 2

ANN: stack-1.9 release candidate
by Emanuel Borsboom 24 Sep '18

24 Sep '18

This is the first release candidate for stack-1.9. Binaries for supported platforms are available here: https://github.com/commercialhaskell/stack/releases/tag/v1.9.0.1 ## Changes since v1.7.1 Release notes: * Statically linked Linux bindists are back again, thanks to [@nh2](https://github.com/nh2). **Please try the `stack-1.9.0.1-linux-x86_64-static.tar.gz` distribution if using Linux**, since it will be the default installed version once v1.9.1 is released. * We will be deleting the Ubuntu, Debian, CentOS, Fedora, and Arch package repos from `download.fpcomplete.com` soon. These have been deprecated for over a year and have not received new releases, but were left in place for compatibility with older scripts. Major changes: * `GHCJS` support is being downgraded to 'experimental'. A warning notifying the user of the experimental status of `GHCJS` will be displayed. Behavior changes: * `ghc-options` from `stack.yaml` are now appended to `ghc-options` from `config.yaml`, whereas before they would be replaced. * `stack build` will now announce when sublibraries of a package are being build, in the same way executables, tests, benchmarks and libraries are announced * `stack sdist` will now announce the destination of the generated tarball, regardless of whether or not it passed the sanity checks * The `--upgrade-cabal` option to `stack setup` has been deprecated. This feature no longer works with GHC 8.2 and later. Furthermore, the reason for this flag originally being implemented was drastically lessened once Stack started using the snapshot's `Cabal` library for custom setups. See: [#4070](https://github.com/commercialhaskell/stack/issues/4070). * With the new namespaced template feature, `stack templates` is no longer able to meaningfully display a list of all templates available. Instead, the command will download and display a [help file](https://github.com/commercialhaskell/stack-templates/blob/master/STAC… with more information on how to discover templates. See: [#4039](https://github.com/commercialhaskell/stack/issues/4039) * Build tools are now handled in a similar way to `cabal-install`. In particular, for legacy `build-tools` fields, we use a hard-coded list of build tools in place of looking up build tool packages in a tool map. This both brings Stack's behavior closer into line with `cabal-install`, avoids some bugs, and opens up some possible optimizations/laziness. See: [#4125](https://github.com/commercialhaskell/stack/issues/4125). * Mustache templating is not applied to large files (over 50kb) to avoid performance degredation. See: [#4133](https://github.com/commercialhaskell/stack/issues/4133). * `stack upload` signs the package by default, as documented. `--no-signature` turns the signing off. [#3739](https://github.com/commercialhaskell/stack/issues/3739) * In case there is a network connectivity issue while trying to download a template, stack will check whether that template had been downloaded before. In that case, the cached version will be used. See [#3850](https://github.com/commercialhaskell/stack/issues/3739). Other enhancements: * On Windows before Windows 10, --color=never is the default on terminals that can support ANSI color codes in output only by emulation * On Windows, recognise a 'mintty' (false) terminal as a terminal, by default * `stack build` issues a warning when `base` is explicitly listed in `extra-deps` of `stack.yaml` * `stack build` suggests trying another GHC version should the build plan end up requiring unattainable `base` version. * A new sub command `run` has been introduced to build and run a specified executable similar to `cabal run`. If no executable is provided as the first argument, it defaults to the first available executable in the project. * `stack build` missing dependency suggestions (on failure to construct a valid build plan because of missing deps) are now printed with their latest cabal file revision hash. See [#4068](https://github.com/commercialhaskell/stack/pull/4068). * Added new `--tar-dir` option to `stack sdist`, that allows to copy the resulting tarball to the specified directory. * Introduced the `--interleaved-output` command line option and `build.interleaved-output` config value which causes multiple concurrent builds to dump to stderr at the same time with a `packagename> ` prefix. See [#3225](https://github.com/commercialhaskell/stack/issues/3225). * The default retry strategy has changed to exponential backoff. This should help with [#3510](https://github.com/commercialhaskell/stack/issues/3510). * `stack new` now allows template names of the form `username/foo` to download from a user other than `commercialstack` on Github, and can be prefixed with the service `github:`, `gitlab:`, or `bitbucket:`. [#4039](https://github.com/commercialhaskell/stack/issues/4039) * Switch to `githash` to include some unmerged bugfixes in `gitrev` Suggestion to add `'allow-newer': true` now shows path to user config file where this flag should be put into [#3685](https://github.com/commercialhaskell/stack/issues/3685) * `stack ghci` now asks which main target to load before doing the build, rather than after * Bump to hpack 0.29.0 * With GHC 8.4 and later, Haddock is given the `--quickjump` flag. * It is possible to specify the Hackage base URL to upload packages to, instead of the default of `https://hackage.haskell.org/`, by using `hackage-base-url` configuration option. * When using Nix, if a specific minor version of GHC is not requested, the latest minor version in the given major branch will be used automatically. Bug fixes: * `stack ghci` now does not invalidate `.o` files on repeated runs, meaning any modules compiled with `-fobject-code` will be cached between ghci runs. See [#4038](https://github.com/commercialhaskell/stack/pull/4038). * `~/.stack/config.yaml` and `stack.yaml` terminating by newline * The previous released caused a regression where some `stderr` from the `ghc-pkg` command showed up in the terminal. This output is now silenced. * A regression in recompilation checking introduced in v1.7.1 has been fixed. See [#4001](https://github.com/commercialhaskell/stack/issues/4001) * `stack ghci` on a package with internal libraries was erroneously looking for a wrong package corresponding to the internal library and failing to load any module. This has been fixed now and changes to the code in the library and the sublibrary are properly tracked. See [#3926](https://github.com/commercialhaskell/stack/issues/3926). * For packages with internal libraries not depended upon, `stack build` used to fail the build process since the internal library was not built but it was tried to be registered. This is now fixed by always building internal libraries. See [#3996](https://github.com/commercialhaskell/stack/issues/3996). * `--no-nix` was not respected under NixOS * Fix a regression which might use a lot of RAM. See [#4027](https://github.com/commercialhaskell/stack/issues/4027). * Order of commandline arguments does not matter anymore. See [#3959](https://github.com/commercialhaskell/stack/issues/3959) * When prompting users about saving their Hackage credentials on upload, flush to stdout before waiting for the response so the prompt actually displays. Also fixes a similar issue with ghci target selection prompt. * If `cabal` is not on PATH, running `stack solver` now prompts the user to run `stack install cabal-install` * `stack build` now succeeds in building packages which contain sublibraries which are dependencies of executables, tests or benchmarks but not of the main library. See [#3787](https://github.com/commercialhaskell/stack/issues/3959). * Sublibraries are now properly considered for coverage reports when the test suite depends on the internal library. Before, stack was erroring when trying to generate the coverage report, see [#4105](https://github.com/commercialhaskell/stack/issues/4105). * Sublibraries are now added to the precompiled cache and recovered from there when the snapshot gets updated. Previously, updating the snapshot when there was a package with a sublibrary in the snapshot resulted in broken builds. This is now fixed, see [#4071](https://github.com/commercialhaskell/stack/issues/4071). * [#4114] Stack pretty prints error messages with proper `error` logging level instead of `warning` now. This also fixes self-executing scripts not piping plan construction errors from runhaskell to terminal (issue #3942). * Fix invalid "While building Setup.hs" when Cabal calls fail. See: [#3934](https://github.com/commercialhaskell/stack/issues/3934) * `stack upload` signs the package by default, as documented. `--no-signature` turns the signing off. [#3739](https://github.com/commercialhaskell/stack/issues/3739)

1 0

ANN: hslua-1.0.0
by Albert Krewinkel 24 Sep '18

24 Sep '18

HsLua provides bindings, wrappers, types, and helper functions to bridge Haskell and the embeddable scripting language Lua. The package ships with a Lua interpreter. HsLua allows to make Haskell programs extensible and scriptable via a widely used language. I am pleased to announce the release of hslua-1.0.0. Changes have been made to most parts of the library: Error handling became simpler, as conversion between Haskell exceptions and Lua errors is now automatic; other improvements concern type-safety, stability, and ease of use. Please see the changelog for the complete list of changes: <https://hackage.haskell.org/package/hslua/changelog> New versions of the extension packages hslua-aeson (marshalling via aeson) and hslua-module-text (a UTF-8 aware string module) have been released as well. For additional information and usage notes: <https://hslua.github.io> Best, - Albert

1 0

Munich Haskell Meeting, 2018-09-24 @ 19:30
by Leah Neukirchen 22 Sep '18

22 Sep '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 24 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.6.1 released
by Herbert Valerio Riedel 22 Sep '18

22 Sep '18

Hello everyone, Here's an addendum to the announcment as it ommitted an important detail: GHC 8.6.1 is only guaranteed to work properly with tooling which uses lib:Cabal version 2.4.0.1 or later. As such, GHC 8.6.1 works best with `cabal-install` 2.4.0.0 or later; please upgrade to `cabal-install` 2.4.0.0 if you haven't already. Note that cabal-install 2.4 supports all GHC versions back till GHC 7.0.4 and we also strongly recommend to use the latest available stable release of `cabal` even with older GHC releases as bugfixes and improvements aren't always backported to older Cabal releases as well as to be able to benefit from recently added CABAL format features[8] (or be able to access package releases on Hackage[9] which rely on those features) which require recent enough versions of Cabal as well. Note that binaries aren't available on cabal's download page[1] yet. If you're on Ubuntu or Debian, you can get a compiled cabal-install 2.4 `.deb` package via Apt from - https://launchpad.net/~hvr/+archive/ubuntu/ghc or - http://downloads.haskell.org/debian/ respectively. Binary versions for macOS and Windows are also expected to become available via [2] and [3] soon (and also at [1]). In the meantime, if you already have GHC 7.10 or later (together with a compatible `cabal` executable) installed, you can easily install cabal 2.4 yourself from Hackage[9] by invoking cabal install cabal-install-2.4.0.0 and making sure that the resulting `cabal` executable is accessible via your $PATH; you can check with `cabal --version` which should emit something along the lines of $ cabal --version cabal-install version 2.4.0.0 compiled using version 2.4.0.1 of the Cabal library Finally, the Haskell Platform[4] release for GHC 8.6.1 should be available soon as well which provides yet another recommended "standard way to get GHC and related tools"[5] in a uniform way across multiple operating systems. See [4] and [5] for more details about the standard Haskell Platform distribution. [1]: https://www.haskell.org/cabal/download.html [2]: https://haskell.futurice.com/ [3]: https://hub.zhox.com/posts/chocolatey-introduction/ [4]: https://www.haskell.org/platform/ [5]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009379.html [6]: https://launchpad.net/~hvr/+archive/ubuntu/ghc [7]: http://downloads.haskell.org/debian/ [8]: https://cabal.readthedocs.io/en/latest/file-format-changelog.html [9]: http://hackage.haskell.org/ -- Herbert On 2018-09-21 at 20:57:02 -0400, Ben Gamari wrote: > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > fourth major release in the GHC 8 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.1 > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > number of exciting features. These most notably include: > > * A new deriving mechanism, `deriving via`, providing a convenient way > for users to extend Haskell's typeclass deriving mechanism > > * Quantified constraints, allowing forall quantification in constraint contexts > > * An early version of the GHCi `:doc` command > > * The `ghc-heap-view` package, allowing introspection into the > structure of GHC's heap > > * Valid hole fit hints, helping the user to find terms to fill typed > holes in their programs > > * The BlockArguments extension, allowing the `$` operator to be omitted > in some unambiguous contexts > > * An exciting new plugin mechanism, source plugins, allowing plugins to > inspect and modify a wide variety of compiler representations. > > * Improved recompilation checking when plugins are used > > * Significantly better handling of macOS linker command size limits, > avoiding linker errors while linking large projects > > * The next phase of the MonadFail proposal, enabling > -XMonadFailDesugaring by default > > A full list of the changes in this release can be found in the > release notes: > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.… > > Perhaps of equal importance, GHC 8.6 is the second major release made > under GHC's accelerated six-month release schedule and the first set of > binary distributions built primarily using our new continuous > integration scheme. While the final 8.6 release is around three weeks > later than initially scheduled due to late-breaking bug reports, we > expect that the 8.8 release schedule shouldn't be affected. > > Thanks to everyone who has contributed to developing, documenting, and > testing this release! > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page https://www.haskell.org/ghc/ > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > Haskell home page https://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug

1 0

Algebraic Effects?
by Viktor Dukhovni 20 Sep '18

20 Sep '18

I picked up Haskell fairly recently, as a "better imperative programming language" to implement highly concurrent code to survey DNSSEC and DANE adoption on the Internet. The results are great, I got a DNS library, network and TLS stack that provide effortless concurrency, and a decent interface to Postgres in the form of the Hasql package and performance is excellent. But I'm still a novice in functional programming, with much to learn. So it is only this week that I've started to read about Algebraic effects, and I curious how the Haskell community views these nowadays. If this is a toxic topic raised by newbies who should just Google past discussions instead, feel free to say so... Does the below thread still sum up the situation: https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we_use_effect_han… I see Haskell now also has an Eff monad. Is it widely used? Efficient? Are there other Haskell libraries that build on it as a foundation? One potential advantage that comes to mind with Effects is that the exceptions raised by a computation can enter its signature and it becomes less likely that a library will leak unexpected exception types from its dependencies to its callers if the expected exceptions are explicit in the signatures and checked by the type system. For example, a while back the Haskell Network.DNS library leaked exceptions from a parser library that was an internal implementation detail, and my code had rare crashes on malformed DNS packets, since I did not expect or handle that exception. -- Viktor.

6 8

Origin of monad transformers (was: Algebraic Effects?)
by Olaf Klinke 20 Sep '18

20 Sep '18

> The only monads with distributive laws are in Data.Distributive, and > they're all isomorphic to (->) e for some e. So that's effectively > ReaderT. That is true for this particular signature of distributive law, and I find this a fascinating result. Especially because there are Haskell terms witnessing this categorical fact. In [1, Theorem 2.4.2] it is stated (as I understand it) that if two monads H and K have a distributive law, then the first is a functor on the Kleisli category of the second while the second is a functor on the Eilenberg-Moore category of the first. In the same paper, Section 4 describes monads on Set (including e.g. trees, bags, Maybe) which distribute over all commutative monads. But maybe one does not need such heavy categorical machinery to describe where monad transformers in Haskell come from. Consider the following. There are at least three kinds of monad transformers t in mtl: (1) t m a = m (t' a) for some monad t' (e.g. ExceptT) (2) t m a = t' (m a) for some monad t' (e.g. ReaderT) (3) t m a = g (m (f a)) for some functors g and f. (e.g. StateT) Only (2) is of the Data.Distributive kind, but all three can be unified under the following scheme: Lemma: If F ⊣ G is an adjunction where F: C → D and G: D → C are functors, and if M: D → D is a monad on D, then G∘M∘F is a monad. Proof: One can factor M through the Kleisli category of M L ⊣ R where L: D → Kleisli(M) and R: Kleisli(M) → D. Since adjoints compose, we have L∘F ⊣ G∘R and G∘R∘L∘F = G∘M∘F. q.e.d. There is another interesting paper [2] showing that for certain class of monads, checking the conditions for a distributive law is easier than the general case. Olaf [1] http://emis.ams.org/journals/TAC/volumes/18/7/18-07.pdf [2] https://doi.org/10.1016/S0022-4049(01)00097-4

1 0

Typeclassopedia for numbers
by Dominik Schrempf 20 Sep '18

20 Sep '18

Hello, the Typeclassopedia[1] lists standard Haskell (algebraic ?) type classes and their relations. I was wondering if a similar construct also exists for numeric type classes (and probably also their instances), since I am always struggling with how, e.g., 'Integral' number are related to 'Fractional' and so on and so forth. Thanks, Dominik [1] https://wiki.haskell.org/Typeclassopedia

2 3

Re: [Haskell-cafe] Parsing LocalTime from Unix seconds
by Olaf Klinke 19 Sep '18

19 Sep '18

Is the result of parsing Unix seconds to LocalTime even well-defined? A LocalTime could be in any time zone, while Unix epoch is relative to a certain time-point in UTC. Hence the parse result must depend on what time zone the LocalTime is referring to. Olaf

6 7

Call for lightning talks and participation -- Haskell Implementors' Workshop
by Joachim Breitner 19 Sep '18

19 Sep '18

Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop Sunday, 23 September, 2018 https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 The Haskell Implementors Workshop is only one week away! Time to look at our great program at https://icfp18.sigplan.org/track/hiw-2018-papers#program and plan your day! Lightning Talks --------------- Like in the previous years, we will have slots for lightning talks. And because they were so successful last year, we will have more! *Topics* Anything related to Haskell implementations, fun uses of Haskell etc. goes. Feel free to tell us about ongoing work, to entertain, to rant, to stir a debate! (If you ever have been to a security or crypto conference, you might have attended their “rump session”. While there will not be alcohol involved at HIW, I hope that we can still match their creativity and insightful fun.) *Rules* * There are 3 sets of 3 lightning talks. * Sign-up is on day of the event, in person, on paper. No prior registration possible. * Lightning talks are 8 mins or less. If you know that your lightning talk takes less time, please say so, and maybe we can put four lightning talks into the slot. * Lightning talks do not count as peer-reviewed publications and are not published in the conference proceedings. Program Committee ----------------- * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (DFINITY / University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact ------- * Joachim Breitner <joachim(a)cis.upenn.edu> -- Joachim Breitner former post-doctoral researcher http://cis.upenn.edu/~joachim

2 1

Algebraic Effects?
by Olaf Klinke 18 Sep '18

18 Sep '18

> Have distributive laws [1] ever been used for monad composition in > Haskell? After all, two monads with a distributive law compose. > > Till There is the distributive package on Hackage, which at least matches the type of the nLab definition. Many common monad transformers stem from monads that are "universally distributive" in the following sense: If t is a monad transformer, then for all other monads m a function with one of the following types can be defined: t Identity (m a) -> m (t Identity a) m (t Identity a) -> t Identity (m a) For which transformers is this the case? For those where t m a is isomorphic to one of the two types t Identity (m a) m (t Identity a) Examples: distr_Reader :: Functor m => m (r -> a) -> r -> m a distr_Reader = \m -> \r -> fmap ($r) m distr_Writer :: Functor m => (w,m a) -> m (w,a) distr_Writer = \(w,m) -> fmap ((,) w) m distr_Either :: Applicative m => Either e (m a) -> m (Either e a) distr_Either (Left e) = pure (Left e) distr_Either (Right m) = fmap Right m distr_Maybe :: Applicative m => Maybe (m a) -> m (Maybe a) distr_Maybe Nothing = pure Nothing distr_Maybe (Just m) = fmap Just m More generally, two monads distribute when one is an endofunctor on the Kleisli category of the other. (The nLab page says Eilenberg-Moore category, I'm not sure whether the two statements are equivalent.) A morphism in the Kleisli category of m is a function a -> m b. An endofunctor f on the Kleisli category must map such a function to a function f a -> m (f b). For example, kleisli_Maybe :: Applicative m => (a -> m b) -> Maybe a -> m (Maybe b) kleisli_Maybe _ Nothing = pure Nothing kleisli_Maybe k (Just a) = fmap Just (k a) kleisli_Reader :: Functor m => (a -> r -> b) -> m a -> r -> m b kleisli_Reader k x r = fmap (flip k r) x Notice that in the former case we used the Kleisli category of m whereas in the latter case we used the Kleisli category of Reader. The more general picture involves an adjunction and the monad m. This covers StateT and the continuation monad. It is well-known that any adjunction F -| G between two categories gives rise to a monad, namely GF. Suppose F:C->D and G:D->C are functors. The adjuntion says that the hom-sets D(Fa,b) and C(a,Gb) are naturally isomorphic. For the state monad, C = Hask (the category of Haskell types and functions) D = Hask, F = (,) s G = (->) s and the isomorphism of hom-sets is currying and uncurrying between (s,a) -> b and a -> (s -> b). In case of the continuation monad Cont r a = (a -> r) -> r, we have C = Hask, D = Hask^op (Hask with direction of arrows reversed) F a = (a -> r) G b = (b -> r) and the isomorphism of hom-sets is between a -> (b -> r) and b -> (a -> r) where the latter is Hask^op(Fa,b). In the case of StateT, since the intermediate category D is Hask, any functor m is an endofunctor on the intermediate category. I do not recall under which conditions the composite GMF is a monad. Olaf

1 0

natural mergesort in Data.List
by Christian Sternagel 18 Sep '18

18 Sep '18

Dear Cafe, some years ago I formalized the mergesort implementation [1] from http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Data.OldList.html… (as far as I can tell it didn't change since 2012) in the proof assistant Isabelle/HOL [2]. More specifically, I proved its functional correctness (the result is sorted and contains all elements of the input with exactly the same multiplicities) and that it is a stable sorting algorithm. Very recently I also formalized a complexity result in Isabelle/HOL, namely that the number of comparisons is bounded from above by n + n * ⌈log 2 n⌉ for lists of length n. For this proof I had to change the definition of "sequences", "ascending", and "descending" slightly. Now here is my question: Does anyone now of reasons why the current implementation of "sequences" is allowed to produce spurious empty lists in its result? The version I used in my formalization only differs in the following three spots: sequences [x] = [[x]] -- this is the only important change, since sequences [] = [] -- then the result does not contain empty lists instead of sequences xs = [xs] and ascending a as [] = let !x = as [a] in [x] instead of ascending a as bs = let !x = as [a] in x : sequences bs and descending a as [] = [a:as] instead of descending a as bs = (a:as) : sequences bs [1] https://www.isa-afp.org/entries/Efficient-Mergesort.html [2] http://isabelle.in.tum.de/

3 6

Get-together at ICFP about Haskell in K-12 education
by Chris Smith 18 Sep '18

18 Sep '18

Hello Haskell community! I've been floating an idea around about hosting a get-together in St. Louis for anyone interested in Haskell at the K-12 (pre-university) level. Some of you know that this has been a big passion of mine for the last 8 years or so. I'd love to discuss with others while a lot of us are in the same place -- whether you're interested in organized teaching, or just teaching your own kids, or just curious about the idea. I've put together this form to collect RSVPs and availability. Interest Form <https://docs.google.com/forms/d/e/1FAIpQLSdJPWIMroEyBuqP15ngmZrp0XwwP-C5uuE…> Thanks, Chris Smith

1 2

CoqPL 2019: Call for Presentations
by Robbert Krebbers 17 Sep '18

17 Sep '18

=================================================================== CoqPL 2019 5th International Workshop on Coq for Programming Languages -- January 19, 2019, co-located with POPL Cascais/Lisbon, Portugal CALL FOR PRESENTATIONS https://popl19.sigplan.org/track/CoqPL-2019 =================================================================== Workshop Overview ----------------- The series of CoqPL workshops provide an opportunity for programming languages researchers to meet and interact with one another and members from the core Coq development team. At the meeting, we will discuss upcoming new features, see talks and demonstrations of exciting current projects, solicit feedback for potential future changes, and generally work to strengthen the vibrant community around our favorite proof assistant. Topics in scope include: - General purpose libraries and tactic language extensions - Domain-specific libraries for programming language formalization and verification - IDEs, profilers, tracers, debuggers, and testing tools - Reports on ongoing proof efforts conducted via (or in the context of) the Coq proof assistant - Experience reports from Coq usage in educational or industrial contexts Workshop Format --------------- The workshop format will be driven by you, members of the community. We will solicit abstracts for talks and proposals for demonstrations and flesh out format details based on responses. We expect the final program to include experiment reports, panel discussions, and invited talks (details TBA). Talks will be selected according to relevance to the workshop, based on the submission of an extended abstract. To foster open discussion of cutting edge research which can later be published in full conference proceedings, we will not publish papers from the workshop. However, presentations will be recorded and the videos made publicly available. Submission details ------------------ Submission page: https://coqpl19.hotcrp.com/ Submission: Monday, October 15, 2018. Notification: Thursday, November 8, 2018. Workshop: Saturday, January 19, 2019 (tentative, date to be confirmed soon). Submissions for talks and demonstrations should be described in an extended abstract, between 1 and 2 pages in length (excluding the bibliography). We suggest formatting the text using the two-column ACM SIGPLAN latex style (9pt font). Templates are available from the ACM SIGPLAN page: http://www.sigplan.org/Resources/Author. Program Committee ----------------- Chairs: - Robbert Krebbers Delft University of Technology, the Netherlands - Ilya Sergey University College London, UK Program Committee: - Olivier Danvy Yale-NUS College, Singapore - Ronghui Gu Columbia University, USA - William Mansky Princeton University, USA - Talia Ringer University of Washington, USA - Gordon Stewart Ohio University, USA - Enrico Tassi Inria, France - Anton Trunov IMDEA Software Institute, Spain - Edwin Westbrook Galois, Inc., USA - Steve Zdancewic University of Pennsylvania, USA

1 0

Parsing LocalTime from Unix seconds
by Marc Busqué 14 Sep '18

14 Sep '18

In GHCi ``` :m +Data.Time parseTimeM True defaultTimeLocale "%s" "1535684406" :: Maybe UTCTime -- => Just 2018-08-31 03:00:06 UTC parseTimeM True defaultTimeLocale "%s" "1535684406" :: Maybe LocalTime -- => Just 1970-01-01 00:00:00 ``` Why? ¯\(°_o)/¯ Marc Busqué http://waiting-for-dev.github.io/about/

2 2

Request for example of putting LaTeX in Haskell code comments for Haddock processing.
by David Banas 13 Sep '18

13 Sep '18

Hi all, Can anyone provide a know working example (GHC 8.4.3) of embedding LaTeX in Haskell source code comments intended for Haddock processing? Both in-line and block, if you’ve got them, would be great. Thanks! -db

5 5