[Haskell-cafe] Re: Haskell Cookbook?

apfelmus at quantentunnel.de apfelmus at quantentunnel.de
Wed Jan 31 05:16:02 EST 2007

Alexy Khrabrov wrote:
> Reflecting why it's harder to pick up
> Haskell than say Ruby or Python, here's what I found -- those
> languages deal with a typical domain available to any programmer --
> his own computer/system/shell.  The artifacts are files, directories,
> timestamps, etc.  The stuff every programmer understands in their
> sleep.  APIs.  So I loved the shell-script beautification thread.

Note that there is an inherent difficulty with files, directories,
pipes: they are not purely functional in style.

While it's unavoidable that

    writeFile :: FilePath -> String -> IO ()

is in IO, I think that

    readFile :: FilePath -> IO String

would not need to be in IO if the file system would be persistent (not

Pipes are an ugly way to implement lazy evaluation. For instance, take
the pipe "ls -l | grep '*.hs'". To achieve the effect that "grep"
immediately feeds on the data "ls -l" spits out, both programs are run
concurrently and blocking keeps in line. This does not generalize so
well to multiple data sources, something lazy evaluation has no problems

And one of the main problems is that current OS see programs as things
of type "String -> IO String". Of course, pure and strongly typed
programs would be preferred. So, instead of calling

    system ("ghc -O2 -c " ++ show filepath)

we want

    GHC.desugar  :: GHC.Haskell' -> GHC.Core
    GHC.optimize :: GHC.Core     -> GHC.Core
    GHC.assemble :: GHC.Core     -> OS.Program

In a sense, current OS are not ready for Haskell yet.


More information about the Haskell-Cafe mailing list