- Haskell-Cafe - Haskell.org

GHC option for performance related output files folder?
by PY 19 Jan '18

19 Jan '18

Hello, All. I made instrumental build which generates profiling information. Cabal's options are: ghc-options: -Wall -O2 -threaded -prof -fprof-auto -rtsopts -fprof-cafs "-with-rtsopts=-N -s -h -i0.1 -p -M1G -SMyApplication-S.log" so running application generates files: /MyApplication-S.log, MyApplication.hp, MyApplication.prof/ but in current working directory - which is the problem (also I need to run it on Windows and Linux). Is it possible to specify directory of those output files with some option? Without this I get "Can't open ... file..." due to permission error - Haskell Runtime tries to save all of them in current folder (on Linux and on Windows standard folders for binaries is not allowed for writing, sure). === Best regards, Paul

1 0

Http client: tlsManagerSettings
by PY 18 Jan '18

18 Jan '18

Hello List! I see that tlsManagerSettings eats > 55Mb. Is it normal? It happens when it reads certificates. So, if it's normal, is it possible that it will consume much-much more on other systems/environments? On what does it depend? === Best regards, Paul

1 0

Versioning of libraries bundled with GHC pre-releases
by Ben Gamari 17 Jan '18

17 Jan '18

TL;DR. We propose to start following the PVP for core libraries shipped with GHC alpha release. Let us know what you think. Hello everyone, GHC has recently been reworking its release policy, increasing the release cadence to two releases per year. We hope that this change facilitates earlier and more thorough testing of GHC. Of course, a compiler is worth little if no real-world packages can be built with it. Historically library maintainers have been reluctant to offer releases claiming compatibility with pre-release GHCs due to the lax versioning guarantees offered by such pre-releases. Specifically, changes to libraries shipped with GHC pre-releases have historically not had proper distinct version numbers, causing unnecessary breakage for released code (e.g. [1]). To make maintainers feel more at ease with releasing libraries compatible with GHC alpha releases, we propose to start using the Package Versioning Policy (PVP) [2] to version GHC's core libraries with each alpha release. That is, libraries which are not source-identical will get at very least a minor bump with each alpha release. By "core libraries" we mean the set of: * base * template-haskell * integer-gmp * integer-simple * hpc * ghci * ghc-compact * all GHC dependencies not maintained by GHC HQ * ghc-prim * ghc-boot * ghc-boot-th Following the PVP will allow maintainers to safely release libraries to Hackage without fear that they will break when the final GHC 8.4.1 release is made, easing the testing process for everyone. If you have an opinion one way or another on this matter please do share it on this list. Cheers, - Ben [1] https://github.com/tibbe/hashable/issues/143 [2] https://pvp.haskell.org/

3 3

ANNOUNCE: servant-pandoc 0.5.0.0
by Ivan Lazar Miljenovic 16 Jan '18

16 Jan '18

I'm pleased to announce the latest release of the servant-pandoc library: https://hackage.haskell.org/package/servant-pandoc-0.5.0.0 servant-pandoc allows you to take the documentation created with servant-docs and use Pandoc to convert it into whichever format you want (rather than the Markdown generated by servant-docs). The main changes in this release are to provide compatibility with servant-docs-0.11.1; specifically, servant-pandoc now emits all the information that servant-docs does with the same configuration options. As such, there are behavioural changes which necessitated the major version bump. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Re: [Haskell-cafe] Non-deterministic function/expression types in Haskell?
by Olaf Klinke 15 Jan '18

15 Jan '18

Long story short: You can stay inside Haskell's type system or extend it, but you end up with monads either way. I'll explain why. > (a) why are monads a perfect solution to my problem? Two reasons. First: Probability distributions do form a monad [Giry,CS,Kock]. It's a mathematical fact. So why not exploit it? It gives you powerful combinators and powerful abstractions. Second: Because the requirements on the type modificators [N] and [D] are describing many features monads have. First observe that you don't really need [D] because any deterministic computation can be embedded into the non-deterministic computations by making the set of possibilities a singleton. That is precisely what 'return' does in the context of monads. (Think of return for the list monad.) > any function that takes a non-deterministic input must have a non-deterministic output. That is common with monads, too: There is no generic function that can extract values out of monads. > we should merge variables with identical values if the types are non-deterministic. That is problematic on several levels. First, is "identical values" decidable by the compiler? Second, equality might depend on the implementation, which might change. For example, (normal 0 1) could contain a random number generator with an intrinsic state. > sample:: (()->a[N]) -> a[N] Observe that, disregarding non-terminating computations, any type t is isomorphic to () -> t. Knowing this, your statement seems to imply that a non-deterministic computation is identified with what you can sample from it. > iid:: Int -> (() -> a[N]) -> [a[N]] The function Control.Monad.sequence plays this role for monads, with a slightly different type signature. Control.Monad.sequence . Data.List.repeat :: Monad m => m a -> m [a] Let the name not deceive you: It is not about sequential computations, rather about ordering the random variables sequentially. > (b) can we extend the HM type system to support non-determinism directly? Yes, you can. But then you have a different language. There many publications describing that [Draheim,Lago,Borgström,RP]. In a nutshell, start with the simply typed lambda calculus and add an operation choose :: I -> a -> a -> a where I is the the type of real numbers 0 <= x <= 1. 'choose' makes a weighted probabilistic choice between its second and third argument. However, in order to describe what programs in (lambda calculus + choose) actually _mean_, you need two things: (1) Define what the compiled program should do at runtime (operational semantics). (2) Define what the program means, mathematically (denotational semantics). For (1), the prevailing approach seems to be to equate a probabilistic term with its behaviour under sampling. Markov Chains are popular [MCMC]. I read it's non-trivial, however, to find a Markov chain that behaves according to a mathematically defined probability distribution. The probability that you know more about that than I do is 1. For (2), the mathematical meaning of ordinary Haskell programs are given via the following mapping. Every Haskell type t is associated with a domain D [DOM] and each Haskell function of type t -> t' is associated with a mathematical function f: D -> D' between the associated domains. Whenever non-determinism is involved, e.g. a probabilistic computation on type t, then instead of D one uses P(D), a suitable "powerdomain". There are various P for various sorts of non-determinism (see the work of Gordon Plotkin), and each of them is a monad on the category of domains. A major problem is whether the P for probabilisitc choice works well with e.g. function types. That is why many papers restrict themselves to first-order functions. Another notoriously hard problem is to combine different sorts of non-determinism. It is like combining monads in Haskell: Some monads have monad transformers associated with them, but some don't. Finally, you might want to play with non-determinism other than the probabilistic one. For example, there is the infinite-search package on hackage, which provides a monad of plain non-deterministic choice beyond finite lists. It is even possible to define a Haskell probability monad in the same spirit. I can provide some code if you wish. Regards, Olaf References [Giry] http://dx.doi.org/10.1007/BFb0092872 [CS] http://dx.doi.org/10.1007/s10485-013-9324-9 [Kock] http://www.tac.mta.ca/tac/volumes/26/4/26-04.pdf [Draheim] http://www.springer.com/de/book/9783642551970 [Lago] https://arxiv.org/abs/1104.0195 [Borgström] https://arxiv.org/abs/1512.08990 [RP] http://www.cs.tufts.edu/~nr/pubs/pmonad.pdf [MCMC] http://okmij.org/ftp/kakuritu/Hakaru10/index.html [DOM] http://www.worldscientific.com/worldscibooks/10.1142/6284

2 2

Non-deterministic function/expression types in Haskell?
by Benjamin Redelings 15 Jan '18

15 Jan '18

