Hey, Haskellers,
I've started writing my first non-toy program in Haskell [1], and things
are starting to click, at least a little bit---I find myself working
around the periphery, building functions that perform particular
operations, testing them in ghci, then figuring out how to link them up.
I at least don't feel perpetually stupid any more.
Anyway, I find myself with a couple of questions. The first, I guess,
is one of style: One Big Monad, or Several Smaller Monads?
I gather a lot of programs create a big RWST IO (or something of that
ilk) that sits at the heart of the action, and then thread that through
the whole program.
However, because I am developing in little pieces, I found myself
writing, for instance, a routine that used a WriterT IO to find all the
.info files in the directory and grab their contents and returning them
as a [(filename,contents)], which I could then parse and act upon. I'm
thinking of doing roughly the same thing for the processing of scraping
web information---creating a separate WriterT IO that goes and grabs the
content and delivers it back for parsing.
Is there a consensus that one approach is better than the other? I
guess I feel like doing it this way is really pushing me to isolate my
imperative vs. pure code, but then, it's all feeding back to processes
running in the IO monad anyway, so am I just being prissy? Are people
likely to look at my code and wonder Just What The Hell Is Going On?
The second question is one of libraries, I guess. The process I've
spec'd consists of several fairly discrete operations that have a couple
of paths through them, some of which are recursive.
For instance, if you're given a project name on the command line, you
need to hit the web site, scrape some info, get the source, unpack, walk
and parse the contents, and then generate the debian files...but if
you're called without a project name (to make updating easy), you need
to check the current dir to walk and parse the contents, figure out your
project name and version, *then* hit the website, scrape some info,
check the version numbers, perhaps get the source and unpack in which
case you need to walk and parse the contents again, then finally
generate the debian files.
When I implemented this in Perl, I actually used lazy attributes on a
central object to make most of these processing dependencies implicit
rather than explicit. It seems like this should be even easier in
Haskell, so I was wondering if there was a component out there already
that made it easy to express these sorts of dependencies to be "solved"?
I appreciate any suggestions or guidance.
Thanks,
Mike.
1. The program is one for generating the Debian packaging files for
Drupal modules (yes, I know one already exists, I've already
re-implemented it once in Perl, so this will actually be version #3),
which is an easily explained task which nonetheless hits a lot of
capabilities (http, html parsing, untar/gz ing, reading and parsing
files, generating files from templates, etc) I would like to explore.
