- Haskell-Cafe - Haskell.org

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

status and future of haskell98 and haskell2010 packages
by Andrey Chudnov 08 Oct '15

08 Oct '15

Hello, My e-mail was rejected from libraries(a)haskell.org (the official maintenance contact of the two packages in question), so I'm trying my luck here instead. Hoping I can get some answers on the following questions: 1. What is the status of `haskell2010` and `haskell98` packages? Are they supported? Deprecated? In need of new maintainers? 2. Assuming the answer to the previous question is "alive and well", are there any plans to release new versions of those for GHC 7.10 and beyond? Thanks in advance, Andrey

2 1

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Brandon Allbery 08 Oct '15

08 Oct '15

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > Please consider that the the way practical development really happens[2] ...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

6 6

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Mark Lentczner 08 Oct '15

08 Oct '15

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > TLDR: To complete the AMP, turn `Monad(return)` method into a > top-level binding aliasing `Applicative(pure)`. > Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. Think of it as Perl 6 or Python 3 for Haskell. - Mark On Tue, Oct 6, 2015 at 1:12 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > (Resending with smaller recipient list to avoid getting stuck in the > moderator queue.) > > On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr(a)gnu.org> > wrote: > >> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: >> > On the libraries I maintain and have a copy of on my computer right >> now: 329 >> >> >> Although this was already pointed out to you in a response to a Tweet of >> yours, I'd like to expand on this here to clarify: >> >> >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. > > Neither AMP or MRP includes a recipe for this in their proposal. AMP got > one post-facto on the Wiki. It turns out that the workaround there didn't > work (we tried it in Cabal and it conflicted with one of the above > requirements.) > > PS: I'm a bit disappointed you seem to dismiss this proposal right away >> categorically without giving us a chance to address your >> concerns. The proposal is not a rigid all-or-nothing thing that >> can't be tweaked and revised. That's why we're having these >> proposal-discussions in the first place (rather than doing blind >> +1/-1 polls), so we can hear everyone out and try to maximise the >> agreement (even if we will never reach 100% consensus on any >> proposal). >> >> So please, keep on discussing! >> > > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. > > What's frustrating is that people don't take a step bad and realize that > they might be in the latter group and should perhaps listen to those in the > former. This doesn't happen, instead we get lots of "C++ and Java so bad > and we don't want to be like them." Haskell is not at risk of becoming C++ > or Java (which are a large improvement compared to the languages came > before them). We're at risk of missing our window of opportunity. I think > that would be a shame, as I think Haskell is a step forward compared to > those languages and I would like to see more software that used be written > in Haskell. > > We've been through this many times before on the libraries list. I'm not > going to win an argument on this mailing list. Between maintaining > libraries you all use and managing a largish team at Google, I don't have > much time for a discussion which approaches a hundred emails and is won by > virtue of having lots of time to write emails. > > -- Johan > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

5 5

quickCheck problem
by Roelof Wobben 08 Oct '15

08 Oct '15

Hello, I have written a function to test if three numbers are the same. Now I want to test my functions by using quickCheck. So I thought to test first if all three are the same. but how can I tell quickcheck that all numbers are the same. and second question : hwo do the test likeif two numbers are the same. I ask this because I try to solve a exercise of the programming Haskell book, IM have read chapter 3 now. Roelof

5 12