- Haskell-Cafe - Haskell.org

OpenBSD stack executable
by mike thomas 09 Feb '20

09 Feb '20

Hi there. I want to use stack on OpenBSD 6.6. In the absence of an official executable, I've been looking for instructions on how to bootstrap stack *without* a preexisting stack executable, with no luck. I've got GHC 8.6.4, Cabal 2.4.0 and Happy 1.19.5. Any thoughts? Cheers Mike Thomas

2 1

MonadThrow and Either instance
by PICCA Frederic-Emmanuel 08 Feb '20

08 Feb '20

Hello, I try to parse a config file and extract a (Path Abs Dir) from these files So I have a parser as defined in config-ini So I need a function with this signature pathAbsDir :: Text -> Either String (Path Abs Dir) pathAbsDir t = do d <- try $ parseAbsDir (unpack . uncomment $ t) case d of Right v -> Right v Left e -> Left (show e) since I am using parseAbsDir wi this signature parseAbsDir :: MonadThrow m => FilePath -> m (Path Abs Dir) I would like to know how to write the patAbsDir method for now I have this error message src/Hkl/Binoculars/Config.hs:82:8-49: error: • Couldn't match type ‘[Char]’ with ‘GHC.Exception.SomeException’ arising from a use of ‘try’ • In a stmt of a 'do' block: d <- try $ parseAbsDir (unpack . uncomment $ t) In the expression: do d <- try $ parseAbsDir (unpack . uncomment $ t) case d of Right v -> Right v Left e -> Left (show e) In an equation for ‘pathAbsDir’: pathAbsDir t = do d <- try $ parseAbsDir (unpack . uncomment $ t) case d of Right v -> Right v Left e -> Left (show e) | 82 | d <- try $ parseAbsDir (unpack . uncomment $ t) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I understand that the MonadThrow instance of Either is for Either Exception a But I want (Either String a). Cheers Frederic

7 8

Seeking help to generalize this ..
by Debasish Ghosh 07 Feb '20

07 Feb '20

Hi - How can I generalize the following pattern to an arbitrary list of functions ? compose :: (Monad m) => (Foo -> m Foo) -> (Foo -> m Foo) -> (Foo -> m Foo) -> Foo -> m Foo compose f1 f2 f3 acc = do a <- f1 acc b <- f2 a f3 b Any help please .. regards. -- Debasish Ghosh http://manning.com/ghosh2 http://manning.com/ghosh Twttr: @debasishg Blog: http://debasishg.blogspot.com Code: http://github.com/debasishg

6 7

sharing
by Tom Schouten 06 Feb '20

06 Feb '20

Hi, Is there currently a consensus on what is the best way to embed a pure dataflow language while keeping control over value sharing? I have a stream processing language that has a monadic interface (a -> b -> m c) to track variable sharing so it can compile down to C or Verilog, but I would like to create an expression interface layer on top (s a -> s b -> s c) that still allows me to recover the underlying monad representation to implement sharing. I got used to writing in monadic form but I really can't sell this to EEs... Other than a TH or syntax frontend, unsafe tricks, or Conal's compiling to categories which requires a plugin (I believe), is there another way? Cheers, Tom

5 12

Re: [Haskell-cafe] sharing
by Tom Schouten 06 Feb '20

06 Feb '20

