March 2012 - Haskell-Cafe

haskell platform - mac lion - installation error
by Peter 11 Mar '12

11 Mar '12

Hello - I'm a new user, having some trouble installing the Haskell Platform (2011.4.0.0 64bit.pkg) on a Macbook Pro (10.7.3). I installed Xcode 4.3.1 (4E1019), then the Haskell Platform. When I double-click on the Platform package icon, I get an installation dialogue with an error message reading "Developer Tools Missing - Please install Xcode developer tools first." Are Xcode developer tools something distinct from Xcode itself? I'm mystified by this error message. Any assistance would be greatly appreciated - thank you.

6 5

Haskell Java interoperability
by bartosz＠fpcomplete.com 10 Mar '12

10 Mar '12

I looked on haskell.org for solutions to Haskell/Java interop, but there doesn't seem to be any current project. What is the status of Lambada or its progeny (I asked Erik Meijer, but he lost track of it). Which project is closest to maturity? --Bartosz

2 1

ANNOUNCE: diagrams 0.5
by Brent Yorgey 09 Mar '12

09 Mar '12

I am pleased to announce the release of version 0.5 of diagrams [1], a full-featured framework and embedded domain-specific language for declarative drawing. Check out the gallery [2] for examples of what it can do! [1] http://projects.haskell.org/diagrams [2] http://projects.haskell.org/diagrams/gallery.html Highlights of this release include: - A new diagrams-contrib [3] package of user-contributed modules, which so far contains code for tree drawing, Apollonian gaskets, planar tilings, "wrapped" layout, and turtle graphics. - Experimental support for animation, built on top of the new active [4] library. - Numerous small additions and improvements, including more general rounded rectangle shapes and better text support. - Much better performance in some common situations, such as laying out a very long list of diagrams using 'cat' and related combinators. - Added support for GHC 7.4. See the release notes [5] for complete details, and the diagrams wiki [6] for help migrating code from 0.4 to 0.5 (changes should be minimal). [3] http://hackage.haskell.org/package/diagrams%2Dcontrib [4] http://hackage.haskell.org/package/active [5] http://projects.haskell.org/diagrams/releases.html [6] http://www.haskell.org/haskellwiki/Diagrams/Migrate0.5 Try it out ---------- For the truly impatient: cabal install gtk2hs-buildtools cabal install diagrams Diagrams is supported under GHC 6.12, 7.0, 7.2, and 7.4. However, getting cairo to build can be tricky on some platforms; see the diagrams wiki [8] for more information and workarounds regarding specific platforms. (A new native SVG backend is in the works, targeted for the 0.6 release.) To get started with diagrams, read the quick tutorial [9], which will introduce you to the fundamentals of the framework. For those who are even less impatient but want to really dig in and use the power features, read the user manual [10]. [7] http://projects.haskell.org/gtk2hs/development/#development [8] http://www.haskell.org/haskellwiki/Diagrams [9] http://projects.haskell.org/diagrams/tutorial/DiagramsTutorial.html [10] http://projects.haskell.org/diagrams/manual/diagrams-manual.html Get involved ------------ Subscribe to the project mailing list [11], and/or come hang out in the #diagrams IRC channel on freenode.org for help and discussion. Make some diagrams. Fix some bugs [12]. Submit your cool examples for inclusion in the gallery or your cool code for inclusion in the diagrams-contrib package! [11] http://groups.google.com/group/diagrams-discuss [12] http://code.google.com/p/diagrams/issues/list Happy diagramming! Brought to you by the diagrams team: - Peter Hall - Ian Ross - Michael Sloan - Ryan Yates - Brent Yorgey with contributions from: - Sam Griffin - Claude Heiland-Allen - John Lato - Vilhelm Sjoberg - Luite Stegeman - Kanchalai Suveepattananont - Scott Walck

1 0

ANNOUNCE: string-conversions-0.1
by Sönke Hahn 09 Mar '12

09 Mar '12

