- Haskell-Cafe - Haskell.org

FRP: how does integration work?
by martin 20 Jan '18

20 Jan '18

Hello all, I am at best half-educated when it comes to FRP, so feel free to direct me to the homework I should do before asking obvious questions. I vaguely remember Paul Hudak talking about integrating a Signal (aka Behavior). Now I have this image in my head, where a Behavior is like vector graphics, except its domain Time and not space. Also I heard the term "late sampling" in conjunction with FRP. Bot ideas make sense to me. So if I look at integration in vector graphics, I might want to get the area between a curve and the x-axis. If I render the curve and then count the pixels between the curve and x-axis, the result will depend on the resolution. With a very low resolution, I'll get a crude approximation of the true area and as I increase the resolution I'll get better approximations and with infinite resolution I'll get the true area. So the result of integration seems to depend on the chosen resolution. Conversely, with pixel graphics, the resolution is fixed right from the start and I cannot not up the resolution at all, at best I could downsample. In FRP I should have something like: newtype Behavior a = Behavior (Time -> a) type Curve = Behavior Double integral :: Curve -> Double -> Curve -- 2nd parameter is the integration constant But what do I get when I take the value of the integral at a given point in time? integralAt :: Time -> Curve -> Double integralAt t curve = let (Behaviour i) = integral curve 0 in i t Nowhere do I mention any (temporal) resolution. How does the integral function know which resoltion to choose?

1 0

Adding packages from within ghci session
by Simon Hafner 20 Jan '18

20 Jan '18

Hello I've been exploring some code via ghci, and I've found myself in this loop: - write some code - figure out I need another package (e.g. mtl for runReaderT) - add package to cabal specification - reload stack ghci - Ctrl+R all the statements to replay the session so far Is there a way to speed up the loop, e.g. via loading packages directly from ghci or saving/replaying a session? Cheers, Simon

3 3

Created haskell-indexer-users mailing list
by Robin Palotai 20 Jan '18

20 Jan '18

Hello Cafe, I created https://groups.google.com/forum/#!forum/haskell-indexer-users, please join if you use / interested in using haskell-indexer [1]! Quoting Section 4.5.5 of the latest HCAR [2], > > Haskell Indexer is a Kythe extension for working with Haskell source code. > Kythe is language-agnostic ecosystem for building tools that work with > code. An example is code search with cross-reference support: > https://cs.chromium.org/. Haskell Indexer makes it possible to use > Kythe-based tools with Haskell. With Haskell Indexer it’s possible to list > all use-sites of any given function (get reverse-references) and explore > the code without any IDE setup. > A portion of GHC and Stackage is indexed and available at > http://stuff.codereview.me/. Thank you & happy coding, Robin [1] https://github.com/google/haskell-indexer [2] https://www.haskell.org/communities/11-2017/html/report.html

1 0

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 18 Jan '18

18 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 17 Jan '18

17 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 16 Jan '18

16 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 16 Jan '18

16 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 16 Jan '18

16 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