- Haskell-Cafe - Haskell.org

ANNOUNCE: mezzolens 0.0.0 & a puzzle
by roconnor＠theorem.ca 12 Oct '15

12 Oct '15

This is a pre-release of mezzolens, a library of first-order functional references based purely on profunctors. I wrote it because https://www.reddit.com/user/Faucelme asked for one. You can find it at https://hackage.haskell.org/package/mezzolens The main purpose of this pre-release is to provide background for framing the following question: In a pure profunctor lens libray, how do you write choosing and beside in such a way that it supports all the following types? choosing :: Lens ta tb a b -> Lens sa sb a b -> Lens (Either ta sa) (Either sa sb) a b choosing :: Traversal ta tb a b -> Travesal sa sb a b -> Traversal (Either ta sa) (Either sa sb) a b choosing :: SEC ta tb a b -> SEC sa sb a b -> SEC (Either ta sa) (Either sa sb) a b beside :: Traversal ta tb a b -> Travesal sa sb a b -> Traversal (Either ta sa) (Either sa sb) a b beside :: SEC ta tb a b -> SEC sa sb a b -> SEC (Either ta sa) (Either sa sb) a b One sufficent solution for choosing would be to write a single function that combines lensVL :: (forall f. Functor f => (a -> f b) -> ta -> f tb) -> Lens ta tb a b traversal :: (forall f. Applicative f => (a -> f b) -> ta -> f tb) -> Traversal ta tb a b into one. The obvious approach is to write an suitable adaptor that transforms any (strong) profunctor into a functor, and if the profunctor is wandering, it produces an applicative functor. But I haven't been able to devise such a suitable adaptor. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

1 0

Final Call for Haskell Prime language committee Nominations!
by Herbert Valerio Riedel 12 Oct '15

12 Oct '15

The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell Prime self-nominations (see also original CfN at [1]) is near! If you have already submitted a self-nomination, please make sure (if it was sent to the haskell-prime list) that it shows up in the mailing list archives at - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or - https://mail.haskell.org/pipermail/haskell-prime/2015-October/ or (if you have only sent it to me directly) that I acknowledged receiving your submission by an email reply. Regards, Herbert Valerio Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

1 0

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

11 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 10 Oct '15

10 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 10 Oct '15

10 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 09 Oct '15

09 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 09 Oct '15

09 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