Hi all! string-conversions is a very simple package to facilitate dealing with different string types. It provides a simple type class that allows you to convert between values of different string types. It also provides type synonyms for these string types. Supported types are: - String - Strict ByteString - Lazy ByteString - Strict Text - Lazy Text http://hackage.haskell.org/package/string-conversions Any comments welcome. Cheers, Sönke

3 8

If you'd design a Haskell-like language, what would you do different?
by Robert Clausecker 09 Mar '12

09 Mar '12

Image you would create your own language with a paradigm similar to Haskell or have to chance to change Haskell without the need to keep any compatibility. What stuff would you add to your language, what stuff would you remove and what problems would you solve completely different? Thanks in advance for all answers, yours Robert Clausecker

39 91

The (!) operation
by Christopher Done 08 Mar '12

08 Mar '12

‘Ello. Is there a generalization of this operator? It's all over the place, it's basically (!) :: (Monad m, Indexed collection index value) => index -> container -> m value We have `(!!)` on lists, `(!)` on maps, vectors, json objects, … (doesn't seem there's one for bytestring) (Though I seem to recall the monadic return value being frowned upon but I don't recall why.) Thoughts? Ciao!

4 9

GHCi fails to load C++ object files (missing symbol)
by Yves Parès 08 Mar '12

08 Mar '12

Hi, I'm trying to have GHCi load a haskell file that depends on a C++ object file, which causes GHCi to fail because of an unknown symbol (*and I did link with **libstdc++*), whereas the link into an executable with ghc works and runs perfectly. I've reduced my code to the smallest one that produces the problem: The C++ part defines a mere class and C externals that enable communication with Haskell: // Header Stuff.hpp class Base { public: Base(); ~Base(); } extern "C" { Base* mkthing(); void delthing(Base*); } ----------- // Source Stuff.cpp #include <iostream> #include "Stuff.hpp" using namespace std; Base::Base() { cout << "Base created" << endl; } Base::~Base() { cout << "Base deleted" << endl; } extern "C" { Base* mkthing() { return new Base(); } void delthing(Base* b) { delete b; } } Haskell code (just for reference, but I'm not sure it's relevant), Main.hs: {-# LANGUAGE ForeignFunctionInterface #-} import Foreign import Foreign.C foreign import ccall unsafe "mkthing" mkthing :: IO (Ptr ()) foreign import ccall unsafe "delthing" delthing :: Ptr () -> IO () main = do p <- mkthing delthing p I then compile it with: g++ -c Stuff.cpp ghci Main.hs Stuff.o -lstdc++ And then the error is: Loading object (static) Stuff.o ... done Loading object (dynamic) /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/libstdc++.so ... done final link ... ghc: Stuff.o: unknown symbol `__dso_handle' linking extra libraries/objects failed Whereas 'ghc Main.hs Stuff.o -lstdc++' works just fine. Does GHCi lacks a link directive that regular GHC has?

3 5

Type classes for converting to Text and String
by Simon Hengel 08 Mar '12

08 Mar '12

Hi! When writing library code that should work with both String and Text I find my self repeatedly introducing classes like: class ToString a where toString :: a -> String class ToText a where toText :: a -> Text (I use this with newtype wrapped value types backed by Text or ByteString.) So I wonder whether it would be a good idea to have a package that provides those classes. Or maybe just ToText, and provide default implementations of toString and toText, like: class ToText a where toText :: a -> Text toText = Text.pack . toString toString :: a -> String toString = Text.unpack . toText How do you guys deal with that? Any thoughts? Cheers, Simon

4 9

Monad.Reader #20 call for copy
by Edward Z. Yang 07 Mar '12

07 Mar '12

I'm pleased to announce that I, Edward Z. Yang, will be taking over Brent Yorgey's role as lead editor of the Monad Reader! Call for Copy: The Monad.Reader - Issue 20 -------------------------------------------- Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The submission deadline for Issue 20 will be: **Monday, March 5** The Monad.Reader ~~~~~~~~~~~~~~~~ The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki- page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~~~~~~~~~~~~~~~~~ Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (ezyang(a)mit.edu) Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll work something out.

1 1

Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
by Greg Weber 07 Mar '12

07 Mar '12

This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607

2 2