Hi, 0. Does anyone know of any simple extensions of the HM type system to non-deterministic functions? The reason that I'm asking is that for probabilistic programming in the lambda calculus, there are two ways of writing expressions: (a) stochastic: let x = sample $ normal 0 1 in x*x or simply (sample $ normal 0 1)^2 (b) "mochastic": do {x <- normal 0 1; return (x*x)} The "mo" in the second one refers to the use of monads. That is the approach taken in the paper "Practical Probabilistic Programming with monads" (http://mlg.eng.cam.ac.uk/pub/pdf/SciGhaGor15.pdf) which I really enjoyed. However, I am interested in the stochastic form here. There are a number of reasons, such as the fact that the monadic representation forces serialization on things that need not be serial. In fact, though, I'm not trying to prove which one is best, I am just interested in exploring the non-monadic approach as well. 1. So, is it possible to do a simple extension to the type system to express non-determinism? I found this paper (Implicit Self-Adjusting Computation for Purely Functional Programs) that uses "level" tags on types to express either (i) security or (ii) changeability. The first idea (for example) is that each type is tagged with one of two "levels", say Public and Secure, so that we actually have Int[Public] or Int[Secure]. Any function that consumes a Secure value must (i) must return a Secure type and (ii) has the arrow in its type labelled with [Secure]. I won't explain the "changeable" idea because its kind of complicated, but I am very interested in it. 2. This is kind of tangential to the point of my question, but to explain the examples below, it might be important to distinguish sampling from a distribution from the distribution itself. So, normal 0 1 won't generate a random sample. Instead, normal 0 1 () will generate a random sample. This allows us to pass (normal 0 1) to another function which applies it multiple times to generate multiple samples from the same distribution. -- sample from a distribution dist sample dist = dist () --- take n samples from a distribution dist iid n dist = take n (map sample $ repeat dist) Here we see some of the value of using the stochastic approach, versus the "mochastic" approach: we can use normal Haskell syntax to handle lists of random values! 3. So, I'm wondering if its possible to extend the HM type system to handle non-determinism in a similar fashion by either (i) having some function types be non-deterministic and/or (ii) having term types be non-deterministic. Taking the second approach, I suggest tagging each type with level [D] (for deterministic) or [N] (for non-deterministic). Notation-wise, if a determinism level is unspecified, then this means (I think) quantifying over determinism levels. A function that samples from the normal distribution we would get a type like: normal:: double -> double -> () -> double[N] Our goal would be that an expression that consumes a non-deterministic expression must itself be non-deterministic, and any function that takes a non-deterministic input must have a non-deterministic output. We could implement that using rules something like this, where {a,b} are type variables and {l1,l2} are level variables. x:a[l1] :: a[l1] \x:a[l1] -> E:b[l2] :: a[l1] -> b[max l1 l2] E[a[l1]->b[l2]] E[a[l]] :: b[l2] The idea is that max l1 l2 would yield N (non-deterministic) if either l1=N or l2=N, because N > D. 4. Putting non-determinism into the type system would affect GHC in a few ways: (a) we shouldn't pull non-deterministic expressions out of lambdas: We should NOT change \x -> let y=sample $ normal 0 1 in y+x into let y = sample $ normal 0 1 in \x -> y+x (b) we should merge variables with identical values if the types are non-deterministic. For example it is OK to change let {x=normal 0 1; y = normal 0 1 in (sample x * sample y)} into let {x=normal 0 1} in sample x However it is NOT OK to change let {x=sample $ normal 0 1; y = sample $ normal 0 1} in x*y into let {x=sample $ normal 0 1} in x*x Perhaps this would be useful in other contexts? 5. If what I've written makes sense, then the types of the functions 'sample' and 'iid' would be: sample:: (()->a[N]) -> a[N] iid:: Int -> (() -> a[N]) -> [a[N]] 6. This is quite a long e-mail, so to summarize, I am interested in whether or not there are any simple systems for putting non-determinism into HM. Is the use of tagged types known NOT to work? Is there are work on this that I should be aware of? Any help much appreciated! :-) take care, -BenRI

9 12

LambdaConf 2018: Call for Proposals
by John A. De Goes 15 Jan '18

15 Jan '18

Dear Haskell Enthusiast: We are pleased to announce the Call for Proposals for LambdaConf 2018 <https://lambdaconf2018.dryfta.com/en/abstract-submission>. LambdaConf is the largest interdisciplinary functional programming conference in the Mountain West, and one of the largest and most well-known functional programming conferences in the world. The conference takes place June 3rd - 5th, in Boulder, Colorado, at the University of Colorado Boulder, and is preceded by commercial training opportunities and followed by a day of third-party mini-conferences on selected topics. If you are an educator, a researcher, a speaker, a speaker coach, or someone aspiring to one of the preceding, then we warmly welcome you to submit a proposal for LambdaConf 2018 <https://lambdaconf2018.dryfta.com/en/abstract-submission>. No prior experience is necessary for most proposals, and we welcome beginner-level content. The Call for Proposals closes at the beginning of February 2018. We recommend submitting as early as you can to ensure sufficient time for editing. LambdaConf attracts everyone from the FP-curious to researchers advancing state-of-the-art; hobbyists, professionals, academics and students. Material at all levels, including beginner content and very advanced content, will find an audience at LambdaConf. Historically, LambdaConf has enjoyed a large selection of sessions on statically-typed functional programming, and a smaller selection of sessions on dynamically-typed functional programming. Some sessions are not tied to specific programming languages, but rather cover topics in abstract algebra, category theory, type theory, programming language theory, functional architecture, and so on, either generally or in a way that applies across many programming languages. LambdaConf looks for sessions in the following areas: Languages. Proposals that overview or dive into specific features of functional, math, or logic programming languages (both new and existing), with the goal of exposing developers to new ideas or helping them master features of languages they already know. Libraries. Proposals that discuss libraries that leverage functional or logic programming to help programmers solve real-world problems. Concepts. Proposals that discuss functional programming idioms, patterns, or abstractions; or concepts from mathematics, logic, and computer science, all directed at helping developers write software that's easier to test, easier to reason about, and easier to change safely. Applications. Proposals that discuss how functional programming can help with specific aspects of modern software development, including scalability, distributed systems, concurrency, data processing, security, performance, correctness, user-interfaces, machine learning, and big data. Use Cases. Proposals that discuss how functional programming enabled a project or team to thrive, or deliver more business value than possible with other approaches. Cherry Picking. Proposals that show how techniques and approaches from functional programming can be adapted and incorporated into mainstream development languages and practices, to the benefit of developers using them. Cautionary Tales. Proposals that call attention to difficulties of functional programming (both as a cautionary tale but also to raise awareness), especially such proposals that suggest alternatives or a path forward. Efficacy. Proposals that present data, measurements, or analysis that suggests different techniques, paradigms, languages, libraries, concepts, or approaches have different efficacies for given specified metrics, which provide actionable takeaways to practicing functional and logic programmers. Off-Topic. Proposals that have appeal to a mainstream developer audience (the number of off-topic proposals we accept is small, but we do accept some, especially for keynotes). LambdaConf accepts proposals for the following types of sessions: Leap Workshops (6h). Leap Workshops are approximately 6 hours in length. They are in-depth, hands-on workshops designed to teach mainstream functional programming topics in enough detail, attendees can immediately apply what they learn in their jobs. We require that speakers follow our recommended format for Leap Workshops, although we allow exceptions for experienced teachers. Hop Workshops (2h). Hop Workshops are 2 hours in length. Like Leap Workshops, these workshops are in-depth and hands-on, but they cover reduced content and may be specialized to topics that may not have mainstream appeal. We require that speakers follow our recommended format for Hop Workshops, although we allow exceptions for experienced teachers. De Novo Sessions (50m). De Novo Sessions are 50 minutes in length. These sessions are designed to present original work from industry and academia. While the requirements for proposals are more rigorous, there is less competition for De Novo slots. Educational Sessions (50m). Educational Sessions are 50 minutes in length. These sessions are designed to clearly and concisely teach one useful concept, skill, aspect, library, or language to attendees. Inspire Talks (5m). Inspire talks are 5 minutes in length and focus on clear communication of a single takeaway. These sessions are intended to inspire attendees to learn more about particular subjects or to try new approaches, and must follow Ignite-style, which consists of 20 slides, each auto-advancing after 15 seconds. Keynotes (40m). Keynotes are 40 minutes in length, and are presented before all attendees (there are no other sessions concurrent with keynotes). Keynotes are designed to offer thought-provoking, opinionated, and insightful commentary on topics of interest to the community. Level of reimbursement varies based on the type of proposal you are selected for: Leap Workshops (6 hours). Speakers for Leap Workshops receive a free ticket, a speaker gift, a speaker dinner, up to 4 days accommodations, full travel reimbursement, and a small honorarium. Hop Workshops (2 hours) / Educational (50m) / De Novo (50m) / Keynote (50m). Speakers for Hop Workshops, Educational, De Novo, and Keynote receive a free ticket, a speaker gift, a speaker dinner, and up to 4 days accommodations. Speakers may also request travel assistance, which is dealt out based on availability and need, and which may cover up to $250 for domestic travel, and $500 for international travel. Inspire (5m). As Inspire talks are only 5 minutes in length, Inspire speakers receive a speaker gift and a speaker dinner, but must purchase a ticket and pay for travel and accommodations on their own. If you are accepted for a specific type of proposal (e.g. Educational), we cannot guarantee that you will get a slot of this type. Based on scheduling requirements, feedback from the committee, or feedback from your speaker coach, we may require you to change the format of your session. You may submit as many proposals as you like, though we recommend spending more time refining fewer proposals, since the quality of your proposals has a significant effect on their chances of acceptance by the blind committee. If you wish to maximize your chances of having a proposal accepted, we also recommend spreading 2-3 proposals across multiple categories, because some categories are fiercely competitive, while others are less competitive. For more information, please see the Call for Proposals website <https://lambdaconf2018.dryfta.com/en/abstract-submission>. Regards, -- John A. De Goes john(a)degoes.net Follow me on Twitter @jdegoes

2 2

How to improve the running time of my algorithm
by Dominik Bollmann 14 Jan '18

14 Jan '18

