[Haskell-cafe] Rethinking OO idioms

[Mikael Brockman]

John Goerzen <jgoerzen at complete.org> writes:

> I've worked with languages with object-oriented features for awhile
> now.  Python and OCaml, the two with which I work the most, both have
> OO.
> 
> One of my first projects in Haskell would be to write a Haskell
> version of Python's ConfigParser[1] class.  I wrote[2],[3] a version
> of this for OCaml that works very well.
> 
> In a nutshell, ConfigParser is a utility for working with sectioned
> configuration files in a style similar to the familiar .ini files from
> Windows.  It has methods to read a configuration file, get/set the
> items that are being configured, and write a new file back out.  This,
> then, is a fairly typical metaphor for OO programs: an instance of a
> class has some state that can be accessed or modified, and possibly
> stored and retrieved.
> 
> So I am thinking about a ConfigParser for Haskell.  The first thing
> that occured to me is that Haskell has no OO features, so I'm not sure
> what is the best way to handle the "class" and its various methods.

I would expect these signatures:

| module Configuration where
|
| type Key = String
| type Value = String
| type Configuration = FiniteMap Key Value
|
| read   :: FileName -> IO Configuration
| write  :: FileName -> Configuration -> IO ()
| update :: Configuration -> Key -> Value -> IO ()
| lookup :: Configuration -> Key -> Value

> The next thing that occured to me is that, unlike OCaml and Python
> classes, Haskell has no mutable variables.  A call like
> config.setOption("main", "initpath", "/usr") in Python -- which alters
> the state of the config object and returns nothing -- would be
> impossible in Haskell (unless perhaps the FiniteMaps are mutable
> somehow?)

The purest approach is to have every configurable function accept a
Configuration.  Functions that in Python would alter the dictionary
would simply return a new one.