January 2017 - Haskell-Cafe

hash tables
by Dennis Raddle 27 Jan '17

27 Jan '17

I want to build a hash table and then freeze it and use it for fast lookup later. Is there a way to build it in IO or ST but freeze it and use it in transparent code later? D

4 3

Re: [Haskell-cafe] Using stringize and string concatenation in ghc preprocessing
by Ben Franksen 27 Jan '17

27 Jan '17

Am 20.08.2016 um 20:33 schrieb Brandon Allbery: > You might want to look at cpphs as an alternative preprocessor. There are > some ancient K&R-era hacks that could be used if absolutely necessary, but > cpphs should be a much simpler and cleaner solution. Is there any reason /not/ to prefer cpphs over cpp? If not, why does anyone still use cpp for Haskell? Cheers Ben -- "Make it so they have to reboot after every typo." ― Scott Adams

12 36

Problem using external package from git with stack
by Juan Luis Martty 27 Jan '17

27 Jan '17

Hello, I am trying to use binary-serialise-cbor in my project. Since it's not on hackage I followed the docs and added the following to stack.yaml: packages: - '.' - location: git: https://github.com/well-typed/binary-serialise-cbor.git commit: 1e11ea5cc7810d241b2fe1bca0ed435baa4d4371 extra-dep: true flags: binary-serialise-cbor: newtime15: true And in my .cabal file I have: build-depends: base >= 4.7 && < 5, network-simple, time, binary-serialize-cbor, bytestring When I do stack build the package is downloaded and built but then I get the following error: Error: While constructing the build plan, the following exceptions were encountered: In the dependencies for hcopia-0.1.0.0: binary-serialize-cbor must match -any, but the stack configuration has no specified version I attached both files just in case. Regards, Juan

4 6

Re: [Haskell-cafe] Instrumentation without requiring code-level changes?
by David Turner 27 Jan '17

27 Jan '17

