October 2008 - Haskell-Cafe

About do notation.
by Magicloud 16 Oct '08

16 Oct '08

Hi, As some articles say, do notation is expand to (>>) and (>>=) when being compiled. So I want to know the details. Like: main = do a <- getArgs b <- getLine myFunc1 (head a) b myFunc2 b (head a) I cannot figure out what is the (>>) and (>>=) way of this. Thanks.

6 5

Re: Where did House/hOp go?
by Kenny Graunke 16 Oct '08

16 Oct '08

Hello! On Thu, Oct 16, 2008, Donnie Jones <donnie at darthik.com> wrote: [snip] > The site is working for me even now. > Unfortunately, the site hasn't really been updated much over the past > couple of years and when I e-mailed some people on the Programatica > project about the status of House & Osker I never got anything back. > The biggest obstacle you may find when trying to set up House & hOp is > that hOp is based upon a modified version of a very old GHC and from > the last time I looked at it the GHC runtime has changed enough that > making a new hOp will be non-trivial. Indeed! House 0.8, as listed on the official programatica page, is based on GHC 6.2...not so fun to work with these days. I've spent the last year or so working on House as part of my research, and have updated it to GHC 6.8.2 (with a lot of help). You can get a copy of my unofficial "House 0.8.91" sources here: http://web.cecs.pdx.edu/~kennyg/house/ It's still a bit of a challenge to build. Notably, you'll need a 32-bit Linux system - it doesn't build on 64-bit linux nor Mac OS X (yet). If you just want a floppy image, you may as well stick with House 0.8 from http://programatica.cs.pdx.edu/House/ ... it's basically the same. --Kenny

2 1

Re: Haskell-Cafe Digest, Vol 46, Issue 118
by Alberto G. Corona 16 Oct '08

16 Oct '08

>Personally, I'm loving the whole concept of this puppy: > GHC.Prim.*reallyUnsafePtrEquality# >I have absolutely no idea what it does, but it must be something really >unsafe! ;-)i I really need reallyUnsafePtrEquality# !!!!! . I need it in inside GHC.Exts if GHC.Prim is being removed. Please!.. I´m involved in a project for storage and retrieval of heavily autoreferenced data structures. This functionality is absolutely needed for that!!.

1 0

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

16 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 16 Oct '08

16 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 16 Oct '08

16 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 16 Oct '08

16 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 16 Oct '08

16 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 16 Oct '08

16 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 16 Oct '08

16 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