(Reply from Sebastiaan Joosten) I've tried something similar before but ran into a lot of cases where verbose intermediate type annotations where necessary to resolve double-wrapping ambiguities because the monad is abstract in my case: xor :: DSL m r => r S -> r S -> m (r S)) Where r is representation wrapper, m is the associated compiler/interpreter, and S is a phantom tag. On 2/5/20 10:05 AM, Sebastiaan Joosten wrote: > Hi Tom, > > It wasn't entirely clear to me what you're looking for, so I'm > probably way off here > >> On 5 Feb 2020, at 08:59, Tom Schouten <tom(a)zwizwa.be >> <mailto:tom@zwizwa.be>> wrote: >> >> asking people to give up expressions while they work just fine in C >> or Verilog > > If all you care about is writing hardware expressions, how about > providing a handful of self-lifting operators? Below is an example of > what I mean (you'd replace the list applicative with your own > applicative). I'm freely combining pureed and unpureed Booleans in the > 'test' example, which would presumably be what your EE's write (I've > only given them a single self-lifting operator, so they're still stuck > writing pretty boring code). Does this help? > > Best, > Sebastiaan > > PS: I'm not replying to haskell-cafe only because my mails bounce > there due to a technical issue that's entirely on my side, feel free > to add this back onto the haskell-cafe thread > > {-# LANGUAGE FlexibleInstances, FlexibleContexts, > MultiParamTypeClasses #-} > class Pureable a b where > maybePure :: a -> b > instance Pureable a [a] where > maybePure = pure > instance Pureable [a] [a] where > maybePure = id > (.&&) :: (Pureable a [Bool], Pureable b [Bool]) > => a -> b -> [Bool] > a .&& b = (&&) <$> maybePure a <*> maybePure b > test :: [Bool] -> [Bool] > test x = (True .&& x) .&& (False .&& x)

2 2

Re: [Haskell-cafe] ListT version leveraging Traversable
by Olaf Klinke 04 Feb '20

04 Feb '20

Dear Juan, Traversables indeed are intimately connected with monad transformers: Two monads are known to commute if one monad (say t) yields a functor on the Kleisli category of the other monad (say m). If you write down what this means for fmap, you get the following type signature: (a -> m b) -> t a -> m (t b) which is the type of mapM and traverse. So does every Traversable monad t yield a monad transformer? Not quite. A functor has to obey the law fmap f.fmap g = fmap (f.g) and this is not given simply by the existence of traverse, you need: traverse f <=< traverse g = traverse (f <=< g). As Li-yao Xia pointed out, it is fairly easy to find a counterexample to <*> = ap for TravListT. But you could of course define <*> = ap and the problem is gone. However, a lawful monad satisfies join . join = join . fmap join and there is a counterexample for TravListT: type M a = TravListT [] a -- [] is not commutative x :: M Int x = TravListT ([[1,2],[3,4]]) -- ((join.join) xxx) /= ((join.fmap join) xxx) xxx :: M (M (M Int)) xxx = let xx = [[x, x],[x]] in TravListT [[TravListT xx,TravListT (reverse xx)]] I have not attempted to make this counterexample minimal, so please forgive the long term. Your claim (3) that [] is the monad of non-determinism is at least not entirely true. Lists modulo ordering and multiplicity are a model of non-determinism. In other words, if Data.Set was a monad then this was your model of non-determinism. Indeed, we have ((sort.runTravListT.join.join) xxx) == ((sort.runTravListT.join.fmap join) xxx) so the counterexample is only a counterexample because the ordering matters for equality. If you're modelling non-determinism, you may safely use the deprecated ListT knowing that the monad laws are violated only due to ordering and multiplicity. Olaf

2 1

ANN:: provenience-0.1.0.0
by Olaf Klinke 04 Feb '20

04 Feb '20

Dear Haskellers, I just uploaded the first release of provenience to hackage [1]. The provenience package contains a monad transformer that lets you automatically track intermediate values and data dependencies in a computation. The philosophy behind it is that computation is done on one machine, while review of the algorithm is done by a third party. We make only minimal assumptions about the third party. Typically, we target static html as documentation format. The resulting data flow graph can be exported as various document formats via Pandoc. If desired, a machine-readable representation of each node is recorded as well. At my company we use provenience to generate invoices paired with Excel files out of the same Haskell application. The provenience Package will be presented at BOB conference [2] in Berlin end of this month. Regards, Olaf [1] https://hackage.haskell.org/package/provenience-0.1.0.0 [2] https://bobkonf.de/2020/klinke.html

1 0

CfP: Haskell Symposium 2020
by Tom Schrijvers 04 Feb '20

04 Feb '20

================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2020 New Jersey, United States 27--28 August, 2020 http://www.haskell.org/haskell-symposium/2020/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2020 will be co-located with the 2020 International Conference on Functional Programming (ICFP). Like last year, we will be using a lightweight double-blind reviewing process. See further information below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2020 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors’ own related work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Early track: Submission deadline: 20 March 2020 (Fri) Notification: 24 April 2020 (Fri) Regular track and demos: Submission deadline: 15 May 2020 (Fri) Notification: 26 June 2020 (Fri) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell20.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Travel Support ============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org) Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permssion-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html) Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available) Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Arthur Azevedo de Amorim Carnegie Mellon University Manuel Chakravarty Tweag I/O / IOHK Jan Christiansen Flensburg University of Applied Sciences Youyou Cong Tokyo Institute of Technology Pierre-Evariste Dagand CNRS Anton Ekblad Chalmers University of Technology Jurriaan Hage Universiteit Utrecht Graham Hutton University of Nottingham José Pedro Magalhães Standard Chartered Clare Martin Oxford Brookes University Andrey Mokhov Jane Street Shin-Cheng Mu Academia Sinica Nikolaos Papaspyrou National Technical University of Athens Simon Peyton Jones Microsoft Research Cambridge Norman Ramsey Tufts University Exequiel Rivas INRIA Tom Schrijvers (chair) KU Leuven Martin Sulzmann Karlsruhe University of Applied Sciences If you have questions, please contact the chair at: tom.schrijvers(a)kuleuven.be<mailto:tom.schrijvers@kuleuven.be> ================================================================================

1 0

ListT version leveraging Traversable
by Juan Casanova 02 Feb '20

02 Feb '20

Hello haskell-cafe, I am going to be stating a series of things about the way I understand some things right now (both theoretical ideas and the general consensus on the Haskell community about some topics). Please feel free to point out to any of these assumptions if you think it is flawed. 1. ListT is deprecated as a Monad Transformer because for some monads it is not a proper transformer. 2. (1) translates literally into the fact that the MonadTrans instace for ListT is unlawful for some monads. 3. The fundamental concept of List as a monad is non-determinism, it is the notion of doing operations on non-deterministic results and generating new non-deterministic results. 4. A "correct" ListT transformer would therefore: 4.1. Be lawful. 4.2. Represent the notion of non-deterministic results tied within the monad they are transforming. 4.3. Be such that when applied to the Identity monad it returns the original List monad. 5. There is no canonical and accepted by the community alternative to ListT which fulfills both points in (4). 6. But there is no proof that (5) is a theoretically necessary thing. I am putting this this way because what I am going to claim now is that I have found one such transformer, that satisfies both points in (4). Therefore, it is very likely that some of my assumptions are flawed. Note that I make no claim that my transformer is unique up to isomorphism. It just seems that what I did does the job, but maybe there are other *fundamentally distinct* ways to fulfill the two points in (4)? Is that maybe the reason why there is no canonical version of ListT? But then why haven't I seen any of those versions, including the one I will present? (By the way, I already see different versions, but which correspond to the same idea just traversing lists in different orders. Permutations of it, so to speak). So, onto what I've done. I am going to be using an example to explain why I think what I did fulfills (4.2). This is not a proof, but I feel that (4.2) is not a formal statement anyway (is there a formal way to express this?). The basic problem I see with implementing ListT correctly is that the non-determinism produces non-deterministic monadic results, and because we wish to keep the non-determinism only to the results and not to the transformed monad itself, there is a need to choose what monadic results we keep. But then, I think, we have a "canonical" way of doing a collection of monadic results: Traversals. And what a wonderful thing that lists are the most natural version of Traversable. Therefore, what I did is to use traverse (and concat, which relies on Foldable which is a superclass of Traversable) to collect the monadic results and produce something that fulfills the type signature that ListT should have. Here's the code. The only really interesting bit is bind: data TravListT m a = TravListT {runTravListT :: m [a]} instance Functor m => Functor (TravListT m) where fmap f (TravListT m) = TravListT (fmap (fmap f) m) instance Applicative m => Applicative (TravListT m) where pure x = TravListT (pure (pure x)) (TravListT fs) <*> (TravListT xs) = TravListT (getCompose ((Compose fs) <*> Compose xs)) instance Monad m => Monad (TravListT m) where return = pure (TravListT ma) >>= f = TravListT (ma >>= (\l -> (concat <$> (traverse (runTravListT . f) l)))) instance MonadTrans TravListT where lift m = TravListT (return <$> m) I also (believe) I have proof that TravListT is a lawful MonadTrans, but I have skipped that here since this is already long enough. If you want to talk about that, we can. This allows me to do the things I would expect of a ListT, such as having a stateful list [1,3,7,11], applying a stateful operation wrapped around a Maybe monad that non-deterministically multiplies and sums each result with the current state with a special case, and increases the state by 1, and produce the stateful, non-deterministic result of doing all of that: let mposns = return [1,3,7,11] :: StateT a Maybe [Int] let tmposns = TravListT mposns let f = \n -> TravListT (StateT (\s -> if (s == n) then Nothing else (Just ([s * n,s + n],s+1)))) let rr = tmposns >>= f runStateT (runTravListT rr) 100 Just ([100,101,303,104,714,109,1133,114],104) runStateT (runTravListT rr) 1 Nothing So I guess my overall question is: why is this not a more standard thing? Are any of my assumptions wrong? Is there something wrong with this monad transformer? Is this really a new idea (I'd be surprised)? Thanks and sorry for the long email, Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 1

