- 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

Looking for a new maintainer for the template package
by Johan Tibell 07 Oct '15

07 Oct '15

I find myself with too little time to maintain the template package anymore, so I'm hereby announcing that I'm looking for a new maintainer. The template package is a quaint little package for doing Python-style string interpolation. Please email me if you're interested. -- Johan

2 1

Looking for a new maintainer for the network package
by Johan Tibell 07 Oct '15

07 Oct '15

I find myself with too little time to maintain the network package anymore, so I'm hereby announcing that I'm looking for a new maintainer. Since lots of people depend on the network package, the maintainer should probably be someone that values stability. If you want to completely rethink how networking APIs should work in Haskell, this is probably not for you. Please email me if you're interested. -- Johan

1 0

OShack hackathon (offer of help)
by Alexey Shmalko 07 Oct '15

07 Oct '15

Hi! We have the OShack hackathon[1] in Kyiv, Ukraine this weekend. It's a 24-hour hackathon dedicated to Open-Source projects. I with friends want to offer our help of time to any Haskell project that needs it. Just ping me back so we can discuss the details. If you're in Kyiv and want to join our team, we'll be glad to see you! You can also join online. Regards, Alexey Shmalko [1]: http://hackraft.com/hackathon/oshack/

1 0

Re: [Haskell-cafe] Reducing the need for CPP
by Bardur Arantsson 06 Oct '15

06 Oct '15

On 10/06/2015 11:11 AM, Johan Tibell wrote: > It might be enough to just add a NOWARN <warning type> pragma that acts on > a single line/expression. I've seen it in both C++ and Python linters and > it works reasonably well and it's quite general. +1. Simple is good and can hopefully also be backported to older GHC releases. (Provided someone's willing to do said releases, obviously.)

2 1

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 06 Oct '15

06 Oct '15

If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, deadline 31st October 2015. Many thanks, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st October 2015 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st October 2015. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Rustom Mody 06 Oct '15

06 Oct '15

On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: > > 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, telling > evidence of non-portability. It is hard to imagine an uglier > "solution" to keeping up with the drip-drip-drip of Haskell > evolution. > > The python 2→3 transition may have caused some pain to some. However it would have been far more difficult if they had not provided tools like 2to3 and six: https://docs.python.org/2/library/2to3.html http://pythonhosted.org/six/ Since the change here is trivial and pervasive why is such a tool not being considered? [Or have I missed the discussion?] In particular we can envisage a tool say 8to10 that has these modes (command-line flags) --portable --readable --info with the idea that - portable is most unreadable (ifdef litter) - readable is not portable -- generate a copy of the whole source tree that will have the changes and not be compatible for ghc < 7.8 This is for those library authors that prefer to maintain a clean code base and hell with earlier ghc versions - info summarizes which files would change and how so that a suitable reorganization of the files/directories can be done prior to the switch This is for those library authors that would like to take the trouble to have a compatibility layer and have code as readable as possible overall [Whether pure is really preferable to return is another matter -- For me one of the strongest criticisms of the python 2→3 switch is this that if they were going to break things anyhow why was the cleanup not more far-reaching? Lets keep this note in these parentheses :-) ]

2 1

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Mike Meyer 06 Oct '15

06 Oct '15

On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson <spam(a)scientician.net> wrote: > > - To use functions like "tryReadMVar", "unsafeShiftR", and > > "atomicModifyIORef'" that are in recent base versions but not older > ones > > (this is a place where CPP use is actually justified) > Well, yeah, new functions don't magically appear in old versions. I > don't anybody expects that :). > Right - they have to be backported, and imply maintenance of multiple branches. Python has been mentioned a couple of times. They did that, backporting functions that mimiced Python 3 functions to later Python 2 versions, which made the tools mentioned possible, or at least more capable. I'll refer those wanting fewer breaking changes to Python. Getting language changes accepted by the PYthon community is *hard*. You need a use case for your change, you need to show that the case can't be handled cleanly by the language as it exists today, that it's common enough to justify the change, and that it won't tempt people to write uglier code than the current solution. If you want to break old code, all those bars get raised - a lot. Or did, anyway, The result of following that was the Python 2/Python 3 split, which I don't think anybody thought was a good thing. Unavoidable, maybe - Python 3 had to break backwards compatibility, so they cleaned up everything along the way, and created tools to migrate code, and committed to maintaining both versions for an extended period of time. And the community was pretty badly splintered by this. The one thing I think they got right is documenting the language change process with the entire PEP process. We seem to have wiki pages, with no editorial oversight, and pages show up in google searches after they've been incorporated into the language in a different form. Not quite as good a thing.

1 0

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

05 Oct '15

Sorry for the premature send. The incomplete sentence was: In any event, #ifdef is, as Simon evidently agrees, telling evidence of non-portability. It is hard to imagine an uglier "solution" to keeping up with the drip-drip-drip of Haskell evolution. doug

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by mantkiew＠gsd.uwaterloo.ca 05 Oct '15

05 Oct '15

I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in). Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing? Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes. Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ‎Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...). -- Michał [1] http://www.infoq.com/presentations/functional-techniques-complexity On Mon, Oct 5, 2015 at 2:34 PM, Gregory Collins <greg(a)gregorycollins.net> wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb(a)gmail.com> wrote: >> >> My understanding of the argument here, which seems to make sense to me, is >> that the AMP already introduced a significant breaking change with regards >> to monads. Books and lecture notes have already not caught up to this, by >> and large. Hence, by introducing a further change, which _completes_ the >> general AMP project, then by the time books and lecture notes are all >> updated, they will be able to tell a much nicer story than the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require CPP > to fix: > > ~/personal/src/snap λ find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to cause problems and > work for me than it is doing to improve the common infrastructure. > > G > -- > Gregory Collins <greg(a)gregorycollins.net> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

ANN: HaRe 0.8 - The Haskell Refactorer
by Alan & Kim Zimmerman 05 Oct '15

05 Oct '15

I'm pleased to announce the release of HaRe 0.8, available on hackage [1] What's new? =========== Everything, and nothing. Everything in the sense that it has been completely reworked internally to make use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3] library. Nothing in the sense that the functionality in this version is/should be identical to that in 0.7.2.8 Limitations =========== HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. Compiling HaRe with 7.10.2 and then using it against projects using an earlier compiler will not work, as HaRe needs to be able to invoke GHC to the type checker stage on the project using GHC 7.10.2. What is it? =========== HaRe makes changes to working code, so that it still works once the change is made. Refactorings it can do are * demote Take a declaration from the level where it is defined and move it down to the place where it is used. This only works if it is used in one place only. * dupdef Duplicate a definition with a new name. * iftocase Convert an if declaration to a case declaration. * liftOneLevel Move a declaration one level up, adding parameters as needed to pass in locally declared variables. * liftToTopLevel Move a declaration to the top level, adding parameters as needed to pass in locally declared variables. * rename Change a name throughout the project. This makes use of the GHC renamed source so will not change other names that just happen to be lexically identical, but are in fact different names. It currently has an emacs integration only, assistance in supporting other environnments welcome. [1] https://hackage.haskell.org/package/HaRe [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations [3] https://hackage.haskell.org/package/ghc-exactprint Alan

