October 2015 - Haskell-Cafe

Monads for Drummers! Yet another monad tutorial with pictures!
by Anton Kholomiov 10 Oct '15

10 Oct '15

Yes! It's another monad tutorial. I've tried hard not to do it but finally it came out. I wrote a book on Haskell in Russian. It's a translation of the chapter that is dedicated to monads. I was convinced by friends to publish it. The monads are explained with pictures and Kleisli categories. Hope this can help to someone to grasp the monad concept. ------------------------------------- ps: pictures were made with diagrams Thank you for being kind with my awkward English!

1 1

ANNOUNCE: unordered-graphs
by Ivan Lazar Miljenovic 10 Oct '15

10 Oct '15

I have a relatively hacked-together graph library that uses unordered-containers as a backend available if anyone finds it interesting/useful: http://hackage.haskell.org/package/unordered-graphs It's primarily developed just for my own needs and thus I'm not sure how much future work I'll be doing on it, but I'm willing to accept pull requests. This library was semi-experimental in that I also tried a few things out with it: * Polymorphic node type * Fixed auto-generated edge type: this is because (node,node, label) triples (ala fgl) do not provide sufficient information to be able to distinguish between multiple edges, etc. * Type parameter to determine whether the graph is directed or undirected. * Typeclass to allow you to determine the type/output of a a match (I didn't end up actually using this, as the one time I needed to do a match I found the extra polymorphism caused problems; it also isn't comprehensive as I didn't write all that many instances.) -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Interfacing with the GHC runtime from a library
by Nicola Gigante 10 Oct '15

10 Oct '15

Hi everybody, suppose to have an Haskell library which is in part implemented in C for whatever reason. Can the C part talk with the runtime, in particular the scheduler? In other words, does the runtime expose the functionality needed to implement, for example, the STM library from outside the GHC runtime itself? Thank you, Nicola

2 1

Vote/comment on usability survey feedback
by Rick Dzekman 09 Oct '15

09 Oct '15

*Responses* Over 100 people responded to the Hackage usability survey. For a qualitative survey this was far more than expected so thank you all for contributing. I'm still going through the responses and will post a csv of the combined web, email and reddit responses soon. *Vote and comment* In the meantime I went through and collated all of the gripes and suggestions people made into two Trello boards: Suggestions board: https://trello.com/b/WJRNDtkD/hackage-usability-suggestions Issues & bugs board: https://trello.com/b/8YSJ5XYV/hackage-usability-issues If you have a Trello account (it's free to register) you can comment and vote on issues. *Please vote on the issues/suggestions you think are the best or most important*. Feel free to make any relevant comments on the cards as well. To vote simply open the card, look in the "Actions" section and select vote. That's it. If reading through the suggestions/issues makes you think of something new simply comment on the very top card and I can add your new suggestion to the list. *What happens next?* There are two things that I want to achieve: 1. Come up with a list of simple, easy to implement changes that can be done on Hackage/Haddocks 2. Come up with wireframes for a potential future state of Hackage that the community can comment on / contribute to, which encompasses everything learned from the survey Not every suggestion is going to be feasible regardless of how popular it is. Additionally, any suggestions which are feasible have to be implemented by someone. The more enthusiasm there is behind an idea (or issue) the more likely we are to see progress.

2 1

Time performance with inlining and space performance with newtype?
by Rob Stewart 09 Oct '15

09 Oct '15

