- Haskell-Cafe - Haskell.org

here's my solution for scripting/interpreter approach
by Dennis Raddle 13 Feb '17

13 Feb '17

My application needed the flexibility of writing test code and running it, or configuring its job (playback of music) through Haskell code and immediately testing the result (i.e. making sound and listening). I thought I would use GHCI, but I ran into some trouble. For one thing, my program forks a thread to do the timed control of the music, while the main thread implements a REPL-like "control loop" -- i.e. let me enter commands to influence the playback or halt it. I think this was crashing GHCI, perhaps when an interpreted script forks a thread which is still alive when control returns to the GHCI prompt. Not sure. Anyway here's what I did. Now the process that does real-time control of the playback is an entirely separate process. The control loop is started by me first, and depending on the command I enter, it builds the playback program with "ghc --make" and then spawns it. I send it signals from the control loop. This turns out to be great. I can make changes anywhere in my playback application, from the deepest utility library to the top-level configuration script, and it builds as needed before running. And, in the case it doesn't need to build anything, "ghc --make" finishes quickly so it doesn't feel inefficient to invoke it after every command I enter in the control loop. D

2 2

Re: [Haskell-cafe] Lenses and records and ecosystem
by Anthony Clayden 11 Feb '17

11 Feb '17

> ON 10/02/17 07:10, Tony Morris wrote: >> On 10/02/17 15:35, Anthony Clayden wrote: >> I see Simon PJ's comment here >> https://github.com/ghc-proposals/ghc-proposals/pull/6#issuecomment-277971802 >> and the lengthy discussions from different advocates. >> >> How much is it true there's a fractured "Haskell ecosystem" >> with 2 (3?) incompatible approaches: >> * H98 style labelled records with various extensions >> to ease the pain. >> * newtype-wrapped Lenses >> * 'raw' (unwrapped) Lenses > Yearss ago, many of us spent a long time > on different designs of lenses, ... > ... it would be foolish to concede that ground > for no significant benefit. Thanks Tony, but I don't understand: concede what ground? You're perhaps saying that one style of lenses is the 'right' one(?) I am asking if they can co-exist. > > Can you mix those three styles inside one program? > How much pain does it cause? > > Can you import libraries with a mix of styles? How does a > program cope? Why would you? For what practical purpose? A lens/a structure/a record is a means to an end. Applications that are putting/getting stuff are doing it for some purpose. Not merely because lenses are a nice application of category theory. So say you want to use the functionality from 3 different libraries, but each is written using a different style. >> >> I see the plethora of operators Lenses come with >> (mostly to keep the types coherent?). >> Except that Lens composition is plain function composition >> (.). >> >> I remember something from SPJ's video/lecture on Lenses: >> that having Lens composition turn out to be function >> composition is "cute". > The use of (.) here was deliberately designed that way to > assist in working against existing code. Is "against" some clever pun here? Like Concerto for Piano against Orchestra? Certainly (.) for lenses works 'backwards' (i.e. suffix style) compared to function-prefix style. (As any Lens tutorial will say.) >> That suggests to me it's more of a happy accident than a >> necessary feature. > Not necessary, just useful. I am less excited about this > feature than many others, but it is useful nonetheless, > and was specifically designed that way. Whether or not that's justified [**] it's counter-intuitive w.r.t. Haskell, so I don't see a need to use the same symbol. Hence my "wondering" below. >> >> I also see in the ORF proposal, OverloadedLabels part, >> that composing with Control.Category.(.) can lead to type >> ambiguity. >> >> I wonder: >> Could there be a dedicated operator for composing Lenses, >> that has the same semantics as (.), >> but a more specialised type? >> To strengthen type inference/reduce ambiguity. >> [**] the justification for postfix style seems to be so it's more like OO. Seems strange: FP just isn't very like OO. And in particular, functional data structures, just aren't like OO/procedural data structures. Anthony

2 1

Re: [Haskell-cafe] Lenses and records and ecosystem
by Anthony Clayden 11 Feb '17

11 Feb '17

