Fri, 4 Aug 2000 08:42:16 -0700 (PDT), Richard Uhtenwoldt <[EMAIL PROTECTED]> pisze:
> and I'd like to hear what Marcin thinks, too: is the IO monad
> outside the beautiful core of Haskell?
Some things are best expressed functionally, others - imperatively.
Many things can be done either way. It's bad when a language forces
the worse variant for some of them. A good language must be able to
express both.
Haskell makes the functional part the default. Balance of heavy
notation is shifted towards making the imperative part more verbose,
compared to average languages (e.g. it completely specifies the
order of imperative operations, yet without arbitrary rules for
evaluation order of subexpressions). So in this sense IO is ugly:
when a thing can be equally well done in functional or imperative
style, in Haskell the functional variant will look nicer, and tiny
bits of imperativeness can obfuscate large parts of code.
It does not mean that the IO monad is evil. It's just not meant
to be used when it's not necessary, because it's generally easier
to maintain functional code. For cases where it's necessary, or is
essential for performance, Haskell should provide imperative data
structures and support imperative programming in libraries too.
The IO monad is worth good support.
<http://www.qss.cz/bench/> is a simple benchmark. I tried to do it
in Haskell and the results were very bad. Elegant code and horrible
efficiency. GHC does not provide a hash table. The logarithmic
factor of FiniteMap justifies the difference, so the core language is
probably fast enough - a hash table should help, at least for speed
(unfortuinately it will not help with memory which is the worst
problem here).
A hash table by nature is as imperative as arrays: an update must
either be in place or copy a linear chunk of data. This is a reason
why FiniteMap uses balanced trees, and why Haskell uses lists much
more than arrays. The IO / ST monads and {IO,ST}{Ref,Array} extensions
already provide the needed core, but there are not enough higher level
libraries. This case cries for a hash table, another might need an
extensible imperative array.
A month ago on comp.lang.functional there was a discussion about
arrays with a functional interface and a hackish implementation with
destructive updates, providing fast access to the latest version
and worse to previous ones. It should be a good solution where the
functional style is appropriate but efficiency requires more than
mere Array or FiniteMap can provide.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