Hello Haskell-Cafe, While playing with dynamic programming problems, I've been trying to solve the "Abbreviation" problem found on hackerrank.com at https://www.hackerrank.com/challenges/abbr/problem. Briefly, this problem asks to decide whether a source string s can be abbreviated into a target string t by capitalizing some of the characters in s and deleting its afterwards remaining lowercase characters. For example, the string s = "aBbdD" can be abbreviated as target t = "BBD", but target t' = "XYZZ" is not an abbreviation for source s' = "xyz". My solution to this problem is the following memoization-based function `isAbbreviation`: ``` import Control.Monad import Control.Monad.State import Data.Char import Data.Map.Strict (Map) import qualified Data.Map.Strict as Map import Data.Maybe import Data.String import Data.Text (Text) import qualified Data.Text as Text import System.IO type Store = Map (Text, Text) Bool isAbbrMemo :: Text -> Text -> State Store Bool isAbbrMemo s t | Text.null t = extend s t $ return (Text.all isLower s) | Text.null s = extend s t $ return False | otherwise = let (a, as) = fromJust $ Text.uncons s (b, bs) = fromJust $ Text.uncons t in extend s t $ matches a as b bs where matches a as b bs | isLower a && toUpper a /= b = isAbbrMemo as (b `Text.cons` bs) | isLower a && toUpper a == b = (||) <$> isAbbrMemo as bs <*> isAbbrMemo as (b `Text.cons` bs) | isUpper a && a /= b = return False | isUpper a && a == b = isAbbrMemo as bs extend :: Text -> Text -> State Store Bool -> State Store Bool extend s t m = do st <- get case Map.lookup (s,t) st of Just v -> return v Nothing -> do v <- m modify $ Map.insert (s,t) v return v isAbbreviation :: Text -> Text -> Bool isAbbreviation s t = evalState (isAbbrMemo s t) Map.empty main :: IO () main = do queries <- readQueries stdin let answers = map yesNo $ map (uncurry isAbbreviation) queries forM_ answers putStrLn yesNo :: Bool -> String yesNo True = "YES" yesNo False = "NO" readQueries :: IsString a => Handle -> IO [(a, a)] readQueries h = do numQueries <- read <$> hGetLine h :: IO Int forM [1..numQueries] $ \_qid -> do s <- hGetLine h t <- hGetLine h return (fromString s, fromString t) ``` However, running `isAbbreviation` on Hackerrank's input #13 still takes around 38 seconds on my machine and is therefore too slow to be an accepted solution. The input of question is attached as a text file. My question is therefore: Where could I further improve the running time of the function `isAbbreviation`? Is there any low-hanging fruit to improve upon? Or is my dynamic-programming based approach somehow flawed in general? (in which I should rather rethink the problem?) Any observations, remarks, and improvements on the above code snippet are greatly appreciated :-) Thanks, Dominik.

2 1

ANN: shelltestrunner 1.9 - Easy, repeatable testing of CLI programs/commands
by Simon Michael 14 Jan '18

14 Jan '18

I'm pleased to announce a new release of shelltestrunner! shelltestrunner (executable: shelltest) is a portable command-line tool for testing command-line programs, or general shell commands, released under GPLv3+. It reads simple test specifications defining a command to run, some input, and the expected output, stderr, and exit status. It can run tests in parallel, selectively, with a timeout, in color, etc. Projects using it include hledger, Agda, and berp. The last release was 1.3.5, in 2015. The new version is 1.9, which has substantial improvements and is recommended for all users. More real-world testing and contributions will help us deliver 2.0. New in 1.9 (2018/1/14): * two new test file formats, allowing input re-use and lighter syntax * new -l/--list flag lists the tests found * new -D/--defmacro option allows text substitution (Taavi Valjaots) * new --xmlout option saves test results as xml (Taavi Valjaots) * tests with Windows line endings now also work on unix (Taavi Valjaots) * shelltestrunner's tests should now pass on Windows (Taavi Valjaots) * flags formerly passed through to test-framework are now built in * >>>= with nothing after it now matches any exit status * failure messages now show the test command (John Chee) * include shelltestrunner's tests in cabal sdist archive (Iustin Pop) * build with latest deps and stackage resolvers * shelltestrunner's code and home page have moved to github Thanks to release contributors Taavi Valjaots, Andrés Sicard-Ramírez, Iustin Pop and John Chee. Install: $ stack install shelltestrunner-1.9 or: $ cabal update && cabal install shelltestrunner-1.9 Home, docs: https://github.com/simonmichael/shelltestrunner <https://github.com/simonmichael/shelltestrunner>

1 0

Fails to `stack exec` a Yesod app
by Yotam Ohad 13 Jan '18

13 Jan '18

