mutable records

[Alastair Reid]

> In Haskell one can use existential lists but I doubt about the
> efficiency.

Existential lists don't have any special time overhead.  All you're
doing is making the typechecker happy about what you're doing.

Of course, there's a small overhead in that any function you invoke on
that object will almost certainly be an indirect function call rather
than a direct function call so you get the same (small) overhead as in
C++ virtual function calls, Haskell method calls (when not optimized
away), etc.

> It is not my aim to make of everything an object like in Jave
> e.g. . The objects I have in mind are showable ojects: windows,
> scrollbars, messageboxes, etc. . Of such objects I demand fast
> response with respect to key input or mouse clicks. I am sure Ocamel
> can do that.

We're sure Haskell can too.

You can probably translate your OCaml code fairly directly into
Haskell but directly translating code which uses mutable state tends
to result in unidiomatic Haskell code.  If you want nice Haskell code
(i.e., which exploits Haskell's strengths, plays well with other
libraries, etc.) it's often best to think about the problem you're
trying to solve and find a way to express that in Haskell instead of 
trying to express the standard solution in Haskell.

For example, C/C++/Java GUIs are usually implemented by creating a
bunch of objects and then connecting the objects together by invoking
methods on them to add event handlers, etc.  Such programs almost
never change the object interconnections after this initialization
phase.  In effect, we have a bunch of single-assignment variables:
they get initialized but never change after that.  

Haskell has single-assignment variables too (i.e., the normal,
non-mutable variables you learn about on page 2 of any Haskell
textbook) and you can often use them to express the connections
between the objects.  Doing this has an enormous benefit that you
don't get in C, C++, Java, etc. which is that Haskell's typechecker
can catch some of the errors you might make when making these
object interconnections.

This example probably doesn't apply to your code but it's an example
of how you can eliminate gratuitious use of mutable variables from
your code.  The key is to ask us about the problem you're trying to
solve not ask how to express the standard (imperative) solution in
Haskell.


-- 
Alastair Reid                 alastair@reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/