[Haskell-cafe] Re: Haskell Cookbook?

[apfelmus at quantentunnel.de]

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
ephemeral).

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
with.

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.


Regards,
apfelmus