Fwd: [Haskell-cafe] What's the deal with Clean?
I had to implement a ring buffer, and I wanted the code using it to be written in Haskell. I ended up implementing the buffer in C, and wrapping it in FFI from Haskell because implementing a destructive array in Haskell is kind of unwieldy to someone of my experience level. In Clean, it looks like the uniqueness typing allows for destructive updates in a very controlled manner. The ST monad provides this functionality. The never-instantiated-in-a-visible-way state parameter of the ST monad provides the uniqueness required for doing destructive updates in a pure way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANNOUNCE: mathlink-2.0.0.3
All: mathlink is a library for writing Mathematica packages in Haskell. One simply writes some functions of type: (MLGet a, MLPut b) = a - IO b and provides a package specification in a simple DSL that mimics that of Mathematica's mprep utility. The result is a program that exposes functions that can be called from Mathematica. This is a complete rewrite of my original implementation and more closely captures the functionality I originally intended. I've only tested it on my own platform (64-bit Linux), but I've taken pains to make sure the code should run on any platform. (The only real issue in the code is picking the right functions to call when marshaling Ints.) Please report any tweaks required to get it to work on your platform. (That is, of course, only if, in fact, there are any other users out there. Right now, as far as I know, I'm it.) I'd also just like to hear from any Haskellers out there that also use Mathematica on a regular basis. Ping me if you're one. --Tracy ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANNOUNCE: mathlink-2.0.0.3
Already posted to the Haskell list but dons suggested I post to the cafe, as well... All: mathlink is a library for writing Mathematica packages in Haskell. One simply writes some functions of type: (MLGet a, MLPut b) = a - IO b and provides a package specification in a simple DSL that mimics that of Mathematica's mprep utility. The result is a program that exposes functions that can be called from Mathematica. This is a complete rewrite of my original implementation and more closely captures the functionality I originally intended. I've only tested it on my own platform (64-bit Linux), but I've taken pains to make sure the code should run on any platform. (The only real issue in the code is picking the right functions to call when marshaling Ints.) Please report any tweaks required to get it to work on your platform. (That is, of course, only if, in fact, there are any other users out there. Right now, as far as I know, I'm it.) I'd also just like to hear from any Haskellers out there that also use Mathematica on a regular basis. Ping me if you're one. --Tracy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphs and graph algorithms?
We don't seem to have a binding to any of the foreign language libs for very large graphs. Do you know of any stand-out libraries in this regard worth binding? When I looked in to this last year, the best I could find was the boost library. It depends very heavily on template meta-programming, though, so it wouldn't really be bindable with any of the generality that it has in its native C++. I ask because I'm doing a lot of graph stuff in Haskell right now, and I might be willing to put in the effort to do the binding--especially while I still have c2hs syntax fresh in the brain: I just finished a complete re-write of the mathlink library (brings Haskell to Mathematica -- announcement to follow shortly). --Tracy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance question
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson lenn...@augustsson.netwrote: You can implement a reasonable split if you can fast-forward the generator. There's no known method to fast-forward the MT, but other generators like MRG32k3a can handle it. Are you aware of any existing (C/C++/Haskell) library implementing this algorithm? A cursory google search didn't turn anything up for me, aside from something implemented in Java, and another in Lisp. --Tracy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance question
Awesome, Felipe. Thanks. --Tracy On Thu, Feb 26, 2009 at 11:07 AM, Felipe Lessa felipe.le...@gmail.comwrote: 2009/2/26 Tracy Wadleigh tracy.wadle...@gmail.com: On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson lenn...@augustsson.net wrote: You can implement a reasonable split if you can fast-forward the generator. There's no known method to fast-forward the MT, but other generators like MRG32k3a can handle it. Are you aware of any existing (C/C++/Haskell) library implementing this algorithm? A cursory google search didn't turn anything up for me, aside from something implemented in Java, and another in Lisp. Maybe http://www.iro.umontreal.ca/~lecuyer/myftp/streams00/http://www.iro.umontreal.ca/%7Elecuyer/myftp/streams00/? -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC
Benedikt writes: I think a good general purpose graph library is tricky though: - There are lot of variants of graphs (trees, bipartite, acyclic, undirected, simple, edge labeled etc.), hard to find adequate and easy to use abstraction. - There is no single 'best' implementation (mutable vs. unmutable etc.). - Its hard to find good traversal and zipper abstractions, though fgl has some nice ones. - The complexity of algorithms varies greatly depending on the particular kind of graph. Anyway, that's why it is challenging and interesting. Hear, hear! From what I can tell, fgl is the closest thing I've seen to a usable remotely-general-purpose graph library in any language. With all apologies to Siek, et al., the boost graph library is exceedingly complex, to the point of being unusable (one man's opinion) to all but the most ardent lovers of C++ template metaprogramming. That's no knock on its designers, it's just that the graph problem provides an exceptionally challenging tension between managing complexity and providing acceptable performance--on top of trying to achieve respectable generality. It seems to me that anyone who aspires to author a Haskell graph library that can be regarded as canonical really ought to first know fgl inside and out, and probably ought to consider extending that library, vs. starting from scratch. In fact, it was my current work with non-trivial graph problems that ultimately led me to justify switching to using Haskell for my day job a couple of months ago (after having investigated and abandoned other possible solutions in other languages that would have been a much easier sell to my higher-ups). So I have a pressing professional interest on hearing others weigh in on this topic, and particularly on the benefits/shortcomings of fgl. I'd especially like to hear from Martin Erwig on this topic. Martin? You listening? --Tracy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