On 27 Jan 2017 07:16, "Saurabh Nanda" <saurabhnanda(a)gmail.com> wrote: (copying the mailing list -- I don't think your intention was to keep this off the mailing list) Apologies, yes, I failed to CC the mailing list. Thanks. Double checked that this one is addressed properly. I've looked at middleware for Scotty (or any WAI application), but it has limitations. I want deeper insights about how much time is being spent where, when serving a web request -- which is why the need to instrument SQL, Redis, and HTML rendering. One example that doesn't necessarily need to be in the IO monad is HTML rendering using Lucid, where the data is being passed separately to it (standard Controller <> View separation). Ok, this is definitely something that's hard to define, let alone measure: Lucid's rendering uses Bytestring.Builder to interleave the rendering and the transmission of traffic over the network, so a simple endTime-minus-startTime calculation doesn't work. You'd have to do something within ByteString.Builder itself to count the time spent filling each buffer vs the time spent sending it. I don't know of an existing implementation, but I can see how you'd do it (and it's worth noting that the relevant code is in IO, hidden behind a call to `unsafePerformIO` or similar): https://hackage.haskell.org/package/bytestring-0.10.8.1/docs/Data-ByteStrin… Also, if everything needs to be run in MonadIO, what does that do to fine-grained effect tracking? I wanted to have HasDb, HasRedis, HasEmail kind of monads (or type-classes) that give me some guarantees about the **type** of IO interactions a particular function call can do. If I instrument them and add an additional MonadIO constraint, does it mean any IO can be lifted into such monads? Your type classes can avoid mentioning IO, it's the instance definitions that would want to contain the instrumentation code. But they need IO anyway so that's no big deal. It's unfortunate to know that the RTS doesn't have these kind of instrumentation capabilities built-in. Is it absolutely not possible to do this at an RTS level? Ah, actually, there's the RTS event log: https://ghc.haskell.org/trac/ghc/wiki/EventLog and https://hackage.haskell.org/package/base-4.9.1.0/docs/Debug-Trace.html#g:2 But it emits a _lot_ of events from the RTS if you switch it on. Cheers, David -- Saurabh. On Fri, Jan 27, 2017 at 12:32 PM, David Turner < dct25-561bs(a)mythic-beasts.com> wrote: > Hi Saurabh, > > There's no direct equivalent to monkey-patching in Haskell (AFAIK (*)). > Why not instrument things always? The performance impact is usually quite > negligible, and the ability to switch instrumentation on at runtime in > production is sometimes invaluable. > > For instrumenting Scotty (in particular) or WAI-based apps (in general) > you can instrument things simply by inserting an appropriate `Middleware`, > a decision that can be deferred until service-startup time, and which > involves no change to the Scotty-side code. > > There's no equivalent to WAI for database access so I don't have a general > answer in that case, but typically database APIs have only a few core > `execute` or `query` functions that are quite straightforward to wrap with > instrumentation if needs be. > > This all kinda _has_ to be in IO anyway, as you're trying to measure a > real-world activity. Certainly there's no problem with either Scotty or > databases in this regard, as they're running in IO. Do you have an example > where you need instrumentation of a pure (i.e. non-IO) computation? In such > a case you could use the `unsafePerformIO` escape hatch (like `Debug.Trace` > does) but you'll have to be very careful to measure what you think you're > measuring: the language is quite free to reorder computations and avoid > repeating duplicated computations via referential transparency etc. > > (*) I mean, you could do something with dynamic libs and LD_PRELOAD (the > original monkey-patching) but please don't! > > Hope that helps, > > David > > On 27 Jan 2017 05:21, "Saurabh Nanda" <saurabhnanda(a)gmail.com> wrote: > >> (another cross post from Reddit - https://www.reddit.com/r/haske >> ll/comments/5qfd36/instrumentation_without_required_application/) >> >> Is it possible to collect instrumentation data from a Hakell application >> without requiring the core application to change code? Here are some >> examples of instrumentation data: >> >> * Time taken to serve an HTTP request (not average time, but individual >> times, for individual requests) along with the incoming request >> params+headers and outgoing response length. >> * Time taken to make an SQL query along with the actual query (again, not >> average times, but individual times, for individual queries) >> * Time taken to fetch data from Redis along with the Redis command >> * Time taken to render an HTML page along with path to the HTML file >> >> Most dynamic languages (like Ruby) allow monkey-patching OR "decorating" >> existing functions during runtime. Most instrumentation agents (like >> Skylight, Newrelic), simply monkey-patch the API surfaces of known >> libraries to collect this data. Therefore, using these instrumentation >> agents is a one line code change (just include the gem, or drop the JAR, or >> whatever). >> >> What is the equivalent of this in Haskell? >> >> Here's what I've tried so far [1] , but it has the following >> disadvantages: >> >> * Requires changes to the application's cabal file to replace the >> non-instrumented versions of the libraries with the instrumented version >> (replace scotty with instrumentedscotty, in my example) >> * Requires the application to explicitly import the instrumented versions >> of the libraries (replace import Scotty with import InstrumentedScotty, in >> my example) >> * Forces all the code interacting with instrumented APIs to be run in a >> MonadIO environment - because of the underlying calls to getCurrentTime >> >> I'm sure there's a better way, but I couldn't get my hands on it! >> >> [1] https://gist.github.com/saurabhnanda/27592da0269bc35569ec6239e1a91b75 >> >> -- 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. >> > -- http://www.saurabhnanda.com

1 0

Re: [Haskell-cafe] Instrumentation without requiring code-level changes?
by Saurabh Nanda 27 Jan '17

27 Jan '17

