- Haskell-Cafe - Haskell.org

2008-10-12 Hackage status with GHC 6.10 release candidate
by Don Stewart 17 Oct '08

17 Oct '08

Hey all. The GHC 6.10 RCs are out, and we're preparing the release. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate. For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 73 DependencyFailed 132 BuildFailed 456 InstallOk Note that these builds are with "soft deps", provided on hackage, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 which train cabal-install to build a larger set of packages. The important result: *46 packages produce different results to ghc 6.8.2* These packages and their logs are listed below. If you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy. The most common issues for these differences are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-12/ The following packages are producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 PArrows-0.1 TypeCompose-0.5 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 hasim-0.1 hask-home-2007.12.6 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 streamproc-1.1 stringtable-atom-0.0.4 typalyze-0.1.1 xmonad-utils-0.1 yhccore-0.9 If you'd like to try your own build of all of hackage, grab a package list (such as this one), http://www.galois.com/~dons/tmp/pkgs-6.10 Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage), and cabal-install 0.6 (on hackage), and then simply, cabal install -v -O0 $(cat pkgs-6.10) --build-reports This will construct a clever plan to install all the packages in the right order, and write logs to ~/.cabal/logs and a full structured build report into ~/.cabal/packages/hackage.*/build-report.log -- Don

6 10

Re: [Haskell-cafe] Very silly
by Andrew Coppin 17 Oct '08

17 Oct '08