> 2017-02-11 09:30 UTC Fumiaki Kinoshita: > Are there any real cases that the polymorphism of > Control.Category.. becomes a real problem? I think > ambiguity rarely occurs on the kind (* -> * -> *). > Hi Fumiaki, the remark is here https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/p… The composition is: fooBar = #foo . #bar ... However, if labels are interpreted using IsLabel, the inferred type of fooBar is (Category cat, IsLabel "foo" (cat s t), IsLabel "bar" (cat r s)) => cat r t There's no FunDep on IsLabel (nor could there be). So `s` is ambiguous. Same as the classical (show . read). The usual type for raw/unwrapped Lenses is: type Lens s t a b = forall f. Functor f => (a -> f b) -> (s -> f t) Which is of kind (* -> * -> *), but you need to squint a bit. > > 2017-02-10 14:35 GMT+09:00 Anthony Clayden: > > > > > > I see the plethora of operators Lenses come with > > (mostly to keep the types coherent?). > > Except that Lens composition is plain function > > composition (.). > > > > I remember something from SPJ's video/lecture on Lenses: > > that having Lens composition turn out to be function > > composition is "cute". > > That suggests to me it's more of a happy accident than a > > necessary feature. > > > > I also see in the ORF proposal, OverloadedLabels part, > > that composing with Control.Category.(.) can lead to > > type ambiguity. > > > > I wonder: > > Could there be a dedicated operator for composing Lenses > > , that has the same semantics as (.), > > but a more specialised type? > > To strengthen type inference/reduce ambiguity. > > AntC

1 0

Lenses and records and ecosystem
by Anthony Clayden 11 Feb '17

11 Feb '17

I see Simon PJ's comment here https://github.com/ghc-proposals/ghc-proposals/pull/6#issuecomment-277971802 and the lengthy discussions from different advocates. How much is it true there's a fractured "Haskell ecosystem" with 2 (3?) incompatible approaches: * H98 style labelled records with various extensions to ease the pain. * newtype-wrapped Lenses * 'raw' (unwrapped) Lenses Can you mix those three styles inside one program? How much pain does it cause? Can you import libraries with a mix of styles? How does a program cope? I see the plethora of operators Lenses come with (mostly to keep the types coherent?). Except that Lens composition is plain function composition (.). I remember something from SPJ's video/lecture on Lenses: that having Lens composition turn out to be function composition is "cute". That suggests to me it's more of a happy accident than a necessary feature. I also see in the ORF proposal, OverloadedLabels part, that composing with Control.Category.(.) can lead to type ambiguity. I wonder: Could there be a dedicated operator for composing Lenses, that has the same semantics as (.), but a more specialised type? To strengthen type inference/reduce ambiguity. AntC

3 2

Lifting a value into a DataKind
by Ivan Lazar Miljenovic 09 Feb '17

09 Feb '17

Is it possible to automatically lift an arbitrary value into a type? i.e. I'm after a function of type `a -> Proxy (b :: a)`. More specifically, I'm wanting to be able to write a function that can convert an Enum (e.g. Bool or Ord) into such a Proxy, so I can actually write a function that looks like: `a -> (forall b. Proxy (b :: a) -> r) -> r` and use the `a` type as a selector value (to e.g. choose between type class instances). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

2 8

Typeclass constraints not inferred when defining a function
by Stephen Demos 09 Feb '17

09 Feb '17

Hi all, A professor showed me a function today that looks like this - `append = flip (foldr (:))` GHC spits back an error when this is compiled - ``` • Ambiguous type variable ‘t0’ arising from a use of ‘foldr’ prevents the constraint ‘(Foldable t0)’ from being solved. Relevant bindings include append :: t0 a -> [a] -> [a] (bound at test.hs:4:1) Probable fix: use a type annotation to specify what ‘t0’ should be. ``` It's obvious from this error message the problem is that the type GHC infers doesn't include the typeclass constraint. In this case, it's Foldable, but you can easily think of other situations where the same error comes up with different typeclasses (a silly example that comes to mind is `fmap (const [])`). It's pretty easy to fix this error by just providing a type for the function that is more specific than the one GHC infers. However, he showed me that defining the same function in ghci using a let binding doesn't yield the same error. In fact, when using `:t`, it shows that ghci successfully infers the typeclass constraint on the function - ``` > :t flip (foldr (:)) flip (foldr (:)) :: Foldable t => t a -> [a] -> [a] ``` I was wondering if anyone could explain this apparent discrepancy to me. Thanks! Stephen Demos