4 6

Teaching haskell at the 42 french school
by Quentin Le Guennec 05 Oct '15

05 Oct '15

Hi, as an introduction, it would be a good advice to first look, if you did not heard of it yet, at what the 42 school is: http://www.42.fr/42-revolutionary-computer-training-free-and-open-to-all/ (TL;DR: *"unique pedagogical approach and accessibility to all, completely free of charge, 42 is the most daring response yet to the challenge of information-technology skill development", "**Innovative teaching methods in technology training: Peer-to-Peer learning"*) The school aims to teach a general knowledge of computer science, but does not provide a Haskell course yet. The exercices and projects are built by students, for students. I love haskell and I'd be really happy to teach that wonderful language, and I'd love to hear your suggestions. I was thinking of the haskell's hard learning way. (I gotta say, the school's pedagogy is pretty sadistic). - Recode List, (,), Either, Maybe and their functor/applicative/monad/etc instances (implying recode those data types first) - String manipulation (basically recode Data.List). Any ideas for prevent students from just copy pasting the hackage code source? - Red black trees are fun, aren't they? - Some kind of AI to solve, for example, Rubik's cube One other thing, this may be very sadistic, but I would like to ask what do you think of allowing ONLY pointfree? It may end-up by having different answers and promote beautiful and concise code. Please expose your ideas, everything is feasible, bonus added to traps, hard to solve problems, and everything that may lead the student to think a lot. Thanks. -- Quentin Le Guennec

2 1

[ANN] PETSc Haskell bindings
by Marco Zocca 05 Oct '15

05 Oct '15

Dear all, development of the Haskell bindings for the PETSc scientific computation library is now public; the repository can be found at https://github.com/ocramz/petsc-hs The interface is still very much experimental and in a state of flow but a number of basic functions are working. I look forward to all feedback; Kind regards, Marco Zocca

1 0

Concept for "equal but unknown"
by martin 05 Oct '15

05 Oct '15

Hello all, there is a problem which popped up a number of times recently and I wondered if there is a general concept to tackle this kind of problems. It goes like this: I book a hotel room. At this time it becomes known that the hotel has one fewer room available, but it is not known which room it is. Likewise I know, that I have a reservation for "a room", but I don't know which one it is. It is however known, that the room in my reservation is the same room the hotel has removed from the list of available rooms. Another example: In air-cargo the cargo company has reserverd space in an aircraft for two containers. One for high-priority parcels and one for low-priority parcels. In the cargo hub, they plan to pack these two containers. At this point in time it is only known that there will be two containers one labelled "high-prio" and the other labelled "low-prio" but their physical identity is not known. Only when you actually do the packing you have a physical container at hand, which has identity. At this moment it becomes clear to which physical containers the reservations refer to and which physical containers are used for packing. I think I can handle this in an imparative style using an extra indirection (think pointers), though even there I would be happy if someone told me something like "this is an example of covariant unification" or something like this. But in haskell I cannot see a solution at all? So: how can I express that two things are equal to each other without knowing the exact value and how do I manage to make both assume a value once one of them becomes known. Do these kind of problems have a name?

5 6

Approach to generalising Functor, is it worth pursuing?
by Clinton Mead 04 Oct '15

04 Oct '15

I've been thinking about generalising Functor, as I had something which was "Functor like" but didn't seem to fit into the existing definition. The example I'll present isn't the problem I was trying to solve, but it probably illustrates the solution better. The questions I have is: 1. Is this useful? 2. Has this been done? If the answers are Yes and No, I'll continue on into making this into a package. Anyway, here's what I've done: As we know, the type signature of fmap is the following: fmap :: Functor f => (a -> b) -> (f a -> f b) I've put brackets around the last two arguments to show that fmap can be also seen as a function which takes a function and returns a new function, in a different "space", for want of a better word. fmap should also follow this rule: fmap (f . g) == (fmap f . fmap g) So we can map an ordinary function into the "Maybe" space, but in a way that composing functions in the putting them in the space is the same as putting them in the space then composing them. I thought it would be nice if we could fmap to Kleisli Arrows, like so: fmap :: Monad m => (a -> b) -> Kleisli m a b Of course this is just "arr". But "arr" follows fmap's rules, so I thought it would be nice to make it a functor. So I was looking for more generalised versions of "Functor", and I found the 'categories' package, which had the following definition: class (Category <https://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Category.html…> r, Category <https://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Category.html…> t) => Functor f r t | f r -> t, f t -> r where fmap :: r a b -> t (f a) (f b) This solves half my problem, as now I can set r = (->) and t = Kleisli m and I've got the categories right. But it forces the "output" category to have a data constructor. So: fmap :: Monad m => (a -> b) -> Kleisli m a b Just won't fit. I'd need to make it: fmap :: Monad m => (a -> b) -> Kleisli m (Id a) (Id b) and then unwrap the results. I found this ugly though. So I've gone with another approached. I've linked the code here: http://ideone.com/TEg4MN and also included it inline at the bottom of this mail. Defining functors now becomes a bit wordy, but basically what I've defined is two functor instances. The first is just a copy of the existing functor instances to maintain the status quo behaviour. But secondly I've defined the Kleisli instance as discussed above. The "main" line, does two calls to fmap. The outermost (on the left) is just an ordinary fmap call on lists. The innermost, fmaps the function "triple" into a Kleisli Arrow, allowing it to be composed with the the Kleisli arrow already defined, 'evenOrNothing'. Type inference works this all out magically without signatures being required. Like I said, is approach new and useful? Improvements would be appreciated also, I'm only over the last few months really started focusing on learning Haskell properly (after leaving my previous job of 8 years), so I'm sure I'm still doing plenty of things not quite right. Thanks, Clinton --- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} module Main ( main ) where import qualified Control.Arrow import Prelude hiding (Functor, fmap, (.)) import Control.Category (Category, (.)) import qualified Data.Functor import qualified Control.Arrow import Control.Arrow (Kleisli(Kleisli), runKleisli) type family F (r :: (* -> * -> *)) (t :: (* -> * -> *)) x type family InputParam f x type family ResultParam f x type family InputCategory f :: (* -> * -> *) type family ResultCategory f :: (* -> * -> *) class Functor f where fmap :: ( Category r, Category t, f ~ F r t c, f ~ F r t d, r ~ InputCategory f, t ~ ResultCategory f, a ~ InputParam f c, b ~ InputParam f d, c ~ ResultParam f a, d ~ ResultParam f b ) => r a b -> t c d data OrdinaryFunctor :: (* -> *) -> * type instance F (->) (->) (f a) = OrdinaryFunctor f type instance InputParam (OrdinaryFunctor f) (f a) = a type instance ResultParam (OrdinaryFunctor f) a = f a type instance InputCategory (OrdinaryFunctor f) = (->) type instance ResultCategory (OrdinaryFunctor f) = (->) instance (Data.Functor.Functor f) => Functor (OrdinaryFunctor f) where fmap = Data.Functor.fmap data KleisliFunctor :: (* -> *) -> * type instance F (->) (Kleisli m) a = KleisliFunctor m type instance InputParam (KleisliFunctor f) a = a type instance ResultParam (KleisliFunctor m) a = a type instance InputCategory (KleisliFunctor m) = (->) type instance ResultCategory (KleisliFunctor m) = Kleisli m instance (Monad m) => Functor (KleisliFunctor m) where fmap = Control.Arrow.arr triple = (*3) evenOrNothing = Kleisli (\x -> if (even x) then Just x else Nothing) main = print $ fmap (runKleisli (evenOrNothing . fmap triple)) [3..6]