Hi, I'm in search of clarifications and descriptions about code optimisations that are recommended in GHC docs, regarding inlining and newtype vs data. 1. Inlining small and often used functions See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html , Section "7.22.6.1. INLINE pragma". It says: "GHC tries to inline functions/values that are 'small enough', thus avoiding the call overhead and possibly exposing other more-wonderful optimisations." I understand the reason for function inlining with other languages like C, as it avoids the construction of new stack frames and coordinating stack pointers for each function call. In Haskell, rather than call stack we've got evaluation stacks. Here are my questions: what exactly is the call overhead of a non-inlned Haskell function? What additional runtime work needs to happen when calling to a non-inlined function? Specifically what other GHC optimisations are possible only if function inlining happens first? Can anyone provide a simple example where 1) a function is not inlined, versus 2) when that function is inlined, which demonstrates two things: 1) a GHC report of the additional optimisations that were applied because of inlining and 2) shorter program runtime as a result of inlining. 2. Calculating the memory costs of a data type As Don Stewart nicely explains on SO http://stackoverflow.com/a/5889784/1526266 , we should always use newtype when we have only a single constructor which has a single field. His example is this: data Book = Book Int Int newtype Book = Book (Int, Int) With newtype, the `Book` construct is guaranteed to be erased at compile time, to have the same representation as `(Int,Int)`. How to I measure the memory space costs of having `Book Int Int` hanging around at runtime, as opposed to just `(Int,Int)`? How many bytes does it cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)` ? Can I ask GHC to tell me how many bytes the storage of each object would require? Or more generally, would looking at GHC Core for all my data structures inform me of the memory space costs for each of them? Thanks -- Rob

4 5

Re: [Haskell-cafe] Monad of no `return` Proposal
by Doug McIlroy 09 Oct '15

09 Oct '15

> littering the code with #ifdefs > Bonus points for keeping the #ifdefs centralized Littering is the right word. "Bonus" is merely less negative points. It is ironic that the beautiful Haskell should progress by adopting the worst feature of C. #ifdef is a sticking-plaster for non-portable code. It is inserted at global level, usually to effect changes at the bottom of the code hierarchy. (Maybe in Haskell it should be a monad, in competition with IO for the outermost layer.) Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed) inescapably nonportable code, such as endianity, in compilation units and #include files in a distinct part of the file system tree selected by the shell. Another trick is to use plain if rather than #if or #ifdef, and let the compiler optimize away the unwanted side of the branch. In any event, #ifdef is, as Simon evidently agrees, evidence

3 4

minimizing overhead between c/c++ and Haskell
by Joshua Jordan 08 Oct '15

08 Oct '15