Juan Carlos Arevalo Baeza wrote: > Andrew Coppin wrote: >> Some guy told me that templates are "the best feature in the >> language", and proceeded to show me a huge chunk of highly >> complex-looking code which is approximately equivilent to >> >> join :: Array x -> Array x -> Array x >> >> I was unimpressed. > > Now I'm curious to know what chunk of code he showed you. FWIW, that > declaration you put there is done in C++ like so: > > template < typename X > > Array<X> join(Array<X> const&, Array<X> const&); > > Nothing more. I like both languages for very different reasons. C++ > for its insane amount of flexibility, and Haskell for its > expressiveness. And I've encountered equally harsh roadblocks in both > whenever I try to get "too crazy" while using them. Well no, he included the implementation as well as just the signature. >> Actually, that's a lie. I was impressed that such a low-level >> language could manage even that much abstraction. But I still prefer >> the Haskell way... > > The dynamic range of the C++ language is probably unparalleled. In > particular, templates enable implementing high level abstractions in a > way such that we're still discovering how far it can go. But of > course, it's not just templates: it's templates when united to all > other language features like overloading. C++ has some interesting ideas. I haven't learned how to use templates yet, but what I do find interesting is that there is no automatic memory management, and yet you can still do fairly dynamic programming. I've never seen any other language that allows this. (I had assumed it's impossible...) This makes me wonder just now necessary GC really is, and whether there is some way to avoid it...

4 3

Haskell in Artificial Intelligence
by Christos Chryssochoidis 17 Oct '08

17 Oct '08

Greetings, I'm interested in doing a survey about the use of Haskell in the field of Artificial Intelligence. I searched in Google, and found in the HaskellWiki, at www.haskell.org/haskellwiki/Haskell_in_industry, two organizations that use Haskell and do work related to AI. Besides that, I haven't found much else. Could somebody from the Haskell community give me some pointer to a project or system related to AI that uses Haskell? Thank you very much in advance. - CC

4 4

ledger manual available
by Simon Michael 17 Oct '08

17 Oct '08

> From: Simon Michael <simon(a)joyful.com> > Date: October 16, 2008 11:36:15 AM PDT > To: haskell-cafe(a)haskell.org, ledger-cli(a)googlegroups.com > Subject: ledger manual available > > This seems to have fallen off the ledger site: the latest ledger > manual in easily-browsable form. To be clear, this documents the > mature ledger, not the young hledger released yesterday. But it's a > good read, gives the big picture and some of it is directly > applicable to hledger. > > one big page: http://joyful.com/repos/ledger/doc/ledger.html > many pages: http://joyful.com/repos/ledger/doc/ledger/ > pdf: http://joyful.com/repos/ledger/doc/ledger.pdf > >

1 0

Cabal package with library and tests
by Mauricio 17 Oct '08

17 Oct '08

Hi, I'm writing a Cabal package, using main=defaultMain in Setup.hs. It has a library, and I want to also build a few executables so I can test the library. How am I supposed to do that? My attempt was to create 'executable' sections for those tests. However, I don't know how to include the main library in the modules used by those tests. I tried to insert my own package in a 'build-depends' line, but that didn't work. Thanks for your tips, Maurício

2 4

Where did House/hOp go?
by Svein Ove Aas 17 Oct '08

17 Oct '08

I'd finally gotten to the point in learning haskell at which they might be interesting to look at, and then.. they were gone. Does anyone know what happened to these projects? They used to be open-source, so the code should still be around somewhere, right?

3 2

Re: [Haskell-cafe] Very silly
by Juan Carlos Arevalo Baeza 17 Oct '08

17 Oct '08

Andrew Coppin wrote: > Some guy told me that templates are "the best feature in the > language", and proceeded to show me a huge chunk of highly > complex-looking code which is approximately equivilent to > > join :: Array x -> Array x -> Array x > > I was unimpressed. Now I'm curious to know what chunk of code he showed you. FWIW, that declaration you put there is done in C++ like so: template < typename X > Array<X> join(Array<X> const&, Array<X> const&); Nothing more. I like both languages for very different reasons. C++ for its insane amount of flexibility, and Haskell for its expressiveness. And I've encountered equally harsh roadblocks in both whenever I try to get "too crazy" while using them. > Actually, that's a lie. I was impressed that such a low-level language > could manage even that much abstraction. But I still prefer the > Haskell way... The dynamic range of the C++ language is probably unparalleled. In particular, templates enable implementing high level abstractions in a way such that we're still discovering how far it can go. But of course, it's not just templates: it's templates when united to all other language features like overloading. Maybe I can take a crack at my own comparison of simple polymorphism between C++ and Haskell. C++: template < typename A > struct B { A m; }; // Polymorphic type definition template <> struct B<bool> { int m; }; // Polymorphic type specialization template < typename A > struct B<B<A> > { A m; }; // Polymorphic type partial specialization template < int N > struct B<int[N]> { int m[N]; }; // Non-type polymorphic parameters template < typename A > struct C { typedef B<B<A> > type; }; // Polymorphic type aliases (type functions) must use trickery and bad syntax B<int> const b = { 8 }; // Declare object of polymorphic type template < typename A > A get(B<A> const& b) { return b.m; } // Polymorphic function using polymorphic type int get(B<int> const& b) { return b.m + 1; } // Specialization of polymorphic function (actually, it is an overload - functions can't be specialized, but this is nearly equivalent) Haskell: data B a = B { m :: a } -- Polymorphic type definition // Polymorphic type specializations not available // Non-type polymorphic parameters not available (must emulate using Peano and such) type C a = B (B a) -- Polymorphic type aliases (type functions) let b = B 8 :: B Int in -- Declare object of polymorphic type get :: B a -> a; get b = m b -- Polymorphic function using polymorphic type (declaration and definition separate) // Specialization of polymorphic function not available without putting the function in a type class C++ templates are clearly more flexible, but they are also a lot clunkier to use (and both things are very much related). If you look at the specializations, and understand them, you'll see that it's easy to make a specialization that is incompatible with the main parametric (template) type definition. Sometimes, that's a good thing. I've created main templates that purposefully fail to compile when used, as a means to detect types that need their own particular specialization. But it's easy to see how they can have... unexpected consequences. For instance: B<B<int> > const bint = { 7 }; B<int> const bintresult = get(bint); // Compiler error! Can you see why? A specialization is to blame. But the main hurdle is that a template's definition is partially untyped. Type-checking of the innards of a template is finalized at the time the template is invoked, at which point it is too late for the compiler to root-cause any failures it encounters. Thus, using complex template-based libraries can be quite inconvenient if you don't get things right on your first try. For instance: C++: template < typename A > bool compare(B<A> const& b1, B<A> const& b2) { return b1.m == b2.m; }; // Another polymorphic function B<SomeType> val; compare(val, val); // This gives out horrible errors if SomeType doesn't have the equality operator defined Haskell: compare :: Eq a => B a -> B a -> Bool; compare b1 b2 = m b1 == m b2 -- Another polymorphic function let val = ... :: B SomeType in compare val val // This Complains if SomeType is not an instance of Eq This is a silly example, and the C++ errors you get are not quite so bad. But they can get really, really bad. The new C++ standard they are finalizing will "fix" this by adding concepts (akin to type classes) and concept_maps (akin to instances). It is interesting to realize, though, that in C++, templates must all be resolved at compile time, whether they use concepts or not. There's never any dictionary-passing happening anywhere, and all polymorphic functions must be specialized for all the different types that are used with them. For runtime polymorphism, C++ uses OO classes which are completely separate. OO classes are in some way like Haskell classes, but the dictionaries must be embedded in the objects themselves, whereas Haskell classes pass the dirctionaries into polymorphic functions separately. If a class is a salad, and the dictionary is the dressing, then C++ serves the dressing in the salad, and Haskell serves it on the side. The main consequence for this is that, in C++, class instances must be attached at the point of declaring the type, whereas in Haskell, you can do it after the fact. Maybe this is not quite so clear or useful after all. One-liners can be quite obtuse. And the craziness with templates shines when you combine them with various other features of the language. You can even make things like Boost.Proto (http://boost-sandbox.sourceforge.net/libs/proto/doc/html/index.html) which is a library for creating arbitrary DSLs in C++. JCAB

1 0

Re: Repair to floating point enumerations?
by Henning Thielemann 17 Oct '08

17 Oct '08

David Roundy schrieb: > Why not look for a heuristic that gets the common cases right, rather > than going with an elegant wrong solution? After all, these > enumerations are most often used by people who neither care nor know > how they're implemented, but who most likely would prefer if haskell > worked as well as matlab, python, etc. Although MatLab has a lot of bad heuristics, they fortunately didn't try to be too clever with respect to rounding errors. Floating point enumerations have the same problems in MatLab as in all other languages.

3 3

Rewrite rules
by George Pollard 16 Oct '08

16 Oct '08

Section 8.13.2 of the GHC manual[1] states: > GHC keeps trying to apply the rules as it optimises the program. For > example, consider: > > let s = map f > t = map g > in > s (t xs) > > The expression s (t xs) does not match the rule "map/map", but GHC > will substitute for s and t, giving an expression which does match. If > s or t was (a) used more than once, and (b) large or a redex, then it > would not be substituted, and the rule would not fire. > The part I'm interested in here is (a); if an expression is used more than one then it cannot be substituted for. Is there any way to work around this or force it? The reason I ask is that as a bit of fun (and inspired by Joachim Breitner's blog post [2]) I was going to try writing a rewrite rule for the first time. What I had in mind was this: {-# RULES "index cycled list" forall list n. cycle list !! n = list !! (n `mod` length list) #-} However, in the case he has written about this won't fire, since the LHS cannot be substituted as `cycle list` is used more than once: > let rlist = cycle list > print ( rlist !! (10^9), rlist !! 0 ) I can get it to fire again if I write it like this: > {-# RULES > "!!/cycle" forall list. (!!) (cycle list) = (\n -> list !! (n `mod` length list)) > #-} > > ... > > let rlist = (!!) (cycle list) > print (rlist (10^9), rlist 0) But this is non-obvious and I'd rather have it fire in the first case (i.e. when used naïvely). So, back to my question; is there a workaround or force for this... or does it break too many things if done? [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html#… [2] http://www.joachim-breitner.de/blog/archives/308-guid.html

3 3

(OT) Humorous definition for fixed points?
by Corey O'Connor 16 Oct '08

16 Oct '08

I was just reminded of one of the joke definitions of recursion: "recursion: see recursion". Perhaps there is a similar one for fixed points? "To learn about fixed points find the fixed point of the process: Given somebody learn about fixed points from them." Course, my understanding of fixed points is poor and my jokes always have poor delivery. So I'm sure somebody else can do better. -Corey O'Connor

2 1

FFI Newbie: c functions that want pointers to objects
by Mauricio 16 Oct '08

16 Oct '08

Hi, Some functions in C changes data using pointers, like this example: void change_int (int *n) { *n ++; } What is the proper way to handle that? I guess I should wrap it like this: foreign ccall "change_int" change_int :: Ptr CInt -> IO () Can I use that on a CInt in Haskell code? Like this obviously wrong code, but that probably shows what I want: do let myN = 5 change_int myN Thanks, Maurício

2 1

What is this function?
by John Ky 16 Oct '08

16 Oct '08

Hi, I've written this function here: scramble [] = [] scramble [x] = [[z] | z <- scramble x] scramble (x:xs) = [(y:z)|y <- scramble x, z <- scramble xs] and (I think) it roughly does what I want it to: *Main> scramble ([]::[Int]) [] *Main> scramble ([1]::[Int]) [[1],[2]] *Main> scramble ([1,2]::[Int]) [[1,1],[1,2],[2,1],[2,2]] *Main> scramble ([1,2,3]::[Int]) [[1,1,1],[1,1,2],[1,2,1],[1,2,2],[2,1,1],[2,1,2],[2,2,1],[2,2,2]] Three questions: 1. What should I call this function? 2. Is there already one in the standard library that does the same thing? 3. Is it possible to rewrite it with only "scramble []" and "scramble (x:xs)" and not the "scramble[x]"? Thanks -John

3 2

What does laziness buy you?
by Ryan Ingram 16 Oct '08

16 Oct '08

One thing that is hard to communicate to people in industry is what value laziness has. You can point people at the WhyFP paper, and talk about infinite data structures and decoupling generation from search until you're blue in the face, but it's so far beyond the day-to-day work of regular programmers that they don't really comprehend. But I was talking to Simon Marlow yesterday and he pointed out something that strikes me as a great example to give of "what laziness buys you". Lets talk about atomic changes. In particular, I want to examine the function atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b This takes an IORef, reads the value out of it, calls some code that gets a new value and may return some derived data, writes the new value into the IORef, and returns the derived data. It has the invariant that no other change to that IORef can happen in between. Now, there are all sorts of issues like "what if 'f' has a side effect" that get sidestepped entirely by purity, but I don't want to talk about those; I think the benefits of purity are easier to argue in many contexts. Lets just look at a simple Haskell implementation: > atomicModifyIORef p f = do > a <- readIORef p > let r = f a > writeIORef p (fst r) > return (snd r) This is a non-atomic implementation, but we can fix it assuming we have "compare-and-swap" available; any language with boxed types can do this: > -- low-level primitive that uses pointer equality behind the scenes > compareAndSwap# :: IORef a -> a -> a -> IO Bool > atomicModifyIORef p f = do > a <- readIORef p > let r = f a > let aNew = fst r > ok <- compareAndSwap# p a aNew > if ok > then return (snd r) > else atomicModifyIORef p f This loops until compareAndSwap# succeeds and is a simple lock-free implementation. But what if f takes a long time to run? In a strict language, if there was contention on p, it's likely that atomicModifyIORef never finishes executing due to starvation! But since Haskell is lazy, each attempt to modify p is a constant-time operation! We just allocate thunks for "r" and "aNew" and do the compare-and-swap. Now, the responsibility for executing f is shifted to anyone who reads from the IORef; they get a thunk. It's likely that this thread will do so, as the value returned by atomicModifyIORef depends on f executing, but if this thread gets suspended or there is contention, the next reader can pick up the slack! In fact, at the low level we can improve this further; we can build the thunks for "r" and "aNew" with a hole to put the value we read out of the IORef; the inner loop then looks like this: > a <- readIORef p > update thunk hole in "r" with "a" > ok <- compareAndSwap# p a aNew which compiles down to just a pointer read, assignment, and CAS instruction. This blew my mind; from the "imperative, strict" point of view, this sort of operation is impossible to do reasonably, and here in Haskell we can get a great "probability of success"; the "critical section" where we have to loop if someone else modified the value behind our back is just a few instructions long! -- ryan

1 0

[Haskell-cafe] Object-oriented programming, Haskell and existentials
by oleg＠okmij.org 16 Oct '08

16 Oct '08

Lennart Augustsson wrote: > I was just pointing out that the mechanism for doing the OO thing > exists in Haskell too, albeit looking a little different. Indeed there is a mechanism for doing OO in Haskell -- several of them. Most of them have nothing to do with Existentials. In the OHaskell paper, http://homepages.cwi.nl/~ralf/OOHaskell/ Ralf Laemmel has collected all known to us methods of doing OO in Haskell. Incidentally, three years ago Lennart Augustsson described a simple, Haskell98 method of emulating OO, without existentials. We give him credit in footnote 4. The OOHaskell paper then goes to demonstrate how to do *all* of the known OO in Haskell, with all its inherent complexity: depth and width subtyping, upcasting and safe downcasting, nominal and structural subtyping, and the whole issue about covariant methods. Derek Elkins wrote: > In general, to encode OO you need quite a bit more than existentials. > As you are probably aware, there was a cottage industry in the mid to > late '90s working on encodings of OO languages into System F + foo > calculi. They just about gave up on a complete encoding until someone > figured one out. 'turns out all you needed was recursive bounded > existential quantification. Not necessarily. Again, please see the OOHaskell paper. The full story is that there are several encodings of objects -- using closures and using existentials. The former are *far* simpler. ML-ART (which later evolved in the 'O' of OCaml) chose the more complex encoding -- and hence had to add equi-recursive types, existentials and universals to Caml -- only because of a potential safety issue with closures. A constructor of an object may invoke methods that may access fields that are not initialized yet. This problem is present in all OO languages, and the common `solution' is an admonition ``not to do that''. Clearly Didier Remy has higher standards, and he went into considerable pain to solve the problem. Incidentally, Haskell can solve this problem in a simpler way. We critically rely on the fact that all effects must be done in a monad. Therefore, in OOHaskell we can safely use the simpler encoding for objects. Regarding existentials, the web page http://okmij.org/ftp/Computation/Existentials.html demonstrates how to systematically eliminate existentials. In fact, the object encoding via existentials can be easily transformed into the encoding that uses only simple, first-order types. The web page begs a question if there is ever any real need for existentials.

5 6

Re: What I wish someone had told me...
by John Lato 16 Oct '08

16 Oct '08

I'd like to thank everyone who replied to my OP, and also perhaps clarify one point. I wasn't trying to be argumentative or negative about any work people have done to make Haskell approachable for OO programmers (or any other programmers, for that matter). I simply wanted to know what others thought about one item that was misleading to me in particular, and to see if others either agreed with me or had similar experiences. That being said, I know that it's a great deal of work to put together a useful tutorial, and I appreciate every one I read. Especially the monad tutorials, of which it took a half dozen before I got it. Best, John

7 6

Writing a function isPrime using recursion.
by Kalashnikov 16 Oct '08

16 Oct '08

I'm supposed to write a function isPrime that checks whether or not a given integer is a prime number or not. The function has to use recursion. The only advice I was given, was to use a helper function. I still have no clue how to do it :confused: I'm new to Haskell by the way..please help.. -- View this message in context: http://www.nabble.com/Writing-a-function-isPrime-using-recursion.-tp2000330… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 2

ANN: hledger 0.1, command-line accounting tool
by Simon Michael 16 Oct '08

16 Oct '08

I'm pleased to announce the first release of hledger, a command-line accounting tool similar to John Wiegley's c++ ledger. hledger generates simple ledger-compatible transaction & account balance reports from a plain text ledger file. It's simple to use, at least for techies. This has been my "learning Haskell" project, but I think it's also useful. It is much less featureful than ledger, and not quite as fast, but it has the virtue of being fun for haskellers to hack on. I am documenting the code, the app is simple, and I'm not too far up the haskell learning curve, so I think other people learning haskell might enjoy a look. It is currently ~1100 lines of haskell excluding tests. home: http://joyful.com/Ledger#hledger hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hledger-0.1 darcsweb: http://joyful.com/darcsweb/darcsweb.cgi?r=hledger darcs 2 repo: http://joyful.com/repos/hledger haddock: http://joyful.com/repos/hledger/api-doc/ ledger home: http://newartisans.com/software/ledger.html ledger manual (recommended): http://github.com/jwiegley/ledger/tree/master/doc/ledger.texi My thanks to John Wiegley for help with compatibility and for his very useful ledger tool. I use it (and now, both of them) daily to track time and money. This is of course a hot topic around our planet. I hope you find it useful or intriguing. Patches and feedback welcome! Best, -Simon

3 3

Improving MTL instances (was: Overlapping/Incoherent instances)
by Ryan Ingram 16 Oct '08

16 Oct '08

On Mon, Oct 13, 2008 at 2:04 AM, J. Garrett Morris <jgmorris(a)cecs.pdx.edu> wrote: > Indeed - MTL seems to have been rewritten at some point in the past to > prefer exhaustive enumeration to overlap. Indeed, and I actually think this is a weakness of the current implementation. Anyone who comes up with a new transformer that provides different functionality than what is there needs to explicitly provide all the relevant instances, instead of letting MonadTrans do its thing. Consider MonadPrompt (shameless plug, it's on hackage!) In order to be fully interoperable with the MTL I'd need to write instances for MonadState, MonadReader, MonadWriter, MonadError, and MonadCont for PromptT. These are unavoidable, although for monads with a "simple enough" interface, such as State, everything can be accomplished with "lift". But I also need to provide the same boilerplate instances for every other monad transformer in the package to give them instances of MonadPrompt. And MonadPrompt *does* have a "simple enough" interface that it could be accomplished trivially with "lift". And this ignores interacting with any other transformer library! Anyone who uses MonadPrompt along with another transformer (like DatabaseT in the PostgreSQL library) needs to write any instances they care about themselves, which adds to the difficulty in using the libraries together. Of course, the point of this message isn't just to complain. The overlap implementation was abhorrent and it *is* better now than it was before. But perhaps there is an abstraction we are missing that would allow for better interoperability. For example, the type-compose library documentation at http://haskell.org/haskellwiki/TypeCompose mentions that (f :. g) is an applicative functor if both f and g are applicative functors, which means there is a generic "transformer" for all applicative functors! The presense of >>=/join for monads make this more difficult, although there is the "product" definition: > newtype Product m n a = Prod { runProd :: m (Either a (Product n m a)) } which handles nesting joins by just nesting the monads recursively. But in this case it is up to the user to figure out how to untangle the spaghetti created, so that's no good. So, does anyone have any good ideas for improving the interoperability of MTL? -- ryan

9 8

Flexible instances
by George Pollard 16 Oct '08

16 Oct '08

I'm a little confused. Why is this allowed: > data Blah = Blah > > instance Eq Blah where > x == y = True But not this: > class Stringable a where > toString :: a -> String > > instance Stringable [Char] where > toString = id (Resulting in:) > Illegal instance declaration for `Stringable [Char]' > (All instance types must be of the form (T a1 ... an) > where a1 ... an are distinct type *variables* > Use -XFlexibleInstances if you want to disable this.) > In the instance declaration for `Stringable [Char]' 'Blah' isn't a type variable, is it? Is my brain just not working right today?

9 9

Very silly
by Andrew Coppin 16 Oct '08

16 Oct '08

{-# LANGUAGE FlexibleInstances #-} module Overload where class Silly s where go :: s instance Silly ([x] -> [x]) where go = reverse instance Silly (Int -> Int) where go = (+1) Don't even ask. Suffice it to say, you *can* make Haskell support arbitrary overloading of function names like C++ has, _if_ you abuse the type system violently enough. Please, won't somebody think of the children?!?

9 13

Cairo and dialog oddities on Windows using glade.
by Jefferson Heard 16 Oct '08

16 Oct '08

Maybe I'm doing something wrong. I've created several dialog boxes in Glade, and I'm calling Gtk.runDialog on them when a user clicks the mouse in my main window. On Linux, they work mostly right, but the insertion point never shows in the Gtk.Entry areas and the dialog itself comes up without any decoration. In Windows, I cannot edit the Entry areas at all. I can click on the action buttons I added with Gtk.Dialog.addButton. Also, I'm getting an (Invalid matrix (matrix not invertible)) error from Cairo in WIndows that I'm not getting in Linux, and all I can think is that occasionally a rectangle width could be negative. Would that cause the error? -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards

1 0

Re: What I wish someone had told me...
by John Lato 16 Oct '08

16 Oct '08

> Albet Lai wrote: > John Lato wrote: >> Are you advocating introducing existential types to beginning >> Haskellers? I think something with the scary name "existential >> quantification" would greatly increase the head'splodin' on the >> learnin' slope. > > OOP(*) advocates introducing existential types to beginning programmers. Yes, because they're required to get almost anything done in OOP languages. In general they are not required in Haskell. I got a bit carried away with rhetorical flourish, but my point wasn't so much that beginners couldn't understand something as that something with such specialized usage isn't necessary for new Haskellers, and is likely to encourage bad habits from OOP-converts. > > The broken analogy between OOP interfaces and Haskell/Isabell type > classes is there because some people insist that all languages should be > like mainstream languages. You have heard it, even from reputable > leaders and pioneers: "if you know one language, picking up others > should be easy, they just differ in syntax". > I have heard it, and I used to believe it. Now I think it's only true provided the one language you know is suitably advanced (and currently non-existent, I think). John

2 1

Network trouble: what to do?
by Creighton Hogg 16 Oct '08

16 Oct '08

So in my quest to create bindings to BlueZ in Haskell, I've hit a bit of a snag: sockets programming. In C, you can use the standard sockets library and just pass around addresses as arrays of 6 bytes instead of arrays of 4 bytes like you normally would. The problem I'm having is that in Network.Socket, there's no such wiggle room and you have to either provide a Word32 or four Word32's to represent the address. Is there a way around this that I just haven't seen, or should I write a patch to Network to add an extra constructor to SockAddr and code to handle it? Cheers, Creighton

2 2

Type safety in foreign pointer
by Mauricio 15 Oct '08

15 Oct '08

Hi, I'm wrapping a library where functions take as parameters pointers to a few standard structs (as, well, all C libraries). I would like to ensure that only pointers of correct structs are passed to those functions. What is the "Haskell way" to do that? My idea is to do something like this: newtype SomeStruct = SomeStruct () and then foreign import ccall "my_function" myfunction :: Ptr SomeStruct -> IO int Is that the proper way to do that? Thanks, Maurício

3 2

ICFP09: Call for Workshop Proposals
by Matthew Fluet (ICFP Publicity Chair) 15 Oct '08

15 Oct '08

CALL FOR WORKSHOP PROPOSALS ICFP 2009 14th ACM SIGPLAN International Conference on Functional Programming 31st August - 2nd September, 2009 Edinburgh, Scotland http://www.icfpconference.org/icfp2009 The 14th ACM SIGPLAN International Conference on Functional Programming will be held in Edinburgh, Scotland from 31st August to 2nd September 2009. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops to be affiliated with ICFP 2009 and sponsored by SIGPLAN. These workshops should be more informal and focused than ICFP itself, include sessions that enable interaction among the workshop attendees, and be fairly low cost. The preference is for one-day workshops, but other schedules can also be considered. The workshops themselves will be held between August 30th and September 5th, as capacity allows. ---------------------------------------------------------------------- Submission details Deadline for submission: 19th November 2008 Notification of acceptance: 17th December 2008 Prospective workshop organisers are invited to submit a completed workshop proposal form in plain text format to the ICFP 2009 workshop co-chairs (Chris Stone and Mike Sperber), via email to icfp09-workshops at cs.hmc.edu by 19th November 2008. Please note that this is a firm deadline. Organisers will be notified if their proposal is accepted by 17th December 2008, and if successful are required to produce a final report after the workshop has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2009/workshops/icfp09-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm ---------------------------------------------------------------------- Selection committee The workshop proposals will be evaluated by a committee comprising the following members of the ICFP 2009 organising committee, together with the members of the SIGPLAN executive committee. Chris Stone Harvey Mudd College Workshops co-chair Mike Sperber DeinProgramm Workshops co-chair Graham Hutton University of Nottingham General Chair Andrew Tolmach Portland State University Program Chair ---------------------------------------------------------------------- Further information Any queries regarding ICFP 2009 workshop proposals should be addressed to the workshops co-chairs (Chris Stone and Mike Sperber), via email to icfp09-workshops at cs.hmc.edu

1 0

I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.
by Magicloud 15 Oct '08

15 Oct '08

1. I cannot install ghc-6.8.3 in my box until I found the old runable binary. 2. After I installed cabal, and upgraded, ghc-6.8.3 cannot rebuild itself. Because its libraries are conflict with the ones upgraded by cabal. 3. Sometimes, ghc just ignore some libs, because it does not meet its dependencies. Well, ghc does not even tell me. It knows what I want? 4. I use cabal, thinking it would make dependencies installation easier for me. Well it does not, once an error happened, nothing would work since. I cannot even remove the broken lib. 5. No more needed. The above ones, which are important enough to drive me crazy.

6 9

Multi-line string literals are both easy /and/ elegant in Haskell
by Matt Morrow 15 Oct '08

15 Oct '08

The new QuasiQuotes extension arriving with ghc 6.10 is very exciting, and handling multi-line string literals is like stealing candy from a baby. ;) ----------------------------------------------------------------------------- -- Here.hs module Here (here) where import Language.Haskell.TH.Quote import Language.Haskell.TH.Syntax import Language.Haskell.TH.Lib here :: QuasiQuoter here = QuasiQuoter (litE . stringL) (litP . stringL) ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- -- There.hs {-# LANGUAGE QuasiQuotes #-} module Main where import Here (here) main = putStr [$here| Shall I say, I have gone at dusk through narrow streets And watched the smoke that rises from the pipes Of lonely men in shirt-sleeves, leaning out of windows? I should have been a pair of ragged claws Scuttling across the floors of silent seas. |] ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- [m@ganon a]$ ghc -O2 --make There.hs [1 of 2] Compiling Here ( Here.hs, Here.o ) [2 of 2] Compiling Main ( There.hs, There.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking There ... [m@ganon a]$ ./There Shall I say, I have gone at dusk through narrow streets And watched the smoke that rises from the pipes Of lonely men in shirt-sleeves, leaning out of windows? I should have been a pair of ragged claws Scuttling across the floors of silent seas. [m@ganon a]$ -----------------------------------------------------------------------------

6 7

ANNOUNCE: Salsa: A .NET Bridge for Haskell
by Andrew Appleyard 15 Oct '08

15 Oct '08

I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: > type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine ("Hello .NET World!") > type Hello.imports System.Console: WriteLine > msbuild > .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew

14 17

How to specify multiple fonts for xmobar?
by Magicloud 15 Oct '08

15 Oct '08

Hi, I am using xmonad + xmobar. And I am using sgi screen font. But sometimes I need to display CJK characters, which need another font. In gtk2 software, this is OK. I just specify the screen font for ascii. It can auto-choose a CJK font. Everything looks fine, maybe not pretty. While, xmobar does not auto-choose a CJK font, if I just specify screen font for ascii, it displays CJK characters in blank. How to fix this?

1 0

Foreign.Marshal.Error.void
by Mauricio 15 Oct '08

15 Oct '08

Hi, Wouldn't it be nice if we had something like 'void' in Foreign.Marshal.Error in standard monad functions, so that we could use it instead of, for instance, mapM_ or sequence_? Best, Maurício

4 3

There is something wrong with hprotoc-0.3.1 package.
by Magicloud 15 Oct '08

15 Oct '08

Hi, I wanted to install this package. Well, Building hprotoc-0.3.1... ... [3 of 7] Compiling Text.ProtocolBuffers.ProtoCompile.Parser ... Text/ProtocolBuffers/ProtoCompile/Parser.hs:48:0: Type synonym `GenParser' should have 2 arguments, but has been given 1 In the type synonym declaration for `P' And it just stopped here.

5 5

There is something wrong in derive-0.1.2 package.
by Magicloud 15 Oct '08

15 Oct '08

Hi, I wanted to install it with cabal. Well $ cabal install derive Resolving dependencies... cabal: Couldn't read cabal file "./derive/0.1.2/derive.cabal" As I traced a little, it seemed that line: 'build-depends: base == 4.*, syb' was wrong.

4 8

[ANN] Haskell Cheatsheet v1.0
by Justin Bailey 15 Oct '08

15 Oct '08

All, I've created a "cheat sheet" for Haskell. It's a PDF that tries to summarize Haskell 98's syntax, keywords and other language elements. It's currently available on hackage[1]. Once downloaded, unpack the archive and you'll see the PDF. A literate source file is also included. If you install with "cabal install cheatsheet", run "cheatsheet" afterwards and the program will tell you where the PDF is located. The audience for this document is beginning to intermediate Haskell programmers. I found it difficult to look up some of the less-used syntax and other language stumbling blocks as I learned Haskell over the last few years, so I hope this document can help others in the future. This is a beta release (which is why I've limited the audience by using hackage) to get feedback before distributing the PDF to a wider audience. With that in mind, I welcome your comments or patches[2]. Justin [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet [2] git://github.com/m4dc4p/cheatsheet.git

8 9

gtk2hs and GTK+OSX
by Jeroen Baekelandt 14 Oct '08

14 Oct '08

Hi, I was wondering if anybody managed to get gtk2hs working with GTK+OSX from http://www.gtk-osx.org/ I'm trying but there seems to be a quite long dependency list that keeps on building up. So I was wondering if it ends and if it works in the end. Thanks, Jeroen

2 1

Re: What I wish someone had told me...
by John Lato 14 Oct '08

14 Oct '08

While this may be true, it's missing the point. The claim that type classes are like interfaces (the usual argument is that they define an interface, but not an implementation) misleads OO-grounded programmers into thinking of type classes in terms of an already-familiar concept. This is bad because said programmers then attempt to apply familiar OO-styles, when they would be better off abandoning most of what they already know about design. I don't mean in the sense of "abstraction good, separation of processing good, repetition bad", but rather how to develop a useful/stable API, how to divide up the different processing the module should do, etc. In short, how to approach API design, which is very different in Haskell than the practice that most OO disciples are familiar with. IMHO, stating that type classes act like interfaces in argument types, but not return types, is too complicated a relationship to be useful to somebody's first introduction to FP. Better to avoid the whole issue completely. John Lato Alexey Romanov wrote: > > Well, they act like interfaces in argument types, just not variable or > return types. > > Yours, Alexey Romanov >

1 0

Congrats. to wxHaskell
by Don Stewart 14 Oct '08

14 Oct '08

I just want to congratulate the wxHaskell team on their new release. With GHC 6.10 RC, cabal 1.6, and cabal-install 0.6, I was able to simply, cabal install wxcore wx And it all worked. Well done! -- Don

5 5

hackage warning: Exposed modules use unallocated top-level names: ... what am I doing wrong?
by Thomas Hartman 14 Oct '08

14 Oct '08

However the package generated the following warnings: * A 'license-file' is not specified. * Exposed modules use unallocated top-level names: Algorithms everything fetchable with darcs get http://code.haskell.org/external-sort external-sort is on hackage and seems to work (you can run demo.hs after cabal installing) but I'd still like to understand if this warning is something I should pay attention to anyway.

1 0

Interesting new user perspective
by Don Stewart 14 Oct '08

14 Oct '08

http://sandersn.com/blog/index.php?title=two_weeks_of_haskell Has some good thoughts on what tripped him up in his first two weeks of Haskell programming. Anything people want to work on there? :-) Worth a read if you're thinking about how to make Haskell yet more accessible. -- Don

20 51

Associated Types and several Classes
by Martin Hofmann 14 Oct '08

14 Oct '08

> {-# OPTIONS_GHC -fglasgow-exts #-} > module Test where >import qualified Data.Set as S Hi. I try to model the following: Hypotheses are build up from Rules, which itself are made of the type Rule. Because I may change the implementation later, I want to use type classes, which define the signature of my functions I will use in other modules. >class CRule r >class (CRule (CRulesRule r) ) => CRules r where > type CRulesRule r >class (CRule (CHypoRule h), CRules (CHypoRules h) ) => CHypo h where > type CHypoRules h > type CHypoRule h > hypo :: > CHypoRules h -> > CHypoRule h -> > h -- | Rule >data Rule = Rule Int deriving(Eq,Ord) >instance CRule Rule -- | Rules >type Rules = S.Set Rule >instance CRules (S.Set Rule) where > type CRulesRule (S.Set Rule) = Rule -- | Hypothese >data Hypo = Hypo { open :: Rules > , closed :: Rules > } >instance CHypo Hypo where > type CHypoRules Hypo = Rules > type CHypoRule Hypo = Rule > hypo ro rc = Hypo { open=ro, closed=(S.singleton rc)} So far so good. But why does now the last of the following lines not type check? It says: Couldn't match expected type `CHypoRules h' against inferred type `S.Set Rule' Couldn't match expected type `CHypoRule h' against inferred type `Rule' >rule1 = Rule 1 >rule2 = Rule 2 >rule3 = Rule 3 >rules = S.fromList [rule1,rule2,rule3] >ahypo = hypo rules rule1 Shouldn't be (CHypoRules Hypo) be associated with Rules and similar (CHypoRule) with Rule? Thanks a lot, Martin -- --------------------------------------------------------------- Dipl.-Wirtsch.Inf. (E.M.B.Sc.) Martin Hofmann Cognitive Systems Group Faculty Information Systems and Applied Computer Science University of Bamberg http://www.cogsys.wiai.uni-bamberg.de/members/hofmann http://www.inductive-programming.org

2 2

couple of questions on monads
by Daryoush Mehrtash 14 Oct '08

14 Oct '08

Question 1: Why are there lazy and strict modules of some monads? (e.g. Control.monad.State) Question 2: If I define a new monad (say xyz), does it have to be as control.monad.xyz module? daryoush

4 4

Query regarding Type classes
by Arun Suresh 14 Oct '08

14 Oct '08

Hello folks, Im kinda new to haskell. Ive only been fiddling around with it for bout 3 - 4 weeks now. And for the life of me... i cant seem to figure out why this doesnt work : class Foo a where fooFunc :: a -> Int data FooData = FData instance Foo FooData where fooFunc _ = 10 class Bar a where barFunc :: (Foo b) => a -> b -> Int data BarData = BData instance Bar BarData where barFunc _ FData = 20 When I compile I get this : Couldn't match expected type `b' against inferred type `FooData' `b' is a rigid type variable bound by the type signature for `barFunc' at Sample.hs:16:20 In the pattern: FData In the definition of `barFunc': barFunc _ FData = 20 In the definition for method `barFunc' Think Im missing something really big... Could somebody kindly help me out here... Regards Arun Could so

5 7

Re: [Haskell-cafe] Still stacking monad transformers
by Tillmann Rendel 14 Oct '08

14 Oct '08

Dino Morelli wrote: > I was wishing I could do this: > > let foo = str `or-if-empty` default > > > If it was a Maybe, this works with mplus: > > (Just "foo") `mplus` (Just "bar") == Just "foo" > Nothing `mplus` (Just "bar") == Just "bar" > > > But not so much for list, mplus just ain't defined that way, instead > doing concatination: > > "foo" `mplus` "bar" == "foobar" > "" `mplus` "bar" == "bar" The difference between Maybe-style MonadPlus and List-style MonadPlus is discussed on http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. With that proposal, you could use morelse with both Maybe and lists. Personally, I would like to call these beasts <|> (for Maybe-style mplus) and <+> (for List-style mplus). One could even have a <| b = a <|> pure b a <+ b = a <+> pure b a +> b = pure a <+> b in the style of <* and *>. Note that I assume Applicative as a superclass of Monad, while I'm talking about a better world anyway. That said, I would consider using something like the <+> sketched here for Strings as a hack, because I do not see Strings as Chars under the List functor, even if they technically may be exactly that. Since "abc" does not represent multiple results, I don't think "" should represent failure. Instead, I would wrap optional strings in Maybe, and then use fromMaybe to handle the default values: fromMaybe "bar" (Just "foo") = "foo" fromMaybe "bar" Nothing = "bar" Now, with the operators sketched above, fromMaybe = flip (<|), so one could use Just "foo" <| "bar" = "foo" Nothing <| "bar" = "bar" which seems to closely correspond to what you want. Tillmann

1 0

Could not build win32 dll..
by Yakov ZAYTSEV 14 Oct '08

14 Oct '08

Hello, Sadly, I've found --mk-dll option unrecognized by latest stable GHC 6.8.3.. I'm new to win32 development How one can make win32 dll at the moment? I've successfully compiled Adder sources from example from section 11.5.4 of user guide I need to build dll to be called from foreign application The only way I see is to use MinGW's gcc which is shipped with GHC distrib to manually link everything GHC runtime needs Did I missed something? TIA -- Best wishes, Y

3 3

Still stacking monad transformers
by Andrew Coppin 14 Oct '08

14 Oct '08

I am becoming extremely frustrated now. The task I want to perform is simple, yet I simply cannot make Haskell do what I want. I've given up hope of ever getting my program to handle infinite result sets. That means I can make do with just ListT. So I have the following monad: type MyMonad x = StateT MyState (ListT Identity) x Now I'm trying to run two computations, starting from _the same state_, and combine the two resulting lists. The trouble is, I am literally losing the will to live trying to comprehend the whinings of the type checker. The operation I'm trying to perform is perfectly simple; I don't understand why this has to be so damned *difficult*! >_< Any suggestions? I found that by using the brief and easily memorable construction "runIdentity $ runListT $ runStateT foo state" I can get at the result set for each action, and combine them. But nothing in hell seems to transform this from [((), MyState)] back into MyMonad ().

9 12

Overlapping/Incoherent instances
by J. Garrett Morris 13 Oct '08

13 Oct '08

Hello everyone, As part of a project to formalize the theory of overlapping instances, I'm looking for examples of overlapping and incoherent instances and their usage. One such example would be the old version of the Monad Transformer Library, which used overlapping instances together with MonadTrans. Any other examples or suggestions would be greatly appreciated! Thanks, /g

5 6

ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2
by Ivan Lazar Miljenovic 13 Oct '08

13 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to announce version 0.4 of my Graphalyze library [1] and 0.2 of my SourceGraph programme [2]. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph This should fix the bugs reported by Gwern Branwen, Magnus Therning (thanks to Niklas Broberg for stating the correct version for Haskell-Src-Exts) and Christopher Hinson. No really new features are included in this release. I was planning on fixing this and releasing it sooner but - to utilise what seems to be a current meme [3] - "I accidentally my Gentoo" on Tuesday night and only fixed it yesterday. [3] http://encyclopediadramatica.com/I_accidentally_X Since I'm more awake now than I was when I made the initial release, here's a run-down of what SourceGraph is: SourceGraph is a programme designed to help you analyse the static complexity of your Haskell code when represented as a graph. At the moment, it does the following (M == for each module, I = for imports, C = the whole codebase): * Visualise it {M,I,C} * See a "collapsed" visualisation {M} * Proposed module/directory layout using two different algorithms {I,C} * See the "core" visualisation (recursively strip off roots/leaves) {M} * Calculate the Cyclomatic complexity [4] {M,I,C} * Root analysis (compare what's exported to what actually is a root) {M,I,C} * Determine how many components you have, to see if you should split {M,I,C} * Clique Analysis (find co-recursive functions) {M,C} * Cycle analysis (non-cliques) {M,I,C} * Chain detection (e.g. "straight-line" functions/imports) {M,I,C} [4] http://en.wikipedia.org/wiki/Cyclomatic_complexity Current limitations: * An automatic refactoring tool: SourceGraph gives *you* information on how you might want to possibly refactor your code. It's not smart: it can't tell that you've clumped functions foo and bar in the same module because they do similar things or because it's a utility module, even though they're not related. For automatic refactoring, see something like HaRe [5]. * SourceGraph ignore's "data-based" functions, i.e. record-functions and class/instance declarations, as it's too confusing (IMHO) which actual function you mean (if you see "show" being called, is it for Int, Double, or something else?). * Despite using Haskell-Src-Exts, some extensions (e.g. TH) are ignored, mainly because I have no idea how they work and nothing to test it on. GHC extensions should be supported (read the parser won't choke on them) though. * Reporting output is currently rather limited: - The report will be generated in a subdirectory called "SourceGraph" of the codebase directory; this is currently hardwired in. - It will produce an all-in-one html file report, with no fancy CSS magic to make it look pretty. Ideally, it would produce a split-file, and allow you to choose output format. - Large graphs are shrunk down to being a maximum of 15"x10". Ideally, I'd like to extend this later so that large graphs will have a shrunk version in the graph, which link to a larger version (note though that these graphs get very large very fast). - The output of individual function names, etc. could be improved. [5] http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html SourceGraph can be installed with cabal-install. Once you've done so, you can analyse a cabalized library/application Foo as follows: $ SourceGraph /path/to/codebase/Foo.cabal Report generated at: /path/to/codebase/SourceGraph/Foo.html This has been written as part of my mathematics Honours Thesis, "Graph-Theoretic Analysis of the Relationships in Discrete Data". Since I've actually got to write the thesis up now, I won't be making any more releases for a while. After uni is over for the semester though, I hope to tidy it up and extend it. If you want to check the code out yourselves, there's also darcs repositories for Graphalyze [6] and SourceGraph [7]. [6] http://code.haskell.org/Graphalyze [7] http://code.haskell.org/SourceGraph/ Note that whilst Graphalyze is fully documented, etc., the internals of SourceGraph are a bit fugly (mainly due to time constraints). Enjoy! - -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjyAacACgkQfEfFJ9JhvyiHEACfVVuRk2FR3ZQiJ6H18FFK/de/ sukAn0tuCLwqxmzlQvWicQKQ3qEJKC1K =HRUK -----END PGP SIGNATURE-----

4 6

Re: [Haskell-cafe] Haskell in Artificial Intelligence
by Martin Hofmann 13 Oct '08

13 Oct '08

Hi Christos, We and a colleague from Japan use Haskell for Inductive Functional Programming, i.e. learn programs from examples. However, we just have started to port our program to Haskell: http://www.cogsys.wiai.uni-bamberg.de/effalip/ Susumu Katayama has already a Haskell library: http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.html More information about IP can be found here: http://www.inductive-programming.org/ What kind of survey are you doing? Do you have a pointer, too? Greetings, Martin

2 1

Haskell on mobile platforms
by Janis Voigtlaender 13 Oct '08

13 Oct '08

Hi all, there were several discussions on this list about different implementations of Haskell running on the iPhone and other mobile platforms over the last three months or so. I would very much like to see the current state of what is and is not yet possible here reflected in the "Platforms" section of the upcoming edition of the Haskell Communities and Activities report. So please, if you have been working on getting Haskell to run on your phone, and even more so if you were successful, write a short HCAR entry about it. For further details, see: http://article.gmane.org/gmane.comp.lang.haskell.cafe/45967 Thanks, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

the ghc "reflection" thing?
by Galchin, Vasili 13 Oct '08

13 Oct '08

hello, Several months ago I saw on the wiki or maybe it was a discussion on mechanism to get the ghc compiler's state. I can't remember enough to ask even well. I know there is a wiki entry. Sorry ... I can only "hint" at this ... ?? Thanks, Vasili

2 2

Constraints at construction
by Iain Barnett 13 Oct '08

13 Oct '08

If I were to create an object in C#, for instance, I could add code to the constructor that might limit the type further e.g. public class Car { string model; int wheels; public Car ( string model, int no_of_wheels ) { if ( no_of_wheels <= 2 ) { throw new Exception( "a car must have at least 3 wheels"); } this.model = model; this.no_of_wheels = no_of_wheels; } } or I could specify all sorts of things, like the size of an array could only be a certain length, or whatever. Similarly, when creating a column with SQL I'd be able to specify further constraints on the column than just it's type. I don't see how to do this with Haskell and the data keyword. Is there a tutorial someone could point me to, or an explanation of this? Or is it that I have to wrap the creation in an accessor function that checks the inputs first? type Model = String type Wheels = Int data Car = Car Model Wheels car_maker model wheels = if wheels <= 2 then error ... else Car model wheels ? Most of my programming career (if you can call it that:) has been primarily with C# and SQL, and perhaps this heady mixture of OOP and hacked-functional is confusing me! Iain

5 6