2 1

HGamer3D 0.6.2
by Peter Althainz 03 Oct '15

03 Oct '15

Dear All, HGamer3D has some new features with version 0.6.2, see www.hgamer3d.org. Builds on Windows and Linux. with version 0.6 a switch was made towards a simpler structure and a new 3d library. regards Peter

1 0

Re: [Haskell-cafe] Parsing Atom feed link
by Adam Bergmark 02 Oct '15

02 Oct '15

Hi, This sounds like a good change to me! Are you willing to provide a patch (and maybe a testcase??) for this? - Adam On Sun, Sep 27, 2015 at 11:17 PM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On Sat, 26 Sep 2015 10:15:24 +0200 > Francesco Ariis <fa-ml(a)ariis.it> wrote: > > > > > Since you have done the homework and this is rfc compliant, have you > > tried sending an email to the maintainer [1]? > > It seems an uncontroversial change and they are active (last version > > released in 2015), I bet they are be willing to fix this. > > > > [1] http://hackage.haskell.org/package/feed > > I sent the message to the maintainer too. I'm tempted to add a quick > temporary fix to my code, but hopefully this issue will get fixed soon > anyway. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 2

Re: [Haskell-cafe] Concept for "equal but unknown"
by Olaf Klinke 02 Oct '15

02 Oct '15

