- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Mathematics and Statistics libraries
by Vivian McPhail 28 Mar '12

28 Mar '12

Date: Sun, 25 Mar 2012 17:54:11 +0400 > From: Aleksey Khudyakov <alexey.skladnoy(a)gmail.com> > Subject: Re: [Haskell-cafe] Mathematics and Statistics libraries > To: haskell-cafe(a)haskell.org > Message-ID: <4F6F2383.6070404(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 25.03.2012 14:52, Tom Doris wrote: > > Hi Heinrich, > > And of course data visualization. Only library I know of is Chart[1] but > I don't like API much. > There is the plot[1] library which provides for updateable plots from GHCi REPL and has a gnuplot-like interface. I wrote it for this very reason, a mathematics/statistics development environment. It uses Data.Vector.Storable, which provides for compatability with both statistics and hmatrix packages (as well as hstatistics). > > I think talking about data frames is a bit pointless unless we specify > what is data frame. Basically there are two representations of tabular > data structure: array of tuples or tuple of arrays. If you want first go > for Data.Vector.Vector YourData. If you want second you'll probably end > up with some HList-like data structure to hold arrays. > > Matrices from hmatrix are easily converted to rows or columns of Data.Vector.Storable and can be sliced and otherwise manipulated. [1] http://hackage.haskell.org/package/plot<%20%20[1]%20http://hackage.haskell.org/package/plot> Vivian

2 1

GSoC project idea: haskell-type-exts
by Niklas Broberg 28 Mar '12

28 Mar '12

See ticket here: http://hackage.haskell.org/trac/summer-of-code/ticket/1620 == What? == The haskell-src-exts library (HSE) is very popular for manipulating Haskell source code in a wide range of scenarios, such as (syntactic) preprocessors (e.g. hsx), syntax highlighting, refactoring and code inspection (e.g. hlint), etc. A commonly sought feature, that would enable a multitude of new and improved scenarios, is the ability to type-check the code, and annotate the AST with type information. Type-driven refactoring, type-aware code inspection, type-based preprocessing, ... Lots of pure awesomeness lies in that direction. Sadly, HSE has no type-checking abilities. For those who seek such, we are forced to point in the direction of the dark cave that is the GHC API. While GHC is an utterly awesome compiler, there are several reasons why this is not an ideal situation. First, GHC was designed and built for optimization, which means that even the early stages of the compilation pipeline contain features that cater to later optimization, but that are (at best) unnecessary for a front-end tool. Second, the API into GHC internals is defined as an afterthought. Some good work has been done to make it somewhat palatable, but it remains a fact that GHC's primary purpose is not to be a library for integration in tools, and this shows. Overall, depending on GHC when all you want is front-end capabilities like parsing and typechecking, is really like using the proverbial sledge hammer. Also, at the meta level, GHC deserves "competition". Right now GHC is de facto the only implementation of Haskell, and as such it more or less defines the progress of Haskell. Too often this leads to overly pragmatic choices, which lead to inconsistencies and headaches for tool programmers. Having a separate, stand-alone front end library would help set higher standards. So - what we need is a type checker that works on the HSE AST: haskell-type-exts! == How? == I now hear you think: "This is too much, an enormous project, surely it can't be done as a GSoC project?" Sure it can! By walking in the footsteps of giants, and following GHC's approach. This can be achieved by closely observing the documentation provided by [1] and [2], with a bit of [3] thrown into the mix. I already have a basic library that provides most of the core framework necessary to cover extensions, but at this time it's mostly just scaffolding. It needs a lot of love, to provide cover for all the various available extensions, but I'm confident it can be done satisfactorily as a GSoC project. Still, it would be reasonable to modularize the task. Certain features are more crucial than others to support, simply because they have a more profound impact on the overall type-checking. Higher-rank types, GADTs and type families (and fundeps) are likely the most important ones to get right. There are also some design issues to get right (e.g. using pure substitution vs efficient mutable variables). I (Niklas Broberg) am more than willing to mentor this project. == Further reading: == [1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. [2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions [3] M. P. Jones. Typing Haskell in Haskell

1 0

Regarding Haskell FFI
by rajendra prasad 28 Mar '12

28 Mar '12

Hi, I am trying to load the DLL(Wrapper.dll) in my code(Main.hs). When I am placing the dll in local directory, I am able to load it through following command: ghci Main.hs -L. -lWrapper But, I am not able to load it if I am putting it in some other directory(../../bin). I used the following command: ghci Main.hs -L../../bin/ -lWrapper I doubt I am not using the correct way to specify the path of dll in the command. Please correct me if I am wrong. Thanks in advance. Regards, Rajendra

2 4

Happstack routing + boomerang + non-ascii urls
by Semen Trygubenko 28 Mar '12

28 Mar '12

Dear Haskell-Cafe, Last weekend I was test driving Web.Routes.Boomerang. A great package … Is there any way I could make it work with urls containing non-ASCII characters? Happstack.Server routing using "path" handles non-ASCII, as in, for instance, dir "work" $ path $ workHandler , where workHandler gets a correctly decoded path segment passed in as a String. The following, however, sitemap :: Router Sitemap sitemap = ( rWork . anyString ) passes to Work constructor an incorrectly decoded String. All the plumbing re embedding boomerang route into a normal Happstack one, etc. is done as per example from crash course here: http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang Many thanks, Sem -- Семен Тригубенко

2 3

Arguments against an hypothetical Data.ByteString.Generic?
by Yves Parès 27 Mar '12

27 Mar '12

Hello, As vector provides a class generalizing all flavours (Data.Vector.Generic.Vector), it occurs to me that the same could be done for ByteString. Then, packages based on it would have the choice between hardcoded and generic, they wouldn't have to duplicate a module to handle both strict and lazy versions, as (with the exception of functions for communication with C code) they already provide the same API. I would be willing to make it, it's a concern I've had in mind for a long time, but as I'm pretty sure the idea isn't new, I would very much like to know if and what arguments (related to performance maybe ? I don't know...) were raised against that.