3 2

Cabal Conditional For Detecting GHCi
by aditya siram 09 Feb '17

09 Feb '17

Hi all, I was wondering if Cabal has a predicate which allows me to only enable options when running GHCi. The use-case is I have a set of `ghc-options` that I do *not* want enabled when I run `cabal repl` or `stack repl`. Ideally I'm looking for something along the lines of: if !repl ghc-options: ... -deech

2 4

ESSLLI student session CFP: Deadline extended until Feb 14
by Andreas Abel 08 Feb '17

08 Feb '17

*Deadline Extension to February 14* *ESSLLI 2017 STUDENT SESSION* Held during the 29th European Summer School in Logic, Language and Information Toulouse, France, July 17-28, 2017 *NEW* *Deadline for submissions: February 14, 2017* https://easychair.org/conferences/?conf=stus2017 *ABOUT:* The Student Session of the 29th European Summer School in Logic, Language, and Information (ESSLLI) will take place in Toulouse, France, July 17th to 28th, 2017 (https://www.irit.fr/esslli2017/) We invite submissions of original, unpublished work from students in any area at the intersection of Logic & Language, Language & Computation, or Logic & Computation. Submissions will be reviewed by several experts in the field, and accepted papers will be presented orally or as posters and selected papers will appear in the Student Session proceedings by Springer. This is an excellent opportunity to receive valuable feedback from expert readers and to present your work to a diverse audience. *ORAL/POSTER PRESENTATIONS:* Note that there are two separate kinds of submissions, one for oral presentations and one for posters. This means that papers are directly submitted either as oral presentations or as poster presentations. Reviewing and ranking will be done separately. We particularly encourage submissions for posters, as they offer an excellent opportunity to present smaller research projects and research in progress. *SUBMISSION GUIDELINES:* Authors must be students, and submissions may be singly or jointly authored. Each author may submit at most one single and one jointly authored contribution. Submissions should not be longer than 8 pages for an oral presentation or 4 pages for a poster presentation (including examples and references). Submissions must be anonymous, without any identifying information. More detailed guidelines regarding submission can be found on the Student Session website: http://www2.sfs.uni-tuebingen.de/esslli-stus-2017/. *SPONSORSHIP AND PRIZES* As in previous years, Springer has kindly agreed to sponsor the ESSLLI student session. The best poster and best talk will be awarded Springer book vouchers of 500€ each. *FURTHER INFORMATION:* Please direct inquiries about submission procedures or other matters relating to the Student Session to johannes.wahle(a)uni-tuebingen.de and karoliina.lohiniva(a)unige.ch. ESSLLI 2017 will feature a wide range of foundational and advanced courses and workshops in all areas of Logic, Language, and Computation. For further information, including registration information and course listings, and for general inquiries about ESSLLI 2017, please consult the main ESSLLI 2017 page: https://www.irit.fr/esslli2017/. Kind regards, The ESSLLI 2017 Student Session Organization Committee Chairs: Johannes Wahle (Universität Tübingen) Karoliina Lohiniva (Université de Genève) LoCo co-chairs: Marie Farrell (National University of Ireland Maynooth) Herbert Lange (University of Gothenburg) LoLa co-chairs: Milica Denic (École normale supérieure de Paris) Mora Maldonado (École normale supérieure de Paris) LaCo co-chairs: Emmanuele Chersoni (Université d'Aix-Marseille) Jennifer Sikos (Universität Heidelberg) -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/

1 0

Network.Download stops after 10 downloads
by Stéphane Thibaud 08 Feb '17

08 Feb '17

I have tried the Network.Download library in order to download CSV files from Yahoo Finance, but after the 10th download every next download fails. Does Network.Download keep connections open? I did consume the result of the openURI function (even with deepseq). Any ideas? Thanks in advance! Stéphane

2 3

Re: [Haskell-cafe] Monad transformer performance - Request to review benchmarking code + results
by Saurabh Nanda 07 Feb '17

07 Feb '17