Looking-up a TyCon of a type exposed from public module but defined in hidden module
by 石井大海 02 Feb '20

02 Feb '20

Hi cafe, I'm currently writing GHC Type-Checker Plugin [ghc-typelits-presburger], which enhances type-inference involving type-level naturals using Presburger arithmetic. To process constraints properly, I need an access to TyCons of `TrueSym0`, `FalseSym0`, `GTSym0`, etc. from `singletons` package. These types are exposed by public modules, e.g. Data.Singletons.Prelude, but it seems that they are originally defined in private module `Data.Singletons.Prelude.Instances`. I first tried, to retrieve the `TyCon` for `TrueSym0`, the following: ``` insts <- lookupModule (mkModuleName "Data.Singletons.Prelude.Instances") (fsLit "singletons") singTrueSym0 <- tcLookupTyCon =<< lookupOrig insts (mkTcOcc "TrueSym0") ``` But this results in the following compile-time error: ``` ghc: panic! (the 'impossible' happened) (GHC version 8.6.5 for x86_64-apple-darwin): Unable to resolve module looked up by plugin: Data.Singletons.Prelude.Instances Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ``` Then, I tried to lookup `TrueSym0` from exposed module, say Data.Singletons.Prelude: ``` prel <- lookupModule (mkModuleName "Data.Singletons.Prelude") (fsLit "singletons") singTrueSym0 <- tcLookupTyCon =<< lookupOrig prel (mkTcOcc "TrueSym0") ``` But this resulted in the following error: ``` • Can't find interface-file declaration for type constructor or class singletons-2.5.1:Data.Singletons.Prelude.TrueSym0 Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the type signature: ... ``` Is there any way, in GHC API, to lookup symbols exported from public module but originally defined in hidden module? Thanks, [ghc-typelits-presburger]: https://github.com/konn/ghc-typelits-presburger -- Hiromi ISHII konn.jinro(a)gmail.com

2 1