Hi, I have the following project (https://github.com/yohad/TheMafsidan) 'stack build` works with no errors but when I try to run it I get App: static: getDirectoryContents:openDirStream: does not exist (No such file or directory) Anyone has a clue on how to fix this? Yotam

3 2

Internships at Microsoft Research Cambridge
by Simon Peyton Jones 11 Jan '18

11 Jan '18

Happy New Year! Would anyone like to come to Microsoft Research Cambridge for an internship? For the first time, this year we have put together a list of all the open internship slots<https://www.microsoft.com/en-us/research/opportunity/internships-msr-cambri…>, with brief descriptions and closing dates. This is in part due to our efforts to reach more people, and attract a broader, more diverse range of applicants. There are lots of projects on that page, but I'd like to highlight one group in particular. I'm personally involved in a project with four intern slots, in which we are using insights from functional programming got improve the experience of using spreadsheets - the world's most widely used functional programming languages. This focus on end-user programming means that we need interns with wide interests and skills. More details are below (copy/pasted from the web page). The application deadline is 31 January 2018. (NB: other slots have other deadlines.) Thanks Simon Functional programming and spreadsheets Supervisors: Simon Peyton Jones<https://www.microsoft.com/en-us/research/people/simonpj/>, Andy Gordon<https://www.microsoft.com/en-us/research/people/adg/>, Claudio Russo<https://www.microsoft.com/en-us/research/people/crusso/>, Neil Toronto, Advait Sarkar<https://www.microsoft.com/en-us/research/people/advait/> Start Date: June/July 2018 Applications close January 31 2018 Reference #: MSRC226 We hope to hire four interns during 2018 with a focus on using insights from functional programming to improve the experience of using spreadsheets. The exact internship project will be chosen to fit the expertise of successful applicants, but we are interested in a broad range of areas including: * Improving the experience of authoring formulae in a spreadsheet * Compiling spreadsheets for faster execution * Using insights from type systems to catch programming errors sooner * Generalisation and program synthesis * Demonstrating radical improvements in the range of applications that can be tackled with spreadsheets. We are looking for three interns with programming-language expertise, and one with a strong background in HCI and user experience. You would be working with leaders in both functional programming (Andy Gordon, Simon Peyton Jones) and user experience (Advait Sarkar, Kenton O'Hara). There is a genuine possibility that your work could have real-world impact. By way of general background, you may want to read Simon Peyton Jones et al's papers "A user-centred approach to functions in Excel<https://dl.acm.org/citation.cfm?id=944721>" and "Champagne Prototyping: A Research Technique for Early Evaluation of Complex End-User Programming Systems<http://ieeexplore.ieee.org/document/1372297/#full-text-section>".

2 1

ANN: network-2.6.3.3
by evan＠evan-borden.com 10 Jan '18

10 Jan '18

Announcing network-2.6.3.3 * Add a function to show the defaultHints without reading their undefined fields [#291](https://github.com/haskell/network/pull/292) * Improve exception error messages for getAddrInfo and getNameInfo [#289](https://github.com/haskell/network/pull/289) * Deprecating SockAddrCan. As always a huge thank you to the network contributors.

1 0

Re: [Haskell-cafe] Getting some funny brackets in Haddock docs
by Johannes Waldmann 10 Jan '18

10 Jan '18

OverloadedLists solves this, in a way? Prelude> :set -XOverloadedLists Prelude> import qualified Data.Map.Strict as M Prelude M> M.size [(2,3)] 1 because of the IsList instance https://hackage.haskell.org/package/containers-0.5.10.2/docs/src/Data.Map.I… Do we want to use this in code examples in the docs? Equivalently, is it recommended to use this notation in actual code? The problem I see is that this (and similar) extensions will be active for all literals in a module - while we only want it for literals of some specific type. I know this is handled in the parser, and we don't know the types at this point. - J

4 4

Getting some funny brackets in Haddock docs
by David Feuer 10 Jan '18

10 Jan '18

The containers Haddock documentation currently represents sequences, sets, and maps via the relevant `fromList` function. For example, Data.Map gives the example findWithDefault 'x' 1 (fromList [(5,'a'), (3,'b')]) == 'x' I find these `fromList` calls exceedingly distracting, and I think they obscure the key ideas. Of course, I *could* just specify at the top that the documentation assumes OverloadedLists, but I think that's likely to be somewhat confusing, especially to beginners. My preference would really be to represent these data structures using funny brackets of some sort. Perhaps ⟦7,34,12⟧ for a sequence, ⦃40,3⦄ for a set, and ⟪(12,"alpha"), (14,"bravo")⟫ for a map. But there are three problems: 1. How can I insert the brackets conveniently? I definitely don't want to fill the module with Unicode. My preference would be to use \{ and \} or \[ and \] and have them get replaced by the left and right brackets appropriate to the module in question. But I don't actually know how to do that. 2. Funny brackets could presumably cause trouble for people who don't have appropriate fonts available. How could I mitigate this? 3. This whole idea could cause trouble for people who want to copy and paste examples from the documentation. Are people likely to want to do that? If so, how might I mitigate that problem? Are there tricks I can play to make copy/paste turn a funny left bracket into `fromList [` and a funny right bracket into `]`, and also not break things for non-HTML backends? Thanks, David

4 3

Re: [Haskell-cafe] Package takeover: re2
by Andrey Sverdlichenko 09 Jan '18

09 Jan '18

Thanks! On Mon, Jan 8, 2018 at 11:20 PM John Millikin <john(a)john-millikin.com> wrote: > Just added you to the maintainer's list. Sorry for the delayed response, > I've been away from reliable internet for a few weeks. > > When you upload the next version, please also update the contact info to > yours. I'll say on my site that you're the new maintainer. > > On Mon, Jan 8, 2018 at 9:54 AM, Andrey Sverdlichenko <blaze(a)ruddy.ru> > wrote: > >> I'd like to take over maintenance of the package re2. It is built >> against old version of re2 library, never updated after 2014 and listed as >> "deprecated" on the author's website. I rather update this one than add >> another package for the same bindings. >> >> I tried to contact owner a week ago, but to no avail. My hackage username >> is blaze. >> > >

1 0

looking for deep learning explanation a la Lämmel's map-reduce paper
by Johannes Waldmann 08 Jan '18

08 Jan '18

Dear Cafe, I like this paper (R. Lämmel in SCP 2008) very much https://userpages.uni-koblenz.de/~laemmel/MapReduce/ both for contents and for style - and I wonder if there's something similar ("Haskell for design recovery", "rigorous description", "executable specification") on deep learning. Mainly for understanding/teaching without all the hype. (But of course, an accelerate-* implementation would be nice.) Yes I know that hyperbole *is* the main thing in this area. Happy New Year - J.

2 2

Package takeover: re2
by Andrey Sverdlichenko 08 Jan '18

08 Jan '18

I'd like to take over maintenance of the package re2. It is built against old version of re2 library, never updated after 2014 and listed as "deprecated" on the author's website. I rather update this one than add another package for the same bindings. I tried to contact owner a week ago, but to no avail. My hackage username is blaze.

1 0

Syntax highlight for numeric literals
by Takenobu Tani 07 Jan '18

07 Jan '18

Dear cafe, I wrote and pushed a bit about the syntax highlights of numeric literals for `BinaryLiterals`, `HexFloatLiterals` and `NumericUnderscores` extensions on editors. https://github.com/takenobu-hs/haskell-numeric-highlight I'm glad if this helps you. Regards, Takenobu

2 2

PSA: `cabal update` command needs manual unsticking
by Gershom B 05 Jan '18

05 Jan '18

Dear Haskellers, A recent update to hackage, which fixed up the 01-index.tar.gz file, revealed a bug in existing versions of cabal-install, when index files are cleaned up. This bug means that the `cabal update` command, which updates the hackage index file, will fail silently and leave the old file in place. It is easy to get things working again, but it requires manual intervention. Here is the most straightforward way to get things working again: On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.* On windows: remove the same files, but from %appdata%\cabal\packages\hackage.haskell.org rerun `cabal update` to fetch a new 01-index. Apologies all for the inconvenience and any confusion this may have caused. There is a PR to fix this behavior in the works, but since the problem is on the client side, the fix will only improve the situations for new versions of `cabal`. Happy New Years to all, and cheers to a very functional 2018, Gershom p.s.: since the problem comes in unpacking the 01-index.tar.gz into the 01-index.tar, you can also just untar that file in place manually, or force cabal into doing the same by running `touch ~/.cabal/packages/hackage.haskell.org/01-index.tar`

6 5

How does the RTS pin ByteArray# objects during FFI calls?
by Reiner Pope 03 Jan '18

03 Jan '18

Hi Haskell-Cafe, I understand from https://mail.haskell.org/pipermail/haskell-cafe/2014-June/114763.html that it is safe to pass ByteArray# objects to FFI calls, using the UnliftedFFITypes language extension. As I understand it, the implicit guarantee is that the RTS will pin the ByteArray#'s address in memory for the duration of the FFI call -- even if the ByteArray# wasn't allocated pinned. I'm curious: how does the RTS achieve this "retroactive" pinning? The documentation at https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned suggests that *all* ByteArrays are allocated pinned to account for the possibility that they will in future be passed to the FFI. Is this really the case? This seems like it forces an unreasonably slow allocator on small (say, ~10-byte) ByteArray allocations where the GC's usual bump-pointer allocator might otherwise be preferable. Regards, Reiner

2 2

ANN: capataz-0.0.0.1 - An OTP-like supervisor library for Haskell
by Román González 02 Jan '18

02 Jan '18

Hello, I'm glad to share the release of a new library for supervising Haskell threads inspired in OTP/Akka called capataz * Hackage: http://hackage.haskell.org/package/capataz * Github: https://github.com/roman/Haskell-capataz * Documentation/Tutorials: https://romanandreg.gitbooks.io/capataz/content/ capataz enhances the reliability of your concurrent applications by offering supervision of threads that run in your application. Advantages over standard libraries: * Links related long-living processes together under a common capataz supervisor, with restart/shutdown order. * Set restart strategies (Permanent, Transient, Temporary) on `IO` sub-routines on a granular level * Set restart strategies on a pool of long-living worker threads (AllForOne, OneForOne) * Complete telemetry on your supervised threads lifecycle (start, error, restarts, shutdown) * Drop-in replacement of forkIO invocations Please feel free to reach out if you are curious and have any ideas/improvements. Cheers. Roman.-

1 0

Shadowing record field names
by ☂Josh Chia (謝任中) 01 Jan '18

01 Jan '18

Quite often, I need to use record types like this: data Whole1 = Whole1 { part :: Part, ... } data Whole2 = Whole2 { part :: Part, ... } Where Whole1 & Whole2 are types of things that have a Part and some other things. E.g. a Book has an Author, a Title, etc and so does an Article. The problem is that I'm not actually allowed to use the same name (author/part) in two different record types. Some people use lens to solve this. You can have a lens called 'author' for dealing with the Author in both Book and Article (e.g. using makeClassy). That's fine, but there's yet another problem. Let's say I have a function that takes an Author and a [Library] and returns all the Libraries that have Books or Articles matching the Author. So: findAuthorLibraries :: Author -> [Library] -> [Library] findAuthorLibraries author libraries = ... But I already have a lens called 'author' and ghc will complain about shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of 'author' for the function argument? Or, should I name the lens 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with 'the' is quite unreadable because whether or not an argument has that prefix depends on whether there's a lens with a conflicting name so it adds noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems quite an overbearing eyesore because for consistency I would have to use the prefix for all my field-accessing lenses. Maybe I should use Lens.Control.TH.makeClassy and then define: findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library] findAuthorLibraries hasAuthor libraries = ... But that may be making my function more complicated and general than I want, affecting readability, simplicity, compilation time and maybe even performance. In summary, I find that there are ways around the problem but they really affect readability. I could also disable the warning about shadowing but that seems pretty dangerous. It may be OK to disable the warning for the specific cases where a function argument shadows something from the topmost scope, but GHC does not allow such selective disabling of that warning. In a code base that deals mainly with concrete business logic, this problem probably crops up more than in a code base that deals mainly with more abstract things. What do people do to address this problem? Any recommendations or best practices? Josh

7 10

ANN: hledger 1.5
by Simon Michael 31 Dec '17

31 Dec '17

Happy New Year all! I'm very pleased to announce hledger 1.5. hledger (http://hledger.org) is a reliable, cross-platform program for tracking money, time or other commodities, using double-entry accounting and simple plain text file formats. It provides command-line, curses and web interfaces, and aims to be a pleasant and practical tool for personal, business or institutional use. A big thank you to the release contributors: Dmitry Astapov, Mykola Orliuk, Eli Flanagan, Elijah Caine, Sam Jeeves, Matthias Kauer, Hans-Peter Deifel, Mick Dekkers, Nadrieril, Alvaro Fernando García. In 2017, four quarter-end releases were shipped on schedule, and our feature set, marketing reach and contributor activity continue to grow. The next release is scheduled for 2018/03/31. New users and contributors are always welcome! Give feedback, report bugs, send pull requests, write about it, etc. And if you have been finding hledger useful, consider becoming a sponsor or donor to help to sustain and accelerate our progress (see home page). Our IRC channel is #hledger on Freenode (http://irc.hledger.org) What's new ? ------------ Some highlights from the release notes at http://hledger.org/release-notes#hledger-1.5 : * Ledger-style automated posting rules to modify transactions, enabled with --auto flag * Ledger-style periodic transaction rules to generate forecast transactions (--forecast) and budget goals * a new budget report (balance --budget) comparing amounts with per-period and per-account budget goals * more expressive period expressions * space can be used as digit group separator character in numbers * commodity or default commodity directives give more control over display precision and decimal point/digit group separator Get started ----------- See http://hledger.org/download for all install methods. Windows users can download nightly binaries. On other platforms, you may need to build the latest release yourself. The easiest and most reliable way is to run the hledger install script. This requires only bash and will install the hledger tools in $HOME/.local/bin/. (It uses an installed cabal or stack if possible, otherwise installs stack and GHC in $HOME/.local/bin and $HOME/.stack/). Here's the responsible way to run it: $ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… $ less hledger-install.sh # (do security review) $ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run) or the more convenient, less secure way: $ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… | bash or, to install individual tools: $ stack install hledger-1.5 # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc. or: $ cabal update $ cabal install hledger-1.5 # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc. Note: building haskell apps can take significant time, memory, and disk space, especially the first time. You can kill and restart the installer without losing progress. If it fails, please help us improve it by reporting the full output. After installation, ensure $HOME/.local/bin is in your $PATH. Now try some commands: $ hledger -h # quick help $ hledger help # list built-in manuals $ hledger add # record some transactions $ hledger # list available commands Now perhaps work through the tutorial at http://hledger.org/step-by-step.html Or review the fine documents, presentations etc. at http://hledger.org and http://plaintextaccounting.org Or say hello and ask questions in the #hledger IRC channel on Freenode: http://irc.hledger.org Wishing you a highly prosperous and serene 2018, -Simon Happy New Year all! I'm very pleased to announce hledger 1.5. hledger (http://hledger.org) is a reliable, cross-platform program for tracking money, time or other commodities, using double-entry accounting and simple plain text file formats. It provides command-line, curses and web interfaces, and aims to be a pleasant and practical tool for personal, business or institutional use. A big thank you to the release contributors: Dmitry Astapov, Mykola Orliuk, Eli Flanagan, Elijah Caine, Sam Jeeves, Matthias Kauer, Hans-Peter Deifel, Mick Dekkers, Nadrieril, Alvaro Fernando García. In 2017, four quarter-end releases were shipped on schedule, and our feature set, marketing reach and contributor activity continue to grow. The next release is scheduled for 2018/03/31. New users and contributors are always welcome! Give feedback, report bugs, send pull requests, write about it, etc. And if you have been finding hledger useful, consider becoming a sponsor or donor to help to sustain and accelerate our progress (see home page). Our IRC channel is #hledger on Freenode (http://irc.hledger.org) What's new ? ------------ Some highlights from the release notes at http://hledger.org/release-notes#hledger-1.5 : * Ledger-style automated posting rules to modify transactions, enabled with --auto flag * Ledger-style periodic transaction rules to generate forecast transactions (--forecast) and budget goals * a new budget report (balance --budget) comparing amounts with per-period and per-account budget goals * more expressive period expressions * space can be used as digit group separator character in numbers * commodity or default commodity directives give more control over display precision and decimal point/digit group separator Get started ----------- See http://hledger.org/download for all install methods. Windows users can download nightly binaries. On other platforms, you may need to build the latest release yourself. The easiest and most reliable way is to run the hledger install script. This requires only bash and will install the hledger tools in $HOME/.local/bin/. (It uses an installed cabal or stack if possible, otherwise installs stack and GHC in $HOME/.local/bin and $HOME/.stack/). Here's the responsible way to run it: $ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… $ less hledger-install.sh # (do security review) $ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run) or the more convenient, less secure way: $ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… | bash or, to install individual tools: $ stack install hledger-1.5 # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc. or: $ cabal update $ cabal install hledger-1.5 # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc. Note: building haskell apps can take significant time, memory, and disk space, especially the first time. You can kill and restart the installer without losing progress. If it fails, please help us improve it by reporting the full output. After installation, ensure $HOME/.local/bin is in your $PATH. Now try some commands: $ hledger -h # quick help $ hledger help # list built-in manuals $ hledger add # record some transactions $ hledger # list available commands Now perhaps work through the tutorial at http://hledger.org/step-by-step.html Or review the fine documents, presentations etc. at http://hledger.org and http://plaintextaccounting.org Or say hello and ask questions in the #hledger IRC channel on Freenode: http://irc.hledger.org Wishing you a highly prosperous and serene 2018, -Simon

1 0

singToList
by Dmitry Olshansky 31 Dec '17

31 Dec '17

Hello cafe, Does a function like `singToList` exist somewhere: singToList :: Sing (xs :: [k]) -> [SomeSing k] singToList = \case SNil -> [] SCons x xs -> SomeSing x : singToList xs ?

2 2

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
by Emanuel Borsboom 31 Dec '17

31 Dec '17

Hi Ben, Are there any plans to start releasing Linux bindists linked with libncurses.so.6? A number of Linux distributions have upgraded from 5, including Fedora, Arch and Gentoo, and the currently available official bindists don't work out of the box on those anymore. -- Manny

2 1

Question about ST arrays
by Jean-Marc Alliot 29 Dec '17

29 Dec '17

Hi, This is my first post to this list so I apologize in advance if I don't use it properly, or if my question is too simple or inapropriate. I come from the Caml world and I am quite new to Haskell (but not to functional programming). I am currently trying to get the hang of Haskell arrays. I have gone through regular arrays, IO Arrays and I am now working with ST Arrays. This is the problem I am currently stuck with. I write the following code: arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int) get :: Int -> Int get i = runST (arr >>= (\b -> readArray b i)) Here everything is perfectly OK. Now I want a more general version that could deal with any array like arr. So I write: get2 :: ST s (STArray s Int Int) -> Int -> Int get2 tab i = runST (tab >>= (\b -> readArray b i)) And the compiler is clearly very upset by my code: Couldn't match type ‘s’ with ‘s1’ ‘s’ is a rigid type variable bound by the type signature for: get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int at testst.hs:17:9 ‘s1’ is a rigid type variable bound by a type expected by the context: forall s1. ST s1 Int at testst.hs:18:14 Expected type: ST s1 Int Actual type: ST s Int I am pretty sure that the compiler is right and I am wrong, but I don't get why... Anyone could help? Thanks

5 8

[Call for Project Ideas] Haskell.org Google Summer of Code 2018
by Jasper Van der Jeugt 25 Dec '17

25 Dec '17

Google Summer of Code will take place again in 2018 [1]. Last year, Haskell.org was not selected, and we decided to run our own program [2], which ended very successfully [3]. This year, we would like to apply to Google Summer of Code again, since their sponsorship is very significant. The main feedback we received from Google last year was that we didn't really have a great homepage for Summer of Code with ideas for students (things were very rushed and we ended up submitting a link to an outdated bug tracker -- not ideal!). We already started fixing that last year by building a nicer webpage to host ideas [4]. We would now like to call on the community to submit ideas for the students. If you are the maintainer or the user of a Haskell project, and you have an improvement in mind which a student could work on during the summer, please submit an idea here: https://summer.haskell.org/ideas.html Or contact Niki Vazou (nvazou [AT] cs.umd.edu) or myself (m [AT] jaspervdj.be) directly. For context, Google Summer of Code is a program where Google sponsors students to work on open-source projects during the summer. Haskell.org has taken part in this program from 2006 until 2015. Many important improvements to the ecosystem have been the direct or indirect result of Google Summer of Code projects, and it has also connected new people with the existing community. Projects should benefit as many people as possible -- e.g. an improvement to GHC will benefit more people than an update to a specific library or tool, but both are definitely valid. New libraries and applications written in Haskell, rather than improvements to existing ones, are also accepted. Projects should be concrete and small enough in scope such that they can be finished by a student in three months. Best, Niki Vazou & Jasper Van der Jeugt for the Haskell.org Committee [1]: https://opensource.googleblog.com/2017/09/announcing-google-summer-of-code-… [2]: https://summer.haskell.org/news/2017-02-28-2017-announce.html [3]: https://summer.haskell.org/news/2017-09-15-final-results.html [4]: https://summer.haskell.org/ideas.html

1 0

Trouble building happy/alex with Stack lts-9.20
by Eric McCorkle 25 Dec '17

25 Dec '17

Hi folks, I'm trying to update my language project to happy >= 9.16, so I can use typeclass-based parsers. Unfortunately, I'm running into build errors after switching to lts-9.20. The log file is attached. I see similar problems when trying to build alex (the lexer generator). It seems to be claiming that there is no cabal file, which is odd, as there clearly is one (in the source at least). Has anyone else seen this problem, and if so, what is the workaround?

3 4

Supporting Haskell.org
by Tikhon Jelvis 25 Dec '17

25 Dec '17

A significant part of the Haskell community infrastructure—including the haskell.org website, Hackage, Hoogle and the build infrastructure for GHC—runs on donations from the Haskell community administered by haskell.org . You can donate right now using several methods including PayPal and check: https://wiki.haskell.org/Donate_to_Haskell.org Haskell.org can also accept donations through employers via Benevity using the unique ID 475236502. As Haskell.org is a 501(c)(3) non-profit, donations are tax-deductible. This year marked the second Haskell Summer of Code program which provided grants for 15 students working on open source Haskell projects over the summer. The projects improved Haskell tooling and libraries as well as supporting Haskell education through improvements to code.world. A detailed retrospective can be found on summer.haskell.org: https://summer.haskell.org/news/2017-09-15-final-results.html With look forward to continuing this work with your support in 2018 as well as exploring new projects to improve the Haskell community infrastructure. Best wishes, Tikhon Jelvis on behalf of the haskell.org committee.

2 1

ANN: progress-meter 1.0.0
by esz＠posteo.de 25 Dec '17

25 Dec '17

Hi everybody, I have just released a complete API rewrite of the `progress-meter` package: * <https://hackage.haskell.org/package/progress-meter> * <https://github.com/esoeylemez/progress-meter> With this package you can easily add live diagnostics to any long-running application from a simple progress bar to full task monitoring. The `System.Progress` module contains a tutorial. Features: * update progress from multiple threads, * non-progress diagnostics that just scroll by (e.g. logging), * breaking the state apart for individual threads, so they can update their relevant portion of the progress bar without interfering with each other ("zooming"), * smart throttling (no updates drawn when nothing is happening, and only ever drawn at a maximum rate). Here is a very simple example: import Control.Concurrent import System.Progress main = withProgress_ "" id $ \pm -> do -- Set the progress bar: setMeter pm "Working..." -- Do some "work": threadDelay 3000000 -- Print something while temporarily hiding the progress bar: putMsgLn pm "Some extra diagnostics that scrolls by" setMeter pm "Almost done..." threadDelay 1000000 putMsgLn pm "Done." The first argument of 'withProgress_' is the initial state and the second is a renderer for the current state: render :: Int -> String render p = "Progress: " ++ show p ++ "%" withProgress_ 0 render $ \pm -> do threadDelay 1000000 setMeter pm 10 threadDelay 8900000 setMeter pm 99 -- The famous last percent: threadDelay 10000000 putMsgLn pm "Done." Progress-meter will do The Right Thing when you update the state or produce log messages from multiple threads. Happy holidays ertes

1 0

Hackage / Stackage Idea
by alex＠centromere.net 23 Dec '17

23 Dec '17

Hi all, I use Haskell in production, and when choosing a library I wonder, "Is this package production-ready?". In addition to evaluating the quality of the code, I consider various factors such as the most recent upload date, number of downloads, the age of the last commit, the author's reputation, the number of packages which depend on that package, and the number of issues open and closed. I think it would be interesting to add a feature to Hackage and/or Stackage which allows companies to advertise that they use a package in production. If they elect to be anonymous, only the count would increase. I believe that this data would not only help inform my library choices, but also help communicate Haskell's merits to industry. What do you all think? Alex

2 1

Code runs 7x FASTER with profiling
by Neil Mayhew 23 Dec '17

23 Dec '17

I was writing a simple utility and I decided to use regexps to parse filenames. (I know, now I have two problems :-) ) I was surprised at how slow it ran, so I did a profiling build. The profiled code runs reasonably quickly, and is 7x faster, which makes it a bit hard to figure out where the slowdown is happening in the non-profiled code. I’m wondering if I’m doing something wrong, or if there’s a bug in |regex-tdfa| or in ghc. I’ve pared my code down to just the following: |import Text.Regex.TDFA ((=~)) main :: IO () main = do entries <- map parseFilename . lines <$> getContents let check (Right (_, t)) = last t == 'Z' check _ = False print $ all check entries parseFilename :: String -> Either String (String, String) parseFilename fn = case (fn =~ pattern :: [[String]]) of [[_, full, _, time]] -> Right $ (full, time) _ -> Left fn where pattern = "^\\./duplicity-(full|inc|new)(-signatures)?\\.\ \([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\." | The relevant part of my |.cabal| file looks like this: |executable DuplicityAnalyzer main-is: DuplicityAnalyzer.hs build-depends: base >=4.6 && <4.11, regex-tdfa >= 1.0 && <1.3 default-language: Haskell2010 ghc-options: -Wall -rtsopts | To run the profiling, I do: |cabal clean cabal configure --enable-profiling cabal build dist/build/DuplicityAnalyzer/DuplicityAnalyzer <names.in +RTS -sprofiling-summary.out -p | The |MUT| time in the non-profiling build is 7x bigger, and the |%GC| time goes from 8% to 21%. I’ve put the actual output in a gist <https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5>. I’ve also put my test input file there, in case anyone wants to try this themselves. I’ve done my testing with NixOS (ghc 8.0.2) and Debian with the Haskell Platform (ghc 8.2.1) and the results are basically the same. I even tried using Docker containers with Debian Jessie and Debian Stretch, just to eliminate any OS influence, and the results are still the same. I’ve tried it on an i5-2500K, i5-3317U and Xeon E5-1620. I also wrote a dummy implementation of |=~| that ignores the regex pattern and does a hard-coded manual parse, and that produces times just slightly better than the profiled ones. So I don’t think there’s a problem in my outer code that uses |=~|.

5 11

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 22 Dec '17

22 Dec '17

George Colpitts <george.colpitts(a)gmail.com> writes: > Probably stating what is obvious and well-know but anyways: > > - On the status page > <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1> it would be > good to have a link for "Phase 2 of the Semigroup-Monoid Proposal (Herbert > Riedel)" Good catch. I've added a link. > - Also IIRC we normally have a page on porting to the new release. It > would be good to have that also when we have a chance. > Indeed, the migration page can be found here: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4. I've added a link to the 8.4 status page. Cheers, - Ben

1 0

Happy National Mathematics Day
by Henk-Jan van Tuyl 22 Dec '17

22 Dec '17

L.S., Happy National Mathematics Day to everyone in India! Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
by Oleg Grenrus 21 Dec '17

21 Dec '17

I copy & paste Hervert's reddit answer here [1], for ones who don't follow it: As the suffix "alpha" implies, this is a very bleeding edge release with very little guarantees regarding API stability (c.f. new GHC schedule [2] <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedu…>). Put differently, a package that works now with GHC 8.4.1-alpha1 may not necessarily work with the final GHC 8.4.1 release. In order to support early adopters in testing GHC 8.4.1-alpha, there's a new Overlay Hackage Package Index <https://github.com/hvr/head.hackage> [3] which provides packages patched for unreleased GHCs (currently GHC 8.4.1-alpha1 & GHC 8.5/HEAD). See its README <https://github.com/hvr/head.hackage#README> [4] for instructions on how to use it; there's also a shell script included which automates common workflows; finally there's also support for HEAD.hackage in themake-travis-yml Travis CI script generator <https://github.com/haskell-hvr/multi-ghc-travis>. [5] Don't hesitate to ask if you have questions! As usual, there's already an (incomplete & work-in-progress) GHC 8.4.x Migration Guide <https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4> [6] you can consult and maybe even help complete. Links: - [1]: https://www.reddit.com/r/haskell/comments/7l4b19/announce_ghc_841alpha1_ava… - [2]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedu… - [3]: https://github.com/hvr/head.hackage - [4]: https://github.com/hvr/head.hackage#README - [5]: https://github.com/haskell-hvr/multi-ghc-travis - [6]: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4 Cheers, Oleg On 21.12.2017 22:16, George Colpitts wrote: > Thanks Ben. I installed the Mac binaries. > > For others who are wondering, you need llvm 5 if you want to use llvm > with this. > > Needless to say, many libraries, e.g. haskell-src-exts, primitive, and > intero won't compile with this even with --allow-newer > > I'll notify those libraries about that in case they want to get > started on 8.4.1 > > Cheers > George > > On Wed, Dec 20, 2017 at 4:48 PM Ben Gamari <ben(a)well-typed.com > <mailto:ben@well-typed.com>> wrote: > > > The GHC development team is pleased to announce the first alpha > release > of the 8.4.1 release. The usual release artifacts are available from > > https://downloads.haskell.org/~ghc/8.4.1-alpha1 > <https://downloads.haskell.org/%7Eghc/8.4.1-alpha1> > > Note that this release drops compatibility with GCC 4.6 and earlier. > While we generally try to place as few constraints on system toolchain > as possible, this release depends upon the __atomic__ builtins > provided > by GCC 4.7 and later (see #14244). > > > === Notes on release scheduling === > > The 8.4.1 release marks the first release where GHC will be > adhering to > its new, higher-cadence release schedule [1]. Under this new scheme, > major releases will be made in 6-month intervals with interstitial > minor > releases as necessary. > > In order to minimize the likelihood of schedule slippage and to ensure > adequate testing, each major release will be preceeded by a number of > regular alpha releases. We will begin issuing these releases roughly > three months before the final date of the major release and will issue > roughly one every two weeks during this period. This high release > cadence will allow us to quickly get fixes in to users hands and allow > better feedback on the status of the release. > > GHC 8.4 is slated to be released in mid-February but, due to technical > constraints, we are starting the alpha-release cycle a bit later than > planned under the above schedule. For this reason, it would be greatly > appreciated if users could put this alpha through its paces to make up > for lost time. > > As always, do let us know if you encounter any trouble in the > course of > testing. Thanks for your help! > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > <mailto:Glasgow-haskell-users@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

Call for Papers: PACMPL issue ICFP 2018
by Lindsey Kuper 21 Dec '17

21 Dec '17

PACMPL issue ICFP 2018 Call for Papers accepted papers to be invited for presentation at The 23rd ACM SIGPLAN International Conference on Functional Programming St. Louis, Missouri, USA http://icfp18.sigplan.org/ ### Important dates Submissions due: 16 March 2018 (Friday) Anywhere on Earth https://icfp18.hotcrp.com Author response: 2 May (Wednesday) - 4 May (Friday) 14:00 UTC Notification: 18 May (Friday) Final copy due: 22 June (Friday) Conference: 24 September (Monday) - 26 September (Wednesday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL <https://pacmpl.acm.org/>) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope PACMPL issue ICFP 2018 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * *Language Design*: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * *Implementation*: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * *Software-Development Techniques*: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * *Analysis and Transformation*: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * *Applications*: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * *Education*: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2018 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such at the time of submission and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is Friday, March 16, 2018, Anywhere on Earth (<https://en.wikipedia.org/wiki/Anywhere_on_Earth>). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from <http://sigplan.org/Resources/Author/#acmart-format>. There is a limit of 27 pages for a full paper or 14 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. These page limits have been chosen to allow essentially the same amount of content with the new single-column format as was possible with the two-column format used in past ICFP conferences. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. **Submission**: Submissions will be accepted at <https://icfp18.hotcrp.com/> Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on Wednesday, May 2, 2018, to read reviews and respond to them. **Supplementary Materials**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at <https://www.acm.org/publications/authors/information-for-authors>. **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at <http://www.sigplan.org/Resources/Policies/Republication>. **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. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2018. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2018 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on May 18, 2018. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After five weeks (June 22, 2018), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within five weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. **PACMPL issue ICFP 2018 will employ 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 judgement 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. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limits for final versions of papers will be increased to ensure that authors have space to respond to reviewer comments and mandatory revisions. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: copyright transfer to ACM; retaining copyright but granting ACM exclusive publication rights; or open access on payment of a fee. Further information about ACM author rights is available from <http://authors.acm.org>. * At least one author of each accepted submissions will be expected to attend and present their paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. * We intend that the proceedings will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit <http://www.acm.org/publications/acm-author-izer-service> to learn how to create links for free downloads from the ACM DL. * The official publication date 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. ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by a committee, separate from the program committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the proceedings, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. Further information about the motivations and expectations for Artifact Evaluation can be found at <https://icfp18.sigplan.org/track/icfp-2018-Artifacts>. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works — or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words "Experience Report" followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better off submitted it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Robby Findler (Northwestern University, USA) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Ryan R. Newton (Indiana University, USA) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Matthew Fluet (Rochester Institute of Technology, USA) Publicity and Web Chair: Lindsey Kuper (Intel Labs, USA) Student Research Competition Chair: Ilya Sergey (University College London, UK) Video Co-Chairs: Jose Calderon (Galois, Inc., USA) Nicolas Wu (University of Bristol, UK) Workshops Co-Chair: David Christiansen (Indiana University, USA) Christophe Scholliers (Universiteit Gent, Belgium) ### PACMPL issue ICFP 2018 Principal Editor: Matthew Flatt (Univesity of Utah, USA) Review Committee: Sandrine Blazy (IRISA, University of Rennes 1, France) David Christiansen (Indiana University, USA) Martin Elsman (University of Copenhagen, Denmark) Marco Gaboardi (University at Buffalo, CUNY, USA) Sam Lindley (University of Edinburgh, UK) Heather Miller (Northweastern University, USA / EPFL, Switzerland) J. Garrett Morris (University of Kansas, USA) Henrik Nilsson (University of Nottingham, UK) François Pottier (Inria, France) Alejandro Russo (Chalmers University of Technology, Sweden) Ilya Sergey (University College London, UK) Michael Sperber (Active Group GmbH, Germany) Wouter Swierstra (Utrecht University, UK) Éric Tanter (University of Chile, Chile) Katsuhiro Ueno (Tohoku University, Japan) Niki Vazou (University of Maryland, USA) Jeremy Yallop (University of Cambridge, UK) External Review Committee: Michael D. Adams (University of Utah, USA) Amal Ahmed (Northeastern University, USA) Nada Amin (University of Cambridge, USA) Zena Ariola (University of Oregon) Lars Bergstrom (Mozilla Research) Lars Birkedal (Aarhus University, Denmark) Edwin Brady ( University of St. Andrews, UK) William Byrd (University of Alabama at Birmingham, USA) Giuseppe Castagna (CRNS / University of Paris Diderot, France) Sheng Chen (University of Louisiana at Lafayette, USA) Koen Claessen (Chalmers University ot Technology, Sweden) Ugo Dal Lago (University of Bologna, Italy / Inria, France) David Darais (University of Vermont, USA) Joshua Dunfield (Queen’s University, Canada) Richard Eisenberg (Bryn Mawr College, USA) Matthew Fluet (Rochester Institute of Technology, USA) Nate Foster (Cornell University, USA) Jurriaan Hage (Utrecht University, Netherlands) David Van Horn (University of Maryland, USA) Zhenjiang Hu (National Institute of Informatics, Japan) Suresh Jagannathan (Purdue University, USA) Simon Peyton Jones (Microsoft Research, UK) Naoki Kobayashi (University of Tokyo, Japan) Neelakantan Krishnaswami (University of Cambridge, UK) Kazutaka Matsuda (Tohoku University, Japan) Trevor McDonell (University of New South Wales, Australia) Hernan Melgratti (University of Buenos Aires, Argentina) Akimasa Morihata (University of Tokyo, Japan) Aleksandar Nanevski (IMDEA Software Institute, Spain) Kim Nguyễn (University of Paris-Sud, France) Cosmin Oancea (DIKU, University of Copenhagen, Denmark) Bruno C. d. S. Oliveira (University of Hong Kong, China) Tomas Petricek (University of Cambridge, UK) Benjamin Pierce (University of Pennsylvania, USA) Christine Rizkallah (University of Pennsylvania, USA) Tom Schrijvers (KU Leuven, Belgium) Manuel Serrano (Inria, France) Jeremy Siek (Indiana University, USA) Josef Svenningsson (Chalmers University of Technology, Sweden) Nicolas Tabareau (Inria, France) Dimitrios Vytiniotis (Microsoft Research, UK) Philip Wadler (University of Edinburgh, UK) Meng Wang (University of Kent, UK)

1 0

Re: [Haskell-cafe] Are bottoms ever natural?
by Alexey Muranov 20 Dec '17

20 Dec '17

Siddharth, how would you deal with functions that terminate for some arguments/inputs but do not terminate for the others ? Alexey. On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote: > > Is that really true, though? > > Usually when you have an infinite loop, you have progress of some > > sort. Infinite loops with no side effects can be removed from the > > program according to the C standard, for example. So, in general, we > > should allow programmers to express termination / progress, right? > At > > that point, no computation ever "bottoms out"? > > Shouldn't a hypothetical purely functional programming language > > better control this (by eg. Forcing totality?) It seems like we lose > > much of the benefits of purity by muddying the waters with > > divergence. > > From an optimising compiler perspective, Haskell is on some weird > > lose-lose space, where you lose out on traditional compiler > > techniques that work on strict code, but it also does not allow the > > awesome stuff you could do with "pure" computation because bottom > > lurks everywhere. > > What neat optimisations can be done on Haskell that can't be done in > > a traditional imperative language? I genuinely want to know. > > What are your thoughts on this? > > Cheers > > Siddharth > > > > On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b(a)gmail.com> > > wrote: >> > > Define "natural". >> > > >> > > You might want to look into the concept of Turing completeness. >> One >> > > could define a subset of Haskell in which bottoms cannot occur... >> > > but it turns out there's a lot of useful things you can't do in >> > > such a language. (In strict languages, these often are expressed >> as >> > > infinite loops of one kind or another. Note also that any >> > > dependency on external input is an infinite loop from the >> > > perspective of the language, since it can only be broken by the >> > > external entity providing the input.) >> > > >> > > On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat >> <siddharth.b >> > > hat(a)research.iiit.ac.in> wrote: >>> > > > I've been thinking about the issue of purity and speculation >>> > > > lately, and from what little I have read, it looks like the >>> > > > presence of bottom hiding inside a lazy value is a huge issue. >>> > > > >>> > > > How "natural" is it for bottoms to exist? If one were to >>> change >>> > > > Haskell and declare that any haskell value can be speculated >>> > > > upon, what ramifications does this have? >>> > > > >>> > > > Is it totally broken? Is it "correct" but makes programming >>> > > > unpleasant? What's the catch? >>> > > > >>> > > > Thanks, >>> > > > Siddharth

7 6

Are bottoms ever natural?
by (IIIT) Siddharth Bhat 20 Dec '17

20 Dec '17

I've been thinking about the issue of purity and speculation lately, and from what little I have read, it looks like the presence of bottom hiding inside a lazy value is a huge issue. How "natural" is it for bottoms to exist? If one were to change Haskell and declare that any haskell value can be speculated upon, what ramifications does this have? Is it totally broken? Is it "correct" but makes programming unpleasant? What's the catch? Thanks, Siddharth -- Sending this from my phone, please excuse any typos!

4 6

Re: [Haskell-cafe] Are bottoms ever natural?
by Alexey Muranov 19 Dec '17

19 Dec '17

Siddharth, are you aware that the question whether a given element belongs to the domain of a given computable function is algorithmically undecidable? Alexey. On Tue, 2017-12-19 at 16:51 +0000, Siddharth Bhat wrote: > > So, I have two opinions to share on this: > > Regarding the plane example, it is wrong to attempt to graph it on a > > plane, precisely because the domain is not the plane. > > I am confused by your assertion that it is impossible to avoid > > divergence in mathematics: we do not define division as a *partial* > > function. Rather we define it as a *total* function on a *restricted > > domain*. > > So, what one would need is the ability to create these restricted > > domains, which certain languages have as far as I am aware. > > At that point, now that we track our domains and codomains > correctly, > > all should work out? > > I would still like an answer to interesting transformations that are > > enabled by having purity and laziness and are not encumbered by the > > presence of bottoms. > > Cheers, > > Siddharth > >

1 0

Writing an interpreter for a language with mutability
by Jeremy Mikkola 19 Dec '17

19 Dec '17

I am quite certain I am not the first to try to do this, but my google-fu is failing me today. How does one go about interpreting a language with mutable objects in Haskell? The best approach I can think of is to represent the language's memory as a `Data.Map.Map RefID LanguageObject` where RefID is some type (probably Int) used as a reference. The LanguageObject structure might contain some values of type RefID to refer to other objects. Mutating an object involves simply replacing the value in the map at a given RefID. I don't like this approach for two reasons: 1. Map lookups aren't very efficient compared with actual references to the value. 2. I have to re-invent garbage collection, removing objects from the map when they no longer have incoming references. (Unlike simple interpreters for languages with immutable values, I can't rely on Haskell's garbage collector to do the work for me.) Is there a better approach? - Jeremy

6 6

Cybersecurity Posts (2) at the University of Sheffield
by Achim D. Brucker 19 Dec '17

19 Dec '17

(Apologies for duplicates - resending after I forgot to attach the body of the mail ...) Dear all, As part of an ambitious strategy for growth, the Department of Computer Science is seeking to appoint two Lecturers/Senior Lecturers/Readers with outstanding expertise in the field of cybersecurity. Computer and information security is a rapidly growing interest at Sheffield. In the Department of Computer Science we have recently established a Security of Advanced Systems group, led by Professor John Clark. There is related expertise in other departments such as Law, Mathematics and Statistics, and Politics. Furthermore, Sheffiield’s strength in engineering brings many opportunities for collaborative research in cybersecurity, in areas such as robotics and advanced manufacturing. To drive our research agenda in cybersecurity forward, we are now seeking to make two appointments at Lecturer, Senior Lecturer or Reader Level. Candidates will demonstrate an excellent research record in cybersecurity. Suitable areas of expertise include (but are not limited to): security policies, threat modelling, authentication, access control, malware and malware detection, network security, secure protocols, intrusion detection, and human factors and security. Candidates who work at the interface of artificial intelligence and cybersecurity are particularly encouraged to apply. In 2016 we were recognised for our work on diversity and equality with a Silver Athena Swan award. Interested candidates may find details of these (and other) posts at: https://www.sheffield.ac.uk/dcs/jobs/index Best, Achim -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Cybersecurity Posts (2) at the University of Sheffield
by Achim D. Brucker 19 Dec '17

19 Dec '17

(Apologies for duplicates) -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

coercing D a to D b
by Evan Laforge 19 Dec '17

19 Dec '17

Given: data D a = A a | B Int Char dmapNoCoerce :: (a -> b) -> D a -> D b dmapNoCoerce f (A a) = A (f a) dmapNoCoerce _ (B i c) = B i c I have to reconstruct a B change it from D a to D b. But at the lower level, couldn't this be implemented as a type cast? What prevents such an optimization? I can write this as dmapCoerce :: (a -> b) -> D a -> D b dmapCoerce f (A a) = A (f a) dmapCoerce _ b@(B {}) = Unsafe.Coerce.unsafeCoerce b >From the core, it looks like dmapCoerce indeed has a cast with no allocation, while dmapNoCoerce allocates a new B. It seems to work, but is it safe? Is there a more principled way to do it? I can't convince Data.Coerce to cooperate, presumably because 'a' and 'b' are not coercible themselves, and it doesn't believe me if I try to tell it the type role is phantom.

3 4

error terminated list
by Evan Laforge 18 Dec '17

18 Dec '17

I've been using this lately to represent a process which can fail but still produce data: data UntilFail err a = a :+ UntilFail err a | Done | Fail err I know there's been discussion of this type before, but I don't remember what it was called and I can't find the right search terms to turn it up. Ring any bells? I have some awkward names for it, but maybe someone else thought of something more elegant. I have some ad-hoc functions for it: mapUntilFail :: (a -> Either err b) -> UntilFail err a -> UntilFail err b concatMapUntilFail :: (a -> UntilFail err b) -> UntilFail err a -> UntilFail err b -- | Like 'concatMapUntilFail', but consume a variable number of results. -- -- A more precise type would end with @Done [a]@. processUntilFail :: (a -> [a] -> (UntilFail err b, [a])) -> [a] -> UntilFail err b Maybe someone who has thought more deeply about it has come up with more elegant abstractions.

1 0

Haskell IDE Engine logo poll
by Damien Flament 18 Dec '17

18 Dec '17

Hi ! The final poll is available featuring all logos submitted until last Friday. Please vote for your favourite*s* here: http://freeonlinesurveys.com/p/Cw1FRJ2G?qid=1017541 Thanks. Damien.

1 0

The Definition of Haskell
by Todd Wilson 18 Dec '17

18 Dec '17

Why doesn't Haskell (or at least "core" Haskell) have a formal definition and safety result the way Standard ML does [1], [2]? Is it just that no one has gotten around to producing them, or because there are fundamental difficulties that stand in the way of completing such a project? Todd Wilson [1] Robin Milner, Mads Tofte, Robert Harper, and David MacQueen. The Definition of Standard ML (Revised). MIT Press, 1997. [2] Daniel K. Lee , Karl Crary , Robert Harper, "Mechanizing the Metatheory of Standard ML", http://www.cs.cmu.edu/~dklee/tslf/

8 9

Managing package release workflow
by Clinton Mead 18 Dec '17

18 Dec '17

Hi All I've already got a few packages on hackage <https://hackage.haskell.org/user/clinton>, but I'd like to upload a few more, but I'm finding the workflow management particularly excessive. Here's what I'd like to do roughly: 1. Choose a number of stack snapshots I'd like my package to successfully build and test against. 2. Automatically apply appropriate version bounds to dependencies in my cabal file based on those snapshots. 3. When these changes are pushed to Github, attempt to compile them using Travis CI, against all the stack snapshots chosen. 4. If we do a push to a particular branch or with particular tag, this signifies we're attempting a release. Attempt to compile using Travis CI, perform the tests. If the compile and tests are successful, push a separate commit, adjust the "source-repository" field in github to point to that release commit (not to master) and upload to hackage. I'm currently doing all of this manually but it's increasingly a bit of a pain. Is there tooling to help me automate this? Thanks, Clinton

2 1

Who can send a patche to vim project?
by Takenobu Tani 18 Dec '17

18 Dec '17

Hi cafe, Who can send a patche to vim project? I'd like to update vim syntax file (haskell.vim) to fix numeric literals. I read the vim `CONTRIBUTING.md` file [1]. It instructs me to contact the maintainer of each files. In the header of `haskell.vim`, the maintainor of `haskell.vim` is haskell-cafe@ML. [2] Who is the maintainer of `haskell.vim`? I'd like to make fix on numeric literals extension: [3] * BinaryLiterals * HexFloatLiterals * NumericUnderscores I prepared two kinds of patches. * Exact pattern version [4] * Fast (but approximate) pattern version [5] I visually checked patches with the these files [6][7]. Could you send a patch of [4] or [5] to vim project? P.S. I have already sent patches to two projects. * `language-haskell` for atom and linguist [8] You can already use it on atom. Linghist (which is used from github) will apply it soon. * `pygments` [9] It is pending review. [1]: https://github.com/vim/vim/blob/master/CONTRIBUTING.md#syntax-indent-and-ot… [2]: https://github.com/vim/vim/blob/master/runtime/syntax/haskell.vim#L3 [3]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009-n… [4]: https://github.com/vim/vim/compare/master...takenobu-hs:syntax-haskell-lite… [5]: https://github.com/vim/vim/compare/master...takenobu-hs:syntax-haskell-lite… [6]: https://github.com/takenobu-hs/ghc/blob/squashed-numeric-underscores/testsu… [7]: https://github.com/takenobu-hs/ghc/blob/squashed-numeric-underscores/testsu… [8]: https://github.com/atom-haskell/language-haskell/commit/f90eb7d8662493536f5… [9]: https://bitbucket.org/birkenfeld/pygments-main/issues/1399/update-haskell-w… Regards, Takenobu

1 2

Is Haskell the best programming language?
by Henning Thielemann 15 Dec '17

15 Dec '17

I just got to know that there is a card game (code quartett) that lets players find out what language is the best: http://codequartett.de/index-en.html :-)

2 1

Announce: Haskell Platform 8.2.2
by Gershom B 14 Dec '17

14 Dec '17

On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.2.2 Now available at https://www.haskell.org/platform/ This includes GHC 8.2.2, cabal-install 2.0.0.1, and stack 1.6.1, all with many bugfixes since the last platform release. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. There are currently no 32 bit Windows builds available. We expect to have those out in short order. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.2-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.0.0.1/changelog The cabal documentation page is at: https://www.haskell.org/cabal/users-guide/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/ The stack documentation page is at: https://docs.haskellstack.org/en/stable/README/ Happy Haskell Hacking all, Gershom

1 0