(copying the mailing list -- I don't think your intention was to keep this off the mailing list) I've looked at middleware for Scotty (or any WAI application), but it has limitations. I want deeper insights about how much time is being spent where, when serving a web request -- which is why the need to instrument SQL, Redis, and HTML rendering. One example that doesn't necessarily need to be in the IO monad is HTML rendering using Lucid, where the data is being passed separately to it (standard Controller <> View separation). Also, if everything needs to be run in MonadIO, what does that do to fine-grained effect tracking? I wanted to have HasDb, HasRedis, HasEmail kind of monads (or type-classes) that give me some guarantees about the **type** of IO interactions a particular function call can do. If I instrument them and add an additional MonadIO constraint, does it mean any IO can be lifted into such monads? It's unfortunate to know that the RTS doesn't have these kind of instrumentation capabilities built-in. Is it absolutely not possible to do this at an RTS level? -- Saurabh. On Fri, Jan 27, 2017 at 12:32 PM, David Turner < dct25-561bs(a)mythic-beasts.com> wrote: > Hi Saurabh, > > There's no direct equivalent to monkey-patching in Haskell (AFAIK (*)). > Why not instrument things always? The performance impact is usually quite > negligible, and the ability to switch instrumentation on at runtime in > production is sometimes invaluable. > > For instrumenting Scotty (in particular) or WAI-based apps (in general) > you can instrument things simply by inserting an appropriate `Middleware`, > a decision that can be deferred until service-startup time, and which > involves no change to the Scotty-side code. > > There's no equivalent to WAI for database access so I don't have a general > answer in that case, but typically database APIs have only a few core > `execute` or `query` functions that are quite straightforward to wrap with > instrumentation if needs be. > > This all kinda _has_ to be in IO anyway, as you're trying to measure a > real-world activity. Certainly there's no problem with either Scotty or > databases in this regard, as they're running in IO. Do you have an example > where you need instrumentation of a pure (i.e. non-IO) computation? In such > a case you could use the `unsafePerformIO` escape hatch (like `Debug.Trace` > does) but you'll have to be very careful to measure what you think you're > measuring: the language is quite free to reorder computations and avoid > repeating duplicated computations via referential transparency etc. > > (*) I mean, you could do something with dynamic libs and LD_PRELOAD (the > original monkey-patching) but please don't! > > Hope that helps, > > David > > On 27 Jan 2017 05:21, "Saurabh Nanda" <saurabhnanda(a)gmail.com> wrote: > >> (another cross post from Reddit - https://www.reddit.com/r/haske >> ll/comments/5qfd36/instrumentation_without_required_application/) >> >> Is it possible to collect instrumentation data from a Hakell application >> without requiring the core application to change code? Here are some >> examples of instrumentation data: >> >> * Time taken to serve an HTTP request (not average time, but individual >> times, for individual requests) along with the incoming request >> params+headers and outgoing response length. >> * Time taken to make an SQL query along with the actual query (again, not >> average times, but individual times, for individual queries) >> * Time taken to fetch data from Redis along with the Redis command >> * Time taken to render an HTML page along with path to the HTML file >> >> Most dynamic languages (like Ruby) allow monkey-patching OR "decorating" >> existing functions during runtime. Most instrumentation agents (like >> Skylight, Newrelic), simply monkey-patch the API surfaces of known >> libraries to collect this data. Therefore, using these instrumentation >> agents is a one line code change (just include the gem, or drop the JAR, or >> whatever). >> >> What is the equivalent of this in Haskell? >> >> Here's what I've tried so far [1] , but it has the following >> disadvantages: >> >> * Requires changes to the application's cabal file to replace the >> non-instrumented versions of the libraries with the instrumented version >> (replace scotty with instrumentedscotty, in my example) >> * Requires the application to explicitly import the instrumented versions >> of the libraries (replace import Scotty with import InstrumentedScotty, in >> my example) >> * Forces all the code interacting with instrumented APIs to be run in a >> MonadIO environment - because of the underlying calls to getCurrentTime >> >> I'm sure there's a better way, but I couldn't get my hands on it! >> >> [1] https://gist.github.com/saurabhnanda/27592da0269bc35569ec6239e1a91b75 >> >> -- 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. >> > -- http://www.saurabhnanda.com

1 1

Suggestions for "Advanced" Topics for Haskell-based Class
by Conrad Cunningham 27 Jan '17

27 Jan '17

I am teaching a class in Haskell-based functional programming for advanced undergraduates and beginning graduate students at my institution. None of the students have previously used Haskell and for most of my students functional programming is new. Because I am teaching this in a "multiparadigm programming" course, I want to expand beyond what I have usually covered in the Haskell-based "functional programming" course and cover a few topics in areas such as parallel, concurrent, distributed, reactive, or metaprogramming (domain-specific languages, Template Haskell, etc.). Assuming my course has more or less covered the topics in *Learn You a Haskell for Great Good *(with likely shallow coverage of monads) at that point, what would be good additional topics to cover, libraries to use, and tutorial or teaching resources to use? Although I have taught fundamental Haskell FP topics for many years, I have not delved into any of these "advanced" topics. Thanks, Conrad -- H. Conrad Cunningham, Professor Computer and Information Science University of Mississippi (USA)

9 10

Instrumentation without requiring code-level changes?
by Saurabh Nanda 27 Jan '17

27 Jan '17

(another cross post from Reddit - https://www.reddit.com/r/haskell/comments/5qfd36/instrumentation_without_re… ) Is it possible to collect instrumentation data from a Hakell application without requiring the core application to change code? Here are some examples of instrumentation data: * Time taken to serve an HTTP request (not average time, but individual times, for individual requests) along with the incoming request params+headers and outgoing response length. * Time taken to make an SQL query along with the actual query (again, not average times, but individual times, for individual queries) * Time taken to fetch data from Redis along with the Redis command * Time taken to render an HTML page along with path to the HTML file Most dynamic languages (like Ruby) allow monkey-patching OR "decorating" existing functions during runtime. Most instrumentation agents (like Skylight, Newrelic), simply monkey-patch the API surfaces of known libraries to collect this data. Therefore, using these instrumentation agents is a one line code change (just include the gem, or drop the JAR, or whatever). What is the equivalent of this in Haskell? Here's what I've tried so far [1] , but it has the following disadvantages: * Requires changes to the application's cabal file to replace the non-instrumented versions of the libraries with the instrumented version (replace scotty with instrumentedscotty, in my example) * Requires the application to explicitly import the instrumented versions of the libraries (replace import Scotty with import InstrumentedScotty, in my example) * Forces all the code interacting with instrumented APIs to be run in a MonadIO environment - because of the underlying calls to getCurrentTime I'm sure there's a better way, but I couldn't get my hands on it! [1] https://gist.github.com/saurabhnanda/27592da0269bc35569ec6239e1a91b75 -- Saurabh.

1 0

Question about STRef
by Antoine Rimlet 26 Jan '17

26 Jan '17

Hi list, I try to get the following little program (a slightly modified "Man or boy", it prints -14254067) work "as expected", that is, without consuming lots of memory: import Control.Monad.ST import Data.STRef a k x1 x2 x3 x4 x5 = do kk <- newSTRef k let b = do k <- modifySTRef kk pred >> readSTRef kk; a k b x1 x2 x3 x4 if k <= 0 then do x3' <- x3; x4' <- x4; return (x3' + x4') else do x5' <- x5; b' <- b; return (x5' + b') main = print (runST (a 22 (return 1) (return (-1)) (return (-1)) (return 1) (return 0))) I use GHC 7.8.4, and executing this program uses about 2.5 GB of memory (or about 3.5 GB with runghc). However, the "equivalent" program in OCaml only needs 4 MB (or 9 MB with the interpreter): let rec a k x1 x2 x3 x4 x5 = let kk = ref k in let rec b () = begin decr kk; a !kk b x1 x2 x3 x4 end in if k <= 0 then let v = x3 () in v + x4 () else let v = x5 () in v + b ();; print_int (a 22 (fun () -> 1) (fun () -> -1) (fun () -> -1) (fun () -> 1) (fun () -> 0));; print_newline ();; Therefore I suspect I'm doing something wrong, but I can't see what. I did try to use the strict version modifySTRef' as indicated in the manual, but with no visible improvement. Thanks, Antoine

3 3

Request for feedback on two GHC proposals
by Mario Blažević 26 Jan '17

26 Jan '17

The time is nigh for closing the discussion on the Eval class proposal for GHC, so please pipe in if you have any interest in it, either on the practical (what's the point of this terrible idea!?) or the theoretical side (I can finally get those free theorems and I'd love unlifted products!). https://github.com/ghc-proposals/ghc-proposals/pull/27 I would also appreciate feedback on a tangentially related and wholly practical INCOMPLETE_CONTEXTS pragma proposal at https://github.com/ghc-proposals/ghc-proposals/pull/34 Thank you.

1 0

Re: [Haskell-cafe] Question about STRef
by Johannes Waldmann 26 Jan '17

26 Jan '17

What Michael did not mention in the mail, but it's in his code: numerals defaulted to Integer, and the story changes (somewhat) if we force Int. I updated my measurements: http://www.imn.htwk-leipzig.de/~waldmann/etc/mob/ and ghc-8 looks better now - but not quite wins. > there's still some more low hanging fruit here ... for whom? What could we reasonably expect of the compiler here? It could do the strictification? the unboxing? It certainly could not replace Integer by Int, since the range of numerical values has no obvious bound. But then, all these Integers are small, but we pay quite an overhead (for represeting Int as Integer) which has increased for current ghcs? - J.

2 2