[Haskell-cafe] real haskell difficulties (at least for me)

[Regis Saint-Paul]

Hi, 

I’ve seen many times the monad topic coming around on the cafe and plentiful
tutorials on monads have been published. However, as a complete Haskell
newbie coming from OOP, I felt monads were not particularly difficult to
grasp, and very exciting to work with. 

During my experiments with Haskell so far, the main problems I kept bumping
into were not related to the language but to its libraries: their
compilation and installation. Unfortunately, this topic has not received
nearly as much attention. I was unable to find a comprehensive tutorial on
how to deal with the variety of problems I get when trying to install
Hackage packages. This turned out to be (and still is) THE main source of
wasted time and headaches. And worse, unlike type problems, these are not
interesting ones to solve. 

Thus, as a beginner, the package management is what is really getting in the
way of switching to Haskell--not the language. Even books like Real World
Haskell (otherwise excellent) ignore entirely the topic. Cabal and
Cabal-install are clearly wonderful applications that make installing most
packages very straightforward. Unfortunately, whenever this "standard"
method for package installation fails (or when it is not available as with,
e.g., gtk2hs), I find myself in complete disarray. 

Below are some of the questions and issues I faced regarding package
management: 

- For a number of packages, cabal-install gets stuck and has to be killed. I
assume this is due to some difficulties in solving the dependencies and it
is fine, not all can be automated and cabal-install is not responsible for
poor packages. But the question then becomes what to do from there? Is their
some method to solve dependencies? How should we proceed to "debug" a
package installation? How do gurus deal with that? (maybe some less known
command line arguments? Or ways to figure out the problem and work out its
solution (cabal-install is silent in such case)? In particular, how to know
why did cabal get stuck in the first place?

- Some packages on Hackage are reported as not building successfully with
GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
and the later might depend on the former...What is one supposed to do in
such case? For example, is it an appropriate way to proceed to compile a
package with one version of GHC and then use the compiled package with
another version of GHC? Is it safe? What could possibly go wrong? If it is
the right way to go, how should we setup the two GHC versions? For instance,
should we have a shared package configuration file and choose through the
path which GHC is used or is there nicer way to set this up?
 
- Taking for example the "encoding" package on Hackage. Last time I tried,
the log was saying it fails to build on GHC 6.10, however, looking inside
this Hackage log, I could see a successful compilation using "preferred
versions". So it looks as if the thing can be compiled somehow. What should
one do with this information? If cabal manages to compile it using this
method on Hackage, then isn't cabal install just doing it on my disk? Is it
possible through some command line? Is it possible manually (without
cabal-install) and, if so, how? (I tried to copy-past the build instruction
as it appeared on the log...that somehow compiled, but then, I failed to
figure out how to install...) 
  
- I’m primarily a windows user and lots of my initial struggles probably
came from that. After many difficulties, I figured out that installing MinGW
and MSys was *THE* way to get a bit more of the things working. First, a lot
of time would be saved by just saying clearly on the GHC download page that
MinGW and MSys are mandatory installation (or even package that with GHC for
the windows distribution if license allows, who cares the extra few Mb).
Even if that is not technically exact, i.e., even if ghci and many trivial
command line programs can work without, MSys and MinGW turn out to be quiet
necessary whenever trying to install anything producing side effect. Making
it plain that these two are necessary would real come has a great time
savers for newbie like me on windows (personal opinion of course). Or, if
another path exists to go without these two, I'd be very glad to learn.
Besides, even these tools basic installation is not enough, you need
automake and various things of the like. That makes me wonder if the most
precious skill for programming with Haskell would not be a strong C/C++
programming background. 
 
- In face of the difficulties with windows, I switched to Linux. While some
things worked better, there were still lots of difficulties with package
compilation. For instance, it is very difficult to figure out which Linux
packages of a given distribution are needed for compiling this or that
package. Again, gtk2hs is epitome here: which C development packages are
needed to compile it is obscure at best (cairo, codeview, etc...). I ended
up querying the Debian package management with any keyword found after
running gtk2hs and randomly installing all the dev packages...And when
gtk2hs finally compiled, it failed to install anyway. As of today, I’ve
never been able to compile even the dumbest demo using gtk2hs whether on
linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the
automated setup install worked but did not allow me to compile with codeview
and I still do not know how to add codeview to the install packages. Trust
that I tried hard and read the docs thoroughly. Gtk2hs is just on of many
examples; I had problems under Linux also with, e.g., Happs, yi, database
things, etc. and figured out that the situation was roughly identical to
windows with MSys and MinGW. So Linux appears not to be the right solution
here. Maybe it's just that Linux users are more experienced with the GNU
C/C++ libraries...but it won't help a windows user to switch to Linux since
this knowledge can't be built out of thin air. 

- Would there be some binary version of cabal targeting various OSs? I
believe the Haskell platform project is about that. But without waiting for
a fair and objective selection of the packages (it seems to be the current
status of the project), I’d be happy working with some authoritative bundle
produced by a Haskell guru and would trust his subjective choices (who am I
to question these choices anyway). Or even an image (e.g., virtual box or
Xen) of a fully setup development environment since there are so many
dependencies involved in, e.g., simply compiling GHC... 

Now, one might argue that these are not Haskell problems, that they are
normal when dealing with non-mature packages. So let me explain why I've
been trying hard to install these packages: 

As a beginner with no experience with emacs, I tried to find some IDE-like
environment which would, at least, save me from manually reloading files in
ghci or help me browse the source files. Following the Haskellwiki advice,
that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension.
To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows.
I had to resort to learning emacs which seems the only sensible choice
available today.  

I am particularly unskilled, no question here. But, would a charitable soul
take the pain of writing a comprehensive package management tutorial instead
of a monad one, (s)he would have my deepest gratitude :)

Apologies for the long mail.

-Regis

P.S. People on #haskell are wonderful. They helped me solve many issues.
Unfortunately, solving specific instances of problem did not contribute much
to a deeper understanding of the internal working. I find myself randomly
trying things without knowing which would work or why; Hence this plea for a
tutorial.