To me this sounds like the Reader monad: You have a value that depends on something that is yet to be decided upon. data SomeCargo = SomeCargo { decide_attribute1 :: ContainerID -> Attr1 decide_attribute2 :: ContainerID -> Attr2 ... } data ConcreteCargo = ConcreteCargo { attribute1 :: Attr1 attribute2 :: Attr2 } withID :: SomeCargo -> ContainerID -> ConcreteCargo If the type ContainerID is searchable [1] then you can have an Eq instance even for the SomeCargo type. That is, two containers are equal if whenever the same ID gets assigned, they have the same properties. The technical term would be "indistinguishable in all contexts". -- Olaf [1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-fi…

1 0

Call for Contributions - Haskell Communities and Activities Report, November 2015 edition (29th edition)
by Mihai Maruseac 02 Oct '15

02 Oct '15

Dear all, We would like to collect contributions for the 28th edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 30 October 2015 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. The final report might have an index with such projects, provided we get enough such submissions. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac and Alejandro Serrano Mena FAQ: Q: What format should I write in? A: The usual format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2015/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2015/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. _However_, if you don't want/have time to format the entry for LaTeX, you can submit it in any other format possible and we will be happy to convert it for the final report. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/) The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then, PNG being preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

1 0

Haskell Tooling Infrastructure
by Alan & Kim Zimmerman 02 Oct '15

02 Oct '15

Now that I am finally turning back to HaRe, the question of infrastructure again comes up. Basically I woudl like to focus in the tool itself, but it can only be useful if it can deal with real world environments. This means properly managing all the different project and compiler environments, and being integrated into IDEs. The current version uses ghc-mod for the lower level interface, and a simple command line interface for the IDE integration. But I have a definite sense that as a community every tool maker is solving the same problems over and over, from ghc-mod to ide-backend to ghci-ng, and onwards. To start a discussion around some kind of architeccture that tool writers can develop agains, ide's can integrat against and ghc/cabal can eventually internalise, I have put some basic points down at https://github.com/RefactoringTools/HaRe/wiki/Requirements-for-IDE-GHC-inte… Regards Alan

2 2

Candidate Haskell Platform 7.10.2-a for use with OS X El Capitan
by Gershom B 01 Oct '15

01 Oct '15

The new OS X El Capitan release (out today) broke the method that Haskell Platform uses to install itself, due to new security features. In fact, if you upgrade your OS, you are also likely to (slightly) break your existing install. There is now a candidate new installer, available at http://downloads.haskell.org/~platform/7.10.2/Haskell%20Platform%207.10.2-a… Note that it is unsigned and you will have to give it permission to run, the usual way, by right clicking on it, and choosing "open" then explicitly allowing it to run. The central difference between this and the prior installer is just that it installs symlinks to ghc tools in the /usr/local tree rather than the /usr tree since the latter is now off limits due to new OS X security features. If you have a prior install and just want to "fix" it after your OS upgrade, no need to reinstall the whole platform. Just download and run the activate-hs shellscript from here: https://github.com/mzero/haskell-platform/blob/master/hptool/os-extras/osx/… Again, after a bit more testing we'll get this signed and released as the new official platform installer for OS X, but in the meantime, I wanted to make sure people were in the loop. Regards, Gershom

2 1

7.10.2 : Compilation slowdown.
by aditya siram 01 Oct '15

01 Oct '15

Hi all, Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase in compilation time. I understand this is a known issue but since I'm seeing something like a 3x slowdown but not across the board, I thought I'd ask. Compilation time for the library I'm writing has remained about the same. I am seeing the slowdown when compiling executables that use the library. There are no other dependencies except base so I'm guessing it something in my library causing the issue. I lean heavily on the FFI, OverlappingInstances and HList style programming in my library which leads me to believe that one of these is causing it. I am seeing no difference in compilation speeds by adding the per instance OVERLAPPING pragmas. Can anyone advise or instruct me on how to profile the compiler? Thanks! -deech

3 4

ANNOUNCE: Megaparsec – an improved and actively maintained fork of Parsec
by Artyom 01 Oct '15

01 Oct '15

Hello! I'd like to announce the release of Megaparsec, a fork of Parsec that has been in the works for the past 2 months. There's a lot of improvements and bugfixes under the hood – as well as a new test suite with 128 Quickcheck tests covering 80% of code (Parsec has only 3 tests, by the way) – but first I'd like to explain why a fork was needed, since forking a popular library is a pretty drastic measure and should be accompanied by an explanation. (A disclaimer: I've been given permission to announce the library, but I'm neither the author nor an expert on parsing.) Hackage: https://hackage.haskell.org/package/megaparsec Changelog (including a list of differences from Parsec): https://hackage.haskell.org/package/megaparsec/changelog Github: https://github.com/mrkkrp/megaparsec If you ever had any ideas about what Parsec should've done differently, or what amazing new combinators it should include, etc., post your ideas here: https://github.com/mrkkrp/megaparsec/issues Why fork Parsec instead of writing a new library ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are many parsing libraries on Hackage; Parsec was one of the first to appear, and it's still the one that is recommended to beginners when they ask about doing parsing in Haskell. Most other libraries aren't exactly trying to compete with Parsec – instead they explore new directions. Like it or not, it remains a fact that a lot of people are being recommended Parsec, a lot of people are using Parsec, and a lot of people will probably continue to use Parsec since there's no clear alternative to it. Writing a new and *different* library probably won't change it. Even new and *similar* libraries (trifecta and attoparsec are similar enough) haven't removed the need for Parsec, only mitigated it somewhat. Perhaps one day trifecta or something else will completely replace Parsec, but right now we still have to put up with Parsec. So, what we need (or at least what would be nice to have) is simply a better Parsec. What's wrong with original Parsec ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Parsec's development has stagnated long ago; you'd have a hard time getting your pull request merged, even if the only thing it does is fixing a typo (I'm not even talking about anything more controversial than that). Parsec isn't perfect or bug-free, and there *is* a need for those pull requests – just look at its Github page, where you'll find 8 unmerged PRs (and 9 open issues): https://github.com/aslatter/parsec In addition to things that could be fixed but simply aren't, there are some inconveniences (and bugs!) that are hard to fix without breaking backwards compatibility: * “notFollowedBy eof” will just silently not do what you expect it to do (a bug old enough to be considered an undocumented feature) * “<|>” and “many” are redefined and so importing Text.Parsec clashes with Control.Applicative (this can't be trivially fixed in Parsec because its “<|>” has different precedence from Control.Applicative's “<|>”) * you can't wrap Parser into monad transformers (I'm talking about things like “WriterT [String] Parser a” – if this was possible, there'd be no need for “user state” baked into ParsecT) * “Text.Parsec.Token” is not flexible enough for many needs; if you depend on it, one day you may find that you have to copy the whole module to get the behavior you want (look at https://github.com/aslatter/parsec/issues/15 and https://github.com/aslatter/parsec/issues/24, for example). In short, there may be a lot of value in improving Parsec – and that's where Megaparsec comes in. What is Megaparsec and how is it different ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Megaparsec “reboots” the development of Parsec. It's not backwards compatible, but it *is* compatible enough to avoid having to rewrite all Parsec tutorials, and code written for Parsec can be converted to use Megaparsec pretty mechanically. Given that, I would recommend using Megaparsec instead of Parsec from now on, unless you need compatibility with GHCs older than 7.10. Here is a detailed account of some of the bigger changes: === Error reporting === Megaparsec's errors messages are significantly more accurate than Parsec's in some cases, as the following demonstration shows. Parsec: > parseTest (try (string "let") <|> string "lexical") "le" parse error at (line 1, column 1): unexpected end of input expecting "lexical" Megaparsec: > parseTest (try (string "let") <|> string "lexical") "le" parse error at line 1, column 1: unexpected "le" expecting "let" or "lexical" And here's another one, showing off how sometimes “try a <|> b” is a bit less harmful than usual. Just in case, I'm talking about this blog post: http://blog.ezyang.com/2014/05/parsec-try-a-or-b-considered-harmful/ If you don't want to read it in full, the gist of it is that if you use “try” too liberally, Parsec's error messages become much worse than they could be. In this example, we're trying to parse a simple version of Haskell's import statements, which can look either as “import Foo” or “import qualified Foo as B”. If you write a parser like this: try pQualifiedImport <|> pImport you will get an uninformative error message on the following input: import qualified Foo s B Specifically, the “try pQualifiedImport” branch will fail, and then the “pImport” branch will stumble upon “qualified” – while the actual error isn't there, but in misspelled “as”. The advice given in the blog post (“The scope of backtracking try should be minimized”) is good, and applies to Megaparsec just as well as it applies to Parsec. However, a curious thing is that in this particular case Parsec *should* be able to tell you that the error is in misspelled “as”, because Parsec implements the longest match rule – errors that occur later in text are given precedence over errors that occur earlier. The code is there, but somehow it doesn't do what it's supposed to do (and Megaparsec fixes that). Here's the code from the article, rewritten for Megaparsec: import Text.Megaparsec import qualified Text.Megaparsec.Lexer as L data Stmt = QualifiedImport String String | Import String deriving (Show) pStmt = try pQualifiedImport <|> pImport pImport = do keyword "import" Import <$> upperCaseIdentifier pQualifiedImport = do keyword "import" keyword "qualified" QualifiedImport <$> upperCaseIdentifier <*> (keyword "as" *> upperCaseIdentifier) upperCaseIdentifier = lexeme $ (:) <$> upperChar <*> many (alphaNumChar <|> oneOf "_.") lexeme = L.lexeme (hidden space) keyword = L.symbol (hidden space) And here are the error messages it produces. Megaparsec: > parseTest (pStmt >> eof) "import qualified Foo s B" parse error at line 1, column 22: unexpected 's' expecting "as" Parsec (with minor modifications): > parseTest (pStmt >> eof) "import qualified Foo s B" parse error at (line 1, column 8): unexpected "q" expecting uppercase letter === Integration with monad transformers === The key type of Parsec is “ParsecT” (others, such as “Parsec” and “Parser”, are just type synonyms). It lets you use parsers with other monads – for instance, if you use “ParsecT String () IO”, you can have IO in your parsers. This is the reason, by the way, why “char” has the type char :: Stream s m Char => Char -> ParsecT s u m Char instead of a simpler char :: Char -> Parser Char (If it was the latter, you wouldn't be able to use “char” and IO in the same parser.) However, even this type isn't general enough for all things you might want to do. Imagine that you want some parsers to generate warnings when they are run, and later you want to collect those warnings and do something with them. This sounds like what Writer was invented for, so you try to use it. Now all your parsers have this type: ParsecT String () (Writer [Warning]) (Where “Warning” is, say, a synonym for String.) Unfortunately, this is not how you should've composed ParsecT and Writer, because this way you don't get backtracking – in other words, if you try to do optional (try someParser) and someParser generates warnings but then fails, “optional” won't be able to make them disappear – they will still be recorded. Same with State – if you do x <* notFollowedBy y and “y” changes the state, this change will be recorded even tho it's not what you want most of the time. (You can use Parsec's internal state and it *will* work, but it doesn't help you when you want to use Writer or something else instead of State.) What you want in such situations is WriterT [Warning] Parser () StateT YourState Parser () ... but you can't get it because “char” and all other primitive parsers simply don't have those types. With Parsec, the only solution is to apply “lift” to all parsers you want to use, which is pretty annoying. Megaparsec solves this by introducing an mtl-style “MonadParsec” class, making primitive parsers members of this class, and providing instances of MonadParsec for various monad transformers. (If you have ever used the ‘parsers’ library, you may recognise this approach.) I think being able to get backtracking behavior without relying on inelegant ways like “Parsec user state” is pretty neat, even if it's not something every Parsec user needs. === Lexing === Parsec has a lexing module (Text.Parsec.Token): http://hackage.haskell.org/package/parsec/docs/Text-Parsec-Token.html If you're not familiar with lexing, the idea is as follows. When you are parsing a programming language, you often have to solve the same set of problems – parsing numbers, string literals (with all those escaping rules), identifiers/operators/keywords, comments, making all parsers handle whitespace (since there can be whitespace between pretty much any 2 tokens), and so on. With “Text.Parsec.Token” you could just specify what counts as whitespace, as a comment, as an identifier character, etc. and get a set of parsers “for free”. Parsec achieves this by defining a huge structure called “GenLanguageDef” that contains the specification of your language: data GenLanguageDef s u m = LanguageDef { commentStart :: String, commentEnd :: String, commentLine :: String, nestedComments :: Bool, identStart :: ParsecT s u m Char, identLetter :: ParsecT s u m Char, opStart :: ParsecT s u m Char, opLetter :: ParsecT s u m Char, reservedNames :: [String], reservedOpNames :: [String], caseSensitive :: Bool } Then you use “makeTokenParser” on it to generate another huge structure containing lots of useful parsers: makeTokenParser :: GenLanguageDef ... -> GenTokenParser ... data GenTokenParser s u m = TokenParser { identifier :: ParsecT s u m String, operator :: ParsecT s u m String, charLiteral :: ParsecT s u m Char, stringLiteral :: ParsecT s u m String, natural :: ParsecT s u m Integer, integer :: ParsecT s u m Integer, float :: ParsecT s u m Double, lexeme :: forall a. ParsecT s u m a -> ParsecT s u m a, parens :: forall a. ParsecT s u m a -> ParsecT s u m a, braces :: forall a. ParsecT s u m a -> ParsecT s u m a, comma :: ParsecT s u m String, colon :: ParsecT s u m String, ... } What's the problem with this approach? It's very inflexible – the moment you want to change something that wasn't supposed to be changed, you're on your own. Do you want to special-case “-- |” comments to use them as doc strings? The easiest solution is to copy the whole module into your own project: https://github.com/aslatter/parsec/issues/15 Do you want to handle newlines by yourself (for instance, to allow them to be expression separators)? The easiest solution is to fork Parsec: https://github.com/aslatter/parsec/issues/24 (Even if those turn out not to be the easiest solutions, it's still somewhat telling that they were what the authors ended up with.) Megaparsec uses a simpler, more flexible approach. See the docs here: https://hackage.haskell.org/package/megaparsec/docs/Text-Megaparsec-Lexer.h… The linked module provides 3 categories of functions: * “integer”, “decimal”, “float”, “charLiteral”, etc are generic parsers that you can use to parse... well, things that they are named after. Some of those – like “integer” – are occasionally useful even if you're not parsing any languages (how often did you have to write “read <$> many1 digit”? now you don't have to). * “skipLineComment” and “skipBlockComment” generate comment parsers, and “space” combines them together. You can make comment parsers arbitrarily complex before passing them to “space”, or you can write your own space-skipping combinator. * “lexeme”, “symbol”, and “symbol'” make lexemes out of things; a lexeme, by convention, expects no leading whitespace and skips all trailing whitespace. So, instead of having parsers being passed to each other under the hood, you now have to pass them by yourself – except that you don't actually have to do much passing, because you can just write import qualified Text.Megaparsec.Lexer as L lexeme = L.lexeme space symbol = L.symbol space and off you go: keyword = label "keyword" . symbol parens = between (symbol "(") (symbol ")") ... etc ... How you can help ~~~~~~~~~~~~~~~~ * Take a project, modify it to use Megaparsec, file an issue if you've encountered any difficulties. * Take a Parsec tutorial and rewrite it for Megaparsec. (And then please send an email so that a link to your tutorial could be added to the README file.) * As I've already mentioned before, if you have any ideas about what could be changed/improved in Parsec, they likely apply to Megaparsec as well – propose them on the issue tracker. * Report typos in documentation (same goes for mistakes, unclear phrasing, etc). If you're shy (like me) and don't like opening issues, just ping me on IRC (I'm “indiagreen” on Freenode) if you spot anything.

6 6

SURVEY: How do you use Hackage?
by Rick Dzekman 01 Oct '15

01 Oct '15

I recently posted some criticisms of the Haskell User Experience on my site. Afterwards Greshom B. and I had a brief chat over email about any recommendations I had. I suggested that the first step in improving the User Experience of any product is research. I think Hackage is something that needs looking at and we agreed that getting some qualitative data was really important. This survey is an attempt to find out how different people use Hackage. If you're able to participate in the survey, you can either submit a response on this webform <https://docs.google.com/forms/d/1YTqI4BNTQ5PHipsJqxvPMnLsxvz6GA_yHm_fO6RhK8…> or submit a response on Reddit <https://www.reddit.com/r/haskell/comments/3n0vaw/survey_how_do_you_use_hack…> . If you have any questions or comments please feel free to email: haskell-usability-survey(a)haskell.org Thanks, Rick Dzekman

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 145, Issue 41
by David Banas 30 Sep '15

30 Sep '15

Thanks for your reply, Tom. That last expression doesn’t seem to have the correct type: Prelude Control.Applicative> let l1 = \x f -> pure f <*> x Prelude Control.Applicative> :t l1 l1 :: Applicative f => f a -> (a -> b) -> f b Prelude Control.Applicative> let l2 = \x f -> fmap f x Prelude Control.Applicative> :t l2 l2 :: Functor f => f a -> (a -> b) -> f b Prelude Control.Applicative> let l3 = \x f -> ($ x) <*> pure f Prelude Control.Applicative> :t l3 l3 :: a1 -> a -> (a1 -> a -> b) -> b Is there a typo? Thanks, -db On Sep 29, 2015, at 9:08 AM, haskell-cafe-request(a)haskell.org wrote: > Message: 2 > Date: Tue, 29 Sep 2015 16:40:38 +0100 > From: Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Question, re: Typeclassopedia Ex. 4.2.1 > Message-ID: <20150929154037.GS14111@weber> > Content-Type: text/plain; charset=us-ascii > > On Tue, Sep 29, 2015 at 07:48:05AM -0700, David Banas wrote: >> pure (flip ($)) <*> x <*> pure f = (interchange) >> pure (flip ($)) <*> pure ($ f) <*> x = (homomorphism) > > For one thing, this step doesn't look right. <*> does not associate that > way. > > It's probably worth at least putting each expression into ghci to check they > have the same time > > Prelude> import Control.Applicative > Prelude Control.Applicative> let l = \x f -> pure (flip ($)) <*> x <*> pure f > Prelude Control.Applicative> :t l > l :: Applicative f => f a -> (a -> b) -> f b > Prelude Control.Applicative> let l2 = \x f -> pure (flip ($)) <*> pure ($ f) <*> x > Prelude Control.Applicative> :t l2 > l2 :: Applicative f => f (((a -> b1) -> b1) -> b) -> a -> f b > > I imagine you're probably going to want to go via ($ x) rather than ($ f), > and possibly use that 'pure f <*> x = fmap f x = ($ x) <*> pure f'. > > Tom

1 0

Initial public release of Haskell bindings for SLEPc
by Marco Zocca 30 Sep '15

30 Sep '15

Dear all, I have published the first version of my Haskell bindings for the SLEPc parallel eigenproblem library; it's available at https://github.com/ocramz/slepc-hs So far, only the most basic functionality is wrapped, and there is no exception control or high-level types and combinators, but it showcases a number of aspects of Haskell foreign-function interface design (using `inline-c`). I am also developing Haskell bindings for PETSc, thanks to the similar design of the two libraries, and I hope to release it before the end of the year. My biggest hope however is to contribute to the conversation between the functional programming and high-performance computing communities, as I feel the expressiveness and correctness guarantees provided by the former can be of great advantage to the latter. I look forward to your feedback; Kind regards, Marco Zocca

1 0

Haskell Weekly News
by Kim-Ee Yeoh 30 Sep '15

30 Sep '15

*Top picks:* - Neil Mitchell reports a stack overflow with 7.10.2 maximumBy <https://ghc.haskell.org/trac/ghc/ticket/10830> that regresses from 7.8.3. His sixth sense points to the Foldable-Traversable coup <https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP> (aka BBP: Burning Bridges Proposal) as culprit. Joachim Breitner investigates and verifies that the bug's indeed caused by BBP's redefinition of maximumBy that changed out foldl1 for foldr1. Neil guesses that with foldl1, "the strictness analysis managed to kick in and optimise things." Joachim opines that "this is more a BBP design issue than a compiler bug." For now, roll your own maximumBy if you're affected. - A reddit question <https://www.reddit.com/r/haskell/comments/3jvyf7/services_for_learners/> asks whether there's a way for "haskell learners to learn haskell from haskell gurus, one-on-one for a fee?" An answer points to CodeMentor <https://www.codementor.io/haskell-experts> where haskellers charge from $15 to $60 per quarter-hour of consultation. Heinrich Apfelmus chimes in to say he's at HackHands <https://hackhands.com/>. - Yair Chuchem, who worked at Google for a year, reveals <https://www.reddit.com/r/haskell/comments/3ij91q/who_works_at_google_and_ho…> how a software engineer's performance metric is gamed to the detriment of the Organizer of the World's Information. Not quite Wally's "I'm gonna write me a new minivan this afternoon" <http://dilbert.com/strip/1995-11-13> but close. To the indignation of his managers, Yair left Google to work with Eyal Lotem on his passion: an Abstract-Syntax-Tree-driven IDE called Lamdu <http://peaker.github.io/lamdu/>, which redditors have already unpacked here <https://www.reddit.com/r/haskell/comments/3k8ek3/lamdu_blog_designing_progr…> . - Ph.D. student Rob Zinkov <http://zinkov.com/posts/2015-08-25-building-a-probabilisitic-interpreter/> demoes a rudimentary Probabilistic Programming Interpreter based on importance sampling. *Quotes of the Week:* - User kyllo on HN: <https://news.ycombinator.com/item?id=10276498#up_10277862> It's an exciting time for Haskell developers right now, we just got an a awesome new build tool (stack), an incredible new server-side framework (servant) and our compile to JS tool (GHCJS) is improving by leaps and bounds. - @gfixler: Was OOP created as a business model to sell complex tooling? @jonruttenberg: <https://twitter.com/jonruttenberg/status/638329205483249664> @gfixler Was #haskell created as a business model to sell complex blog posts? - User breadbox on HN observes: <https://news.ycombinator.com/item?id=10122333#up_10126413> "People think that confidence follows skills, but it’s usually the other way around where skills follow confidence." This is a fact that really needs to be more widely acknowledged. (It also casts the microagressions that have the effect of chipping away at the confidence of women and minorities in a rather uncomfortable light.) - User mgrennan on HN: <https://news.ycombinator.com/item?id=10122784#up_10123667>I understand it is our nature to push away from parents to strike out on our own. I also understand why older people resist change. Magic happens when the young seek to understand the wisdom of their elders and elders hold on to explorer spirit of their youth. -- Kim-Ee

1 0

Haskell Engineer Needed for Machine Learning Startup
by Charles Weitzer 30 Sep '15

30 Sep '15

Voleon Capital Management LP is a startup quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer with strong functional programming experience as soon as possible. Voleon's founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon's team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well. Here is our formal job description: ********************************************************** * Senior Software Engineer * Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems. The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm's offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, catered lunches, and competitive benefits packages. We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus. We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential. Required experience: - strong experience developing in a functional programming environment (Haskell, Erlang, others). - developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness. - working in TCP/IP networking, multi-threading, and server development. - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.). - architecting and designing highly available systems. - architecting and designing large-scale data management infrastructure. - working in large codebases and building modular, manageable code. Preferred experience.: - debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc. - working with build and test automation tools. - working with well-defined change management processes. - diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc. - working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems. Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring. Benefits and compensation are highly competitive. ********************************************************** The above job description is just a starting point in terms of possible duties and seniority. We can be very flexible for the right person. If you are interested please apply on our website: http://voleon.com/apply/. If you have any questions or if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details. Thank you, Charles Weitzer Senior Recruiter Voleon Capital Management LP Office: 510.704.9870 x 7012 Mobile: (510) 558-9182 www.Voleon.com<http://www.voleon.com/>

1 0

Data.Foldable.all and empty list
by Lana Black 30 Sep '15

30 Sep '15

Hello, Is there any particular reason why the 'all' function returns True when supplied with an empty list (or any other foldable)? I'm aware that it is implemented via All monoid instance, my question is whether this behaviour is intentional or it can be considered a bug.

5 4

Parsing, infixes and on-the-fly precedence
by Jeffrey Brown 29 Sep '15

29 Sep '15

I imagine a parser that operates on (String,[String]) pairs, for which the second element allows the user to define precedence on the fly. For instance, it would read the pair (x,y) = ("a , b : c", [":" , ","]) as "(a , (b : c))" because y informs the parser that in x the colon binds first, then the comma. I know it is possible, because Haskell does it already! In Haskell we can define novel infix operators on the fly, including their precedence relative to each other. I don't know how, though, so that's my question. -- Jeffrey Benjamin Brown

4 5

Question, re: Typeclassopedia Ex. 4.2.1
by David Banas 29 Sep '15

29 Sep '15

Hi all, In trying to solve exercise 4.2.1 in Typeclassopedia, I’ve come up with the following: To prove: pure f <*> x = pure (flip ($)) <*> x <*> pure f Proof: pure (flip ($)) <*> x <*> pure f = (interchange) pure (flip ($)) <*> pure ($ f) <*> x = (homomorphism) pure (flip ($) ($ f)) <*> x = (definition of flip) pure ($ ($ f)) <*> x = (interchange) x <*> pure ($ f) = (interchange) (Is this step valid?) pure f <*> x Is the last step in my proof valid? Thanks, -db

2 1

Using Parsec with a recursive data as the stream
by Matteo Ferrando 28 Sep '15

28 Sep '15

Hello, I've posted this question in StackOverflow[1], but I thought this would be a good place to ask too: I'm writing an interpreter for functional programming language with with *mixfix operators*, just like Agda[2]. I used their paper[3] as reference. if_then_else_ : Bool -> a -> a -> a if True then x else _ = x if False then _ else x = x _/\_ : Bool -> Bool -> Bool True /\ True = True _ /\ _ = False So that means I had to run a parser (I used Alex/Happy), to get an AST, with this specific part (smaller than actual `Expr`): data Expr = Id String | Apply [Expr] | Forall Type Expr data Type = TypeBind String Expr And with this `Expr`, I have to run a second parser (which I intend to use Parsec) to do the following kind of processing: λ let example = Apply [Id "if", Id "a", Id "/\\", Id "b", Id "then", Id "c", Id "else", Id "d"] λ parseMixfix example Right (Apply [Id "if_then_else_",Apply [Id "_/\\_",Id "a",Id "b"],Id "c",Id "d"]) I started with a Parser that received a `Stream` of `[Expr]`, but this only accepts the lists in a `Apply`, and doesn't go deep in the *tree*, just parses on the top level. So I'm considering the option of instead of using `[Expr]` as the `Stream`, to use `Expr`, having to do the `Stream` instance for it; this is where I'm at: data Tok a = This a | Over (Tok a) deriving (Show) instance (Monad m) => Stream Expr m (Tok Expr) where uncons ex = check ex where check :: Monad m => Expr -> m (Maybe (Tok Expr, Expr)) check ex = case ex of Id s -> return $ Just (This (Id s), Apply []) Apply (x:xs) -> do mst <- check x return $ fmap (\(a, b) -> (Over a, b)) mst Which is using `data Tok` as kind of a Zipper breadcrumb (or at least I see it that way), to indicate how deep in the tree it comes from. I know this is not the correct code, but is for you folks to get the idea. I'm wondering if I'm on the right track or if there's a better solution for this problem. I'm also missing the `Forall` case here; that's because I was making tests with an `Id | Apply` only tree before. [1]: http://stackoverflow.com/posts/32831287 [2]: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Mixfix [3]: http://www.cse.chalmers.se/~nad/publications/danielsson-norell-mixfix.pdf

1 0

Fmap and Map for lists
by Strikingwolf2012 . 28 Sep '15

28 Sep '15

Does anyone have any idea why fmap (Functor map) and the list map are separate functions? I think it would make plenty sense for the Functor map to just be named map and have lists respond to that

2 1

Re: [Haskell-cafe] Parsing Atom feed link
by Francesco Ariis 27 Sep '15

27 Sep '15

On Sat, Sep 26, 2015 at 10:59:12AM +0300, fr33domlover wrote: > Hello, > > I'm using the package 'feed' to parse news feeds and I noticed it fails to > parse the item links of many feeds! I investigated and apparently here is why. > Many Atom feeds in practice seem to publish their item links like this: > > <link href="http://....."/> Checking the code [1] it looks like it is indeed the case linkRel = Right `fmap` pAttr "rel" e [1] http://hackage.haskell.org/package/feed-0.3.10.1/docs/src/Text-Atom-Feed-Im… > I looked at the examples at https://tools.ietf.org/html/rfc4287 and I just > checked Octopress (Ruby) and Ikiwiki (Perl) generated feeds. The RFC's examples > have item links without "alernate" (as the only item link provided) and both > generators I mentioned create feed item links without "alternate". > > > Should 'feed' be fixed to recognize them? Since you have done the homework and this is rfc compliant, have you tried sending an email to the maintainer [1]? It seems an uncontroversial change and they are active (last version released in 2015), I bet they are be willing to fix this. [1] http://hackage.haskell.org/package/feed

2 1

Solutions to Typeclassopedia Ex. 3.3.1?
by David Banas 27 Sep '15

27 Sep '15

Would anyone care to share their solution to exercise 3.3.1 in Typeclassopedia? Thanks, -db

4 4

Constrain Symbol to contain only alphabetic characters
by Alexander Vieth 27 Sep '15

27 Sep '15

Hi Café, Is it possible to do this? I looked through the source for GHC.TypeLits on hackage but found no leads. Thanks for any help, Alex

2 1

STM implementation
by Nicola Gigante 26 Sep '15

26 Sep '15

Hi all, I’m considering the idea of hacking into the STM implementation, but the source in rts/STM.c seems rather dense. Is there some documentation about the internals or some place to start to understand what’s going on? Thank you, Nicola

3 4

Bologna Haskell Meeting, 2015-10-17 @ 9:30
by m 26 Sep '15

26 Sep '15

Dear all, a Bologna Haskell Meeting will take place on Saturday, October 17 at 9:30. For details see here: https://www.eventbrite.it/e/biglietti-incontro-autunnale-haskell-ita-a-bolo… The page is in Italian and English: the main event is in Italian but many people speak English and we will try to include as many participants as possible. If you would like to give a talk, drop a note to Haskell_ITA(a)googlegroups.com (there is probably still a free slot at the beginning or at the end of the evening). In the same building there will also be an Elixir meeting: https://www.eventbrite.it/e/biglietti-bologna-elixir-erlang-meetup-18440536… (but we have a bigger and better meeting room ...) and participants to a meeting can also lurk the other event. Everybody is welcome! And if you are interested in participating to the event, please buy a ticket on Eventbrite (it is free) just for the meeting that you plan to attend to. Thanks, and see you in Bologna, if you happen to be around. P.S.: if anybody is travelling and needs further information about hotels, travel, etcetera, feel free to contact me directly, I'll be glad to help. -- .*. finelli /V\ (/ \) -------------------------------------------------------------- ( ) Linux: Friends dont let friends use Piccolosoffice ^^-^^ -------------------------------------------------------------- A mother takes twenty years to make a man of her boy, and another woman makes a fool of him in twenty minutes. -- Frost

1 0

Parsing Atom feed link
by fr33domlover 26 Sep '15

26 Sep '15

Hello, I'm using the package 'feed' to parse news feeds and I noticed it fails to parse the item links of many feeds! I investigated and apparently here is why. Many Atom feeds in practice seem to publish their item links like this: <link href="http://....."/> But in the 'feed' package, a link is taken to be an item link only if its relation is alternate, i.e. add an attribute rel="alternate". So for these feeds it returns 'Nothing' for 'getItemLink'. A quick workaround is to go over the links manually of course, which solves the issue locally, but I think it should be solved more generally. Is the problem in 'feed' which recognizes links incorrectly, or do those Atom feeds simply use the wrong way to publish item links? Are they required to use "alternate"? I looked at the examples at https://tools.ietf.org/html/rfc4287 and I just checked Octopress (Ruby) and Ikiwiki (Perl) generated feeds. The RFC's examples have item links without "alernate" (as the only item link provided) and both generators I mentioned create feed item links without "alternate". Should 'feed' be fixed to recognize them? From the RFC: atom:link elements MAY have a "rel" attribute that indicates the link relation type. If the "rel" attribute is not present, the link element MUST be interpreted as if the link relation type is "alternate". --fr33

1 0

ANN: stack-0.1.5.0
by Emanuel Borsboom 25 Sep '15

25 Sep '15

New version released of stack, a build tool. See README <https://github.com/commercialhaskell/stack#how-to-install> for installation and upgrade instructions. Note: the binary tarballs’ contents have changed, and they now enclose their contents in a directory, and include documentation. If you have a script that should only extract the stack executable, use something like tar xzf stack-0.1.5.0-x86_64-osx.tar.gz --strip-components=1 stack-0.1.5.0-x86_64-osx/stack. MinGHC installers <https://github.com/fpco/minghc/releases> have also been updated to include this version of stack (and will continue to be updated for future releases). Major changes: - On Windows, we now use a full MSYS2 installation in place of the previous PortableGit. This gives you access to the pacman package manager for more easily installing libraries. - Support for custom GHC binary distributions #530 <https://github.com/commercialhaskell/stack/issues/530> - ghc-variant option in stack.yaml to specify the variant (also --ghc-variant command-line option) - setup-info in stack.yaml, to specify where to download custom binary distributions (also --ghc-bindist command-line option) - Note: On systems with libgmp4 (aka libgmp.so.3), such as CentOS 6, you may need to re-run stack setup due to the centos6 GHC bindist being treated like a variant - A new --pvp-bounds flag to the sdist and upload commands allows automatic adding of PVP upper and/or lower bounds to your dependencies Other enhancements: - Adapt to upcoming Cabal installed package identifier format change #851 <https://github.com/commercialhaskell/stack/issues/851> - stack setup takes a --stack-setup-yaml argument - --file-watch is more discerning about which files to rebuild for #912 <https://github.com/commercialhaskell/stack/issues/912> - stack path now supports --global-pkg-db and --ghc-package-path - --reconfigure flag #914 <https://github.com/commercialhaskell/stack/issues/914> #946 <https://github.com/commercialhaskell/stack/issues/946> - Cached data is written with a checksum of its structure #889 <https://github.com/commercialhaskell/stack/issues/889> - Fully removed --optimizations flag - Added --cabal-verbose flag - Added --file-watch-poll flag for polling instead of using filesystem events (useful for running tests in a Docker container while modifying code in the host environment. When code is injected into the container via a volume, the container won’t propagate filesystem events). - Give a preemptive error message when -prof is given as a GHC option #1015 <https://github.com/commercialhaskell/stack/issues/1015> - Locking is now optional, and will be turned on by setting the STACK_LOCK environment variable to true #950 <https://github.com/commercialhaskell/stack/issues/950> - Create default stack.yaml with documentation comments and commented out options #226 <https://github.com/commercialhaskell/stack/issues/226> - Out of memory warning if Cabal exits with -9 #947 <https://github.com/commercialhaskell/stack/issues/947> Bug fixes: - Hacky workaround for optparse-applicative issue with stack exec --help #806 <https://github.com/commercialhaskell/stack/issues/806> - Build executables for local extra deps #920 <https://github.com/commercialhaskell/stack/issues/920> - copyFile can’t handle directories #942 <https://github.com/commercialhaskell/stack/pull/942> - Support for spaces in Haddock interface files fpco/minghc#85 <https://github.com/fpco/minghc/issues/85> - Temporarily building against a “shadowing” local package? #992 <https://github.com/commercialhaskell/stack/issues/992> - Fix Setup.exe name for —upgrade-cabal on Windows #1002 <https://github.com/commercialhaskell/stack/issues/1002> - Unlisted dependencies no longer trigger extraneous second build #838 <https://github.com/commercialhaskell/stack/issues/838>

1 0

Munich Haskell Meeting, 2015-09-28 @ 19:30
by Christian Neukirchen 25 Sep '15

25 Sep '15

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 28 at Cafe Puck at 19h30. For details see here: http://chneukirchen.github.io/haskell-munich.de/dates (http://www.haskell-munich.de/ is currently out of order, but will be restored soon!) If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2015/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0