Thanks for digging deeper, David. What exactly did you inline? Also, am I the only one losing my mind over this? It's such a straightforward use of available code structuring tools in Haskell. How come the compiler is not being smart about this OOB? -- Saurabh. On 29 Jan 2017 9:42 pm, "David Turner" <dct25-561bs(a)mythic-beasts.com> wrote: Here's the profiling summary that I got: COST CENTRE MODULE %time %alloc getOverhead Criterion.Monad 41.3 0.0 >>= Lucid.Base 19.2 41.6 makeElement.\.\ Lucid.Base 11.4 23.4 fromHtmlEscapedString Blaze.ByteString.Builder.Html.Utf8 7.9 14.9 >>= Data.Vector.Fusion.Util 2.3 1.7 return Lucid.Base 1.4 2.1 runBenchmark.loop Criterion.Measurement 1.2 0.0 with.\ Lucid.Base 1.0 2.1 foldlMapWithKey Lucid.Base 0.5 2.6 streamDecodeUtf8With.decodeChunk Data.Text.Encoding 0.0 1.7 As expected, HtmlT's bind is the expensive bit. However I've been unable to encourage it to go away using INLINE pragmas. On 29 January 2017 at 15:45, Oliver Charles <ollie(a)ocharles.org.uk> wrote: > I would start by inlining operations in the Functor, Applicative and Monad > classes for your monad and all the layers in the stack (such as HtmlT). An > un-inlining monadic bind can end up allocating a lot (as it's such a common > operation) > > On Sun, 29 Jan 2017, 3:32 pm Saurabh Nanda, <saurabhnanda(a)gmail.com> > wrote: > >> Please tell me what to INLINE. I'll update the benchmarks. >> >> Also, shouldn't this be treated as a GHC bug then? Using monad >> transformers as intended should not result in a severe performance penalty! >> Either monad transformers themselves are a problem or GHC is not doing the >> right thing. >> >> -- Saurabh. >> >> On 29 Jan 2017 7:50 pm, "Oliver Charles" <ollie(a)ocharles.org.uk> wrote: >> >> I would wager a guess that this can be solved with INLINE pragmas. We >> recently added INLINE to just about everything in transformers and got a >> significant speed up. >> >> On Sun, 29 Jan 2017, 11:18 am David Turner, < >> dct25-561bs(a)mythic-beasts.com> wrote: >> >> I would guess that the issue lies within HtmlT, which looks vaguely >> similar to a WriterT transformer but without much in the way of >> optimisation (e.g. INLINE pragmas). But that's just a guess after about 30 >> sec of glancing at https://hackage.haskell.org >> /package/lucid-2.9.7/docs/src/Lucid-Base.html so don't take it as gospel. >> >> My machine is apparently an i7-4770 of a similar vintage to yours, >> running Ubuntu in a VirtualBox VM hosted on Windows. 4GB of RAM in the VM, >> 16 in the host FWIW. >> >> >> On 29 Jan 2017 10:26, "Saurabh Nanda" <saurabhnanda(a)gmail.com> wrote: >> >> Thank you for the PR. Does your research suggest something is wrong with >> HtmlT when combined with any MonadIO, not necessarily ActionT? Is this an >> mtl issue or a lucid issue in that case? >> >> Curiously, what's your machine config? I'm on a late 2011 macbook pro >> with 10G ram and some old i5. >> >> -- Saurabh. >> >> On 29 Jan 2017 3:05 pm, "David Turner" <dct25-561bs(a)mythic-beasts.com> >> wrote: >> >> The methodology does look reasonable, although I think you should wait >> for all the scotty threads to start before starting the benchmarks, as I >> see this interleaved output: >> >> Setting phasers to stun... (port 3002) (ctrl-c to quit) >> Setting phasers to stun... (port 3003) (ctrl-c to quit) >> Setting phasers to stun... (port 3001) (ctrl-c to quit) >> benchmarking bareScotty >> Setting phasers to stun... (port 3000) (ctrl-c to quit) >> >> Your numbers are wayyy slower than the ones I see on my dev machine: >> >> benchmarking bareScotty >> Setting phasers to stun... (port 3000) (ctrl-c to quit) >> time 10.94 ms (10.36 ms .. 11.52 ms) >> 0.979 R² (0.961 R² .. 0.989 R²) >> mean 12.53 ms (11.98 ms .. 13.28 ms) >> std dev 1.702 ms (1.187 ms .. 2.589 ms) >> variance introduced by outliers: 66% (severely inflated) >> >> benchmarking bareScottyBareLucid >> time 12.95 ms (12.28 ms .. 13.95 ms) >> 0.972 R² (0.951 R² .. 0.989 R²) >> mean 12.20 ms (11.75 ms .. 12.69 ms) >> std dev 1.236 ms (991.3 μs .. 1.601 ms) >> variance introduced by outliers: 50% (severely inflated) >> >> benchmarking transScottyBareLucid >> time 12.05 ms (11.70 ms .. 12.39 ms) >> 0.992 R² (0.982 R² .. 0.996 R²) >> mean 12.43 ms (12.06 ms .. 13.01 ms) >> std dev 1.320 ms (880.5 μs .. 2.071 ms) >> variance introduced by outliers: 54% (severely inflated) >> >> benchmarking transScottyTransLucid >> time 39.73 ms (32.16 ms .. 49.45 ms) >> 0.668 R² (0.303 R² .. 0.969 R²) >> mean 42.59 ms (36.69 ms .. 54.38 ms) >> std dev 16.52 ms (8.456 ms .. 25.96 ms) >> variance introduced by outliers: 92% (severely inflated) >> >> benchmarking bareScotty >> time 11.46 ms (10.89 ms .. 12.07 ms) >> 0.986 R² (0.975 R² .. 0.994 R²) >> mean 11.73 ms (11.45 ms .. 12.07 ms) >> std dev 800.6 μs (636.8 μs .. 975.3 μs) >> variance introduced by outliers: 34% (moderately inflated) >> >> but nonetheless I do also see the one using renderTextT to be >> substantially slower than the one without. >> >> I've sent you a PR [1] that isolates Lucid from Scotty and shows that >> renderTextT is twice as slow over IO than it is over Identity, and it's >> ~10% slower over Reader too: >> >> benchmarking renderText >> time 5.529 ms (5.328 ms .. 5.709 ms) >> 0.990 R² (0.983 R² .. 0.995 R²) >> mean 5.645 ms (5.472 ms .. 5.888 ms) >> std dev 593.0 μs (352.5 μs .. 908.2 μs) >> variance introduced by outliers: 63% (severely inflated) >> >> benchmarking renderTextT Id >> time 5.439 ms (5.243 ms .. 5.640 ms) >> 0.991 R² (0.985 R² .. 0.996 R²) >> mean 5.498 ms (5.367 ms .. 5.631 ms) >> std dev 408.8 μs (323.8 μs .. 552.9 μs) >> variance introduced by outliers: 45% (moderately inflated) >> >> benchmarking renderTextT Rd >> time 6.173 ms (5.983 ms .. 6.396 ms) >> 0.990 R² (0.983 R² .. 0.995 R²) >> mean 6.284 ms (6.127 ms .. 6.527 ms) >> std dev 581.6 μs (422.9 μs .. 773.0 μs) >> variance introduced by outliers: 55% (severely inflated) >> >> benchmarking renderTextT IO >> time 12.35 ms (11.84 ms .. 12.84 ms) >> 0.989 R² (0.982 R² .. 0.995 R²) >> mean 12.22 ms (11.85 ms .. 12.76 ms) >> std dev 1.159 ms (729.5 μs .. 1.683 ms) >> variance introduced by outliers: 50% (severely inflated) >> >> I tried replacing >> >> forM [1..10000] (\_ -> div_ "hello world!") >> >> with >> >> replicateM_ 10000 (div_ "hello world!") >> >> which discards the list of 10,000 () values that the forM thing >> generates, but this made very little difference. >> >> Hope this helps, >> >> David >> >> >> [1] https://github.com/vacationlabs/monad-transformer-benchmark/pull/2 >> >> >> >> On 29 January 2017 at 07:26, Saurabh Nanda <saurabhnanda(a)gmail.com> >> wrote: >> >> Hi, >> >> I was noticing severe drop in performance when Lucid's HtmlT was being >> combined with Scotty's ActionT. I've tried putting together a minimal repro >> at https://github.com/vacationlabs/monad-transformer-benchmark Request >> someone with better knowledge of benchmarking to check if the benchmarking >> methodology is correct. >> >> Is my reading of 200ms performance penalty correct? >> >> -- Saurabh. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> >>

3 7