I've been learning Haskell recently and I'm interested in exploring whether something I have in mind is feasible. I have several projects similar to the one below, this is just one example: I have written a plug-in for an existing software (which manages it's own threading, memory, etc). The plug-in interface is in c++ and is wrapped in an extern c call for the final connection to the software. The actual plugin is rather functional in nature, and at its core simply accepts float, int, and string values, does a certain amount of internal processing based on input criteria, and returns float values as a result. I'd like to re-factor it one day, so instead of doing it in c++, it would be interesting to rewrite my plug-in with the logic and structure (with memoization, etc) of the internal processing in Haskell, which is called from the other executable. The processing will be called by the c/c++ threads many millions of times in one run, so perhaps the overhead of separate processes and interprocess communication would be too great, and I'd hope for minimal time overhead between the c/c++ and Haskell calls. I imagine the process might go something like this, after looking over the documentation (Using the FFI with GHC): ------------------------------ -------- -the c/c++ plug-in initializes the GHC runtime in a set-up step -- begin call: repeated many millions of times -the c/c++ threads call the haskell function -the haskell function returns a value to the c/c++ threads -- end calls -after everything is finished, the c/c++ plug-in uninitializes the GHC runtime -------------------------------------- So before attempting this, my questions would be: 1) What do you guys think the overhead in this situation would be? 2) Would you suggest exploring anything besides what I've mentioned, and am I missing anything?

1 0

Well-typed design issue
by Alex 08 Oct '15

08 Oct '15

Hello: I am implementing a high-level protocol which requires the use of various cryptographic primitives. I have the following goals in mind: 1. Allow others to extend the library to use different underlying crypto implementations, ciphers, curves, etc, and 2. Have the library be well-typed so that cryptographic operations are unambiguous, leading to code which can be easily audited. According to the spec, the user is allowed to instantiate the protocol with any combination of supported ciphers and curves, but the high-level operations always remain the same regardless of what primitives are used. Pursuant to the above goals, I've defined two typeclasses, "Cipher" and "Curve". I'm using TypeFamilies to facilitate the creation of data types that are independent of the underlying crypto library. The Cipher typeclass is as follows: class Cipher c where data Ciphertext c :: * data SymmetricKey c :: * data Nonce c :: * data Digest c :: * cipherName :: c -> ByteString cipherEncrypt :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c cipherDecrypt :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext cipherZeroNonce :: Nonce c cipherIncNonce :: Nonce c -> Nonce c cipherGetKey :: SymmetricKey c -> Nonce c -> SymmetricKey c cipherHashToKey :: Digest c -> SymmetricKey c cipherHashToAD :: Digest c -> AssocData cipherHash :: ScrubbedBytes -> Digest c cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c cipherHMAC :: SymmetricKey c -> ScrubbedBytes -> Digest c newtype Plaintext = Plaintext ScrubbedBytes newtype AssocData = AssocData ScrubbedBytes Unfortunately, the spec as written assumes that all variables are blobs of bytes. The issue I'm running in to is that, in my goal to have everything well-typed, my typeclasses are filling up with conversion functions like "cipherHashToKey" and "cipherHashToAD". These type conversions are necessary because I'm required to compute values like "HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign it to a variable whose type is "SymmetricKey c" (hence the need for cipherHashToKey). Is all my effort to write a well-typed library being done in vain? Should I just give up and have all the functions use ByteStrings? -- Alex

3 3

Failing to catch exception
by Michael Jones 08 Oct '15

08 Oct '15

I’m having trouble with an exception that won’t catch and looking for suggestions. Basically, a “fail” inside a “catch” inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException. Details: I’m using Text.Regex.PCRE and the exception comes from a “fail" in unwrap: unwrap :: (Show e) => Either e v -> IO v unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err) Right v -> return v The catch is in this function, catching SomeException: filterTableRow _ record fils = do s <- showRecord record vs <- Control.Exception.catch ( return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils) ) ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool]) return $ foldl (.&.) True vs filterTableRow is called from an unsafeIOToSTM: unsafeIOToSTM $ filterTableRow gridData row’ fil which is called from a wx callback from a button press Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch. Adding -xc to the ghc runtime shows the error: *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: Text.Regex.PCRE.String.matchTest, called from Text.Regex.PCRE.String.unwrap, … user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses")) Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException. Any ideas why it is not caught or some way to debug it?

2 4

ANN: wxInstall Abriline and wxHaskell 0.92.1.0
by Henk-Jan van Tuyl 08 Oct '15

08 Oct '15

L.S., I am happy to announce the installation packages for wxHaskell on Windows, and a new version of wxHaskell: 0.92.1.0 So far, the installation of wxHaskell on Windows has been difficult, but now it is just a matter of downloading an installation package[0][1], unzipping it to the directory where you want to have it installed, and clicking on Install.bat. A detailed description can be found at the wxHaskell-for-Windows homepage[2]. The current configuration of the installation packages (one package for 32 bit and one for 64 bit systems), is called Abriline and contains compiled wxWidgets 3.0.2 and all further necessary DLLs. The installation procedure automatically installs the latest version of wxHaskell and can be used for several of the most recent versions of GHC. In case you are wondering where the name Abriline comes from, it is generated by a girls name generator I wrote (in Haskell of course); I selected this name because a search on Internet seems to indicate that the name is brand new. The new version of wxHaskell is released because it solves a bug that could crash an application. What is wxHaskell? ------------------ wxHaskell[3] is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore built on top of wxWidgets – a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel. Links ----- See the homepage of wxHaskell for more information: https://wiki.haskell.org/WxHaskell The packages are: - wxc https://hackage.haskell.org/package/wxc - wxdirect https://hackage.haskell.org/package/wxdirect - wxcore https://hackage.haskell.org/package/wxcore - wx https://hackage.haskell.org/package/wx Regards, Henk-Jan van Tuyl [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/wxInstall-Abrilin… [1] http://sourceforge.net/projects/wxhaskell/files/wxInstall/wxInstall-Abrilin… [2] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_easy_way [3] https://wiki.haskell.org/WxHaskell -- 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://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0