2 4

ANNOUNCE: haskell-src-exts-1.12.0
by Niklas Broberg 27 Mar '12

27 Mar '12

Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.12.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts It's been a long while since the last update before this, but it is my definite hope that I will once again be able to update regularly. This major release primarily enables the (relatively) new quasi-quoter syntax. The "major" version bump is questionable, but better safe than sorry. The only backwards incompatible change is that pretty- and exact-printing now use the new quasi-quoter syntax, which makes the round-tripping 'exactPrint . parse' cycle fail for code using the old syntax. There are more changes in the pipeline, some larger and some smaller. Stay tuned! Changelog: 1.11.1 --> 1.12.0 =============== * Move from old [$...| quasi-quote syntax to the new [...| one. The old syntax is still recognized while parsing. * Allow symbols as variables when TypeOperators is enabled. * Rename ExplicitForall in ExplicitForAll, to be consistent with GHC and the Haskell' process. Cheers, /Niklas

2 1

Reminder Munich Haskell Meeting
by Heinrich Hördegen 27 Mar '12

27 Mar '12

Dear all, just to remind you: Tomorrow, 28th of March, our Haskell get-together will take place in Munich. If you plan to join, go to http://www.haskell-munich.de/dates and click the button. Have a nice day, Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

1 0

Regarding Haskell FFI for C/C++ (Passing of String)
by rajendra prasad 27 Mar '12

27 Mar '12

Hi, I have just started learning Haskell FFI. I am trying to send a string from hastell to a C function. For this, I am required to convert the haskell string to byte string. I have two methods to achieve this task. Both are listed below: 1) import Foreign.C.String let arg1 = map castCharToCChar "Hello" :: [CChar] 2) import qualified Data.ByteString.Char8 as B f = B.pack "Hello" I just wanted to know the optimal way to achieve this task. Please suggest the optimal way of doing this. If there is any other way, please share it. Also, please suggest me any good tutorial to start with Haskell FFI for C/C++. Thank you very much. Regards, Rajendra

2 3

good lightweight web-framework like sinatra?
by serialhex 27 Mar '12

27 Mar '12

i'm looking for something lightweight, that dosnt need it's own server, can easily run on cgi on an apache with minimal work, and dosn't have many dependancies. i was looking at yesod, but it is bigger than i need for my site (at this point) and would take too much work to get running on my webhost. though i am looking forward to learning it and using it in the future, i just need something that will play nicely with apache & cgi... justin p.s. if anyone is interested to know i'm using nearlyfreespeach.net as my host... haskell is one of the many languages they support via cgi, but, at the moment, it is kind of difficult to get yesod or rails or the like to work on it... :-/ -- * The wise man said: "Never argue with an idiot. They bring you down to their level and beat you with experience." * As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. ~Doug McIlroy No snowflake in an avalanche ever feels responsible. --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?”

6 6

Is there a generic way to detect "mzero"?
by Ting Lei 27 Mar '12

27 Mar '12

Hi, I was writing a code trying to use MonadPlus to detect some error cases (representing missing values etc. in pure code). With the Maybe monad, I can do this: can0 :: (a -> Maybe b) -> a -> Bool can0 f x = case f x of Nothing -> False Just x -> True And I got the expected result: *Main> can0 (\x -> Just x) 1 True But, when I try to generalize this using MonadPlus, as follows: can :: (MonadPlus m) => (a -> m b) -> a -> Bool can f x = case f x of mzero -> False _ -> True I got a warning: __testError.hs:31:11: Warning: Pattern match(es) are overlapped In a case alternative: _ -> ... Ok, modules loaded: Main. And the result is also not as intended (see also can0): *Main> can (\x -> Just x) 1 False Can anyone help to explain why this wouldn't work or if there is a workaround to use Monadplus and mzero (or Monad and fail) to achieve this? Thanks in advance for your help Ting

9 10