A nice side effect of supporting Cabal 1.18 (thanks again to dynamic-cabal) is that we can use a sandbox to install the executables we need, like buildwrapper and scion-browser. Up to now, if you hadn't installed them, you'd get a dialog box asking you if you wanted to. Users have complained that this was an unnecessary step, but I didn't want to install executables with many dependencies into the user's package database without a notice. Now, executables get installed into a specific sandbox, so the install may be a bit longer if you already had some dependencies, but we don't mess up anything on your system.
The only issue is that inside a cabal sandbox, all packages need to be coherent: you cannot have two different versions of the same library. This shouldn't normally be an issue, but it is at the moment, because we try to install HLint and SourceGraph, that both require a different version of haskell-src-exts. I have sent a patch to Ivan Lazar Miljenovic so that SourceGraph can support the latest version of haskell-src-exts so hopefully this will be sorted by the time EclipseFP 2.6 hit the metaphorical shelves.
So hopefully EclipseFP 2.6 will be easier to install and will take advantage of the latest Cabal functionality!
Multiple Dispatch as Dispatch on Tuples, by Gary T. Leavens and Todd D. Millstein:
Many popular object-oriented programming languages, such as C++, Smalltalk-80, Java, and Eiffel, do not support multiple dispatch. Yet without multiple dispatch, programmers find it difficult to express binary methods and design patterns such as the "visitor" pattern. We describe a new, simple, and orthogonal way to add multimethods to single-dispatch object-oriented languages, without affecting existing code. The new mechanism also clarifies many differences between single and multiple dispatch.
Multimethods and multiple dispatch has been discussed numerous times here on LtU. While the theory has been fully fleshed out to the point of supporting full-fledged type systems for multiple dispatch, there has always remained a conceptual disconnect between multimethods and the OO model, namely that methods are supposed to be messages sends to objects with privileged access to that object's internal state. Multimethods would seem to violate encapsulation inherent to objects, and don't fit with the conceptual messaging model.
This paper goes some way to solving that disconnect, as multiple dispatch is simply single dispatch on a distinct, primitive class type which is predicated on N other class types and thus supporting N-ary dispatch. This multiple dispatch support can also be retrofitted to an existing single-dispatch languages without violating its existing dispatch model.
The summary for the impatient: some core operations in text and aeson are now much more efficient. With text, UTF-8 encoding is up to four times faster, while with aeson, encoding and decoding of JSON bytestrings are both up to twice as fast.attoparsec 0.11.1.0
Perhaps the least interesting release is attoparsec. It adds a new dependency on Bas Van Dijk’s scientific package to allow efficient and more accurate parsing of floating point numbers, a longstanding minor weakness. It also introduces two new functions for single-token lookahead, which are used by the new release of aeson; read on for more details.text 184.108.40.206
The new release of the text library has much better support for encoding to a UTF-8 bytestring via the encodeUtf8 function. The new encoder is up to four times faster than in the previous major release.
Simon Meier contributed a pair of UTF-8 encoding functions that can encode to the new Builder type in the latest version of the bytestring library. These functions are slower than the new encodeUtf8 implementation, but still twice as fast as the old encodeUtf8.
Not only are the new Builder encoders admirably fast, they’re more flexible than encodeUtf8, as Builders can be used to efficiently glue together from many small fragments. Once again, read on for more details about how this helped with the new release of aeson. (Note: if you don’t have the latest version of bytestring in your library environment, you won’t get the new Builder encoders.)
The second major change to the text library came about when I finally decided to expose all of the library’s internal modules. The newly exposed modules can be found in the Data.Text.Internal hierarchy. Before you get too excited, please understand that I can’t make guarantees of release-to-release stability for any functions or types that are documented as internal.aeson 0.7.0.0
Finally, the new release of the aeson library focuses on improved performance and accuracy. We parse floating point numbers more accurately thanks once again to Bas van Dijk’s scientific library. And for performance, both decoding and encoding of JSON bytestrings are up to twice as fast as in the previous release.
On the decoding side, I used the new lookahead primitives from attoparsec to make parsing faster and less memory intensive (by avoiding backtracking, if you’re curious). Meanwhile, Simon Meier contributed a patch that uses his new Builder based UTF-8 encoder from the text library to double encoding performance. (Encoding performance is improved even if you don’t have the necessary new version of bytestring, but only by about 10%.)
On my crummy old Mac laptop, I can decode at 30-40 megabytes per second, and encode at 100-170 megabytes per second. Not bad!Thanks
I'd particularly like to thank Bas van Dijk and Simon Meier for their excellent contributions during this most recent development cycle. It's really a pleasure to work with such smart, friendly people.
Simon and Bas deserve some kind of an additional medal for being forgiving of my sometimes embarrassingly long review latencies: some of Simon's patches against the text library are almost two years old! (Please pardon me while I grasp at straws in my slightly shamefaced partial defence here: the necessary version of bytestring wasn't released until three months ago, so I'm not the only person in the Haskell community with long review latencies...)
Engineering and research tasks (plotting, file parsing etc) in Haskell, modest programming background
I've recently become interested in learning Haskell, partly out of an intellectual interest in Haskell's "pure" functional programming philosophy, but also in search of a learning a versatile/practical new tool for engineering and research. I posted a question today on /r/learnprogramming/ but haven't yet gotten many responses. I'll ask a bit more specific questions here, since I've spent some more time reading up on Haskell and also since this is a pretty active and mature subreddit where I might get more or better advice.
I'm a PhD student in engineering, and if I remain in academia or take a research-oriented job in consulting, I'll frequently perform numerical computations, read and write from formatted text files/spreadsheets/databases, generate plots of data or parse input for other tools to use. Occasionally solve a set of differential equations or some other symbolic problem too.
I'm intrigued by Haskell, but can't justify the time spent using it unless I can integrate it into my work in the future in lieu of more familiar tools including Matlab, and Python/Scipy, etc. (I'm familiar with the "it will help you think better" argument many advocate---indeed that's the main draw for learning it!---but for practicality, I want to fit it into my workflow as a research scientist or engineer. If it isn't likely to ever become a tool that I can benefit from as a non-full-time programmer, then I could still enjoy the intellectual aspect of learning, but I'd do it leisurely on evenings and call it a hobby).
- Haskell is powerful and elegant for solving algorithmic problems and "helps you think better" but,
- No "out of the box" solution for graphics/plotting,
- Package management is glitchy and may frustrate someone without a background in CS/software development,
- Something something compiler something something,
- The elegance/"pure" aspect of Haskell begins to break down at the boundaries between Functional Programming World and the Real World. This is overcome somehow by something called "monads" which I haven't grokked yet, but they seem to be either mind-blowing or aggravating depending on who you ask.
Now, some stuff I've read seems to indicate other functional languages might meet my needs better---for example Scheme---where pragmatically "breaking the rules" overcomes some of these frustrating issues for beginners. On the other hand, I've got a modest understanding of Linux as a desktop user, occasional small victories at the command line, understand pipes, parsing, and other higher-level languages---and if these other tools helped me leverage the power of Haskell for solving certain problems, that'd be satisfactory. This post about using Haskell the pharmaceutical industry seems to contain the most relevant information for my needs, and it's also reassuring. But maybe some of you can throw out a few pointers...
What kind of approach would be best for me---i.e. no development background, modest scientific computing background, willing to hack around a little bit for solutions---to tackle? Should I go ahead with Haskell? Scheme? Other? Any general advice on availability of graphics library/module/whatever in Haskell? Are they well maintained? How about read & write packages for text files, CSV, XLSX or ODS? Do I need a numerical module to perform efficient matrix operations (is it kosher to call something an "operation" in FP?) If I know how to generate graphics already in Python, or if I adopted a simple tool like (for example) Processing, would I be better off generating plot commands to run elsewhere than trying to make graphics appear in Haskell? Any general workflow advice?
Sorry if some of these questions are poorly formed. I haven't found an abundance of resources that discuss this from an engineering/science/"Matlab-y" perspective---the Haskell community seems to have a lot of programmers and mathematicians, and I can't speak that lingo so well :-)
Thanks.submitted by use_reddit_sparingly
[link] [9 comments]