mutable records

2002-09-03 Thread Scott J.



Hi,

Is it possible to define oject 
types in Haskell and what does one propose to do it?

Is it possible to define parts of a record 
with the help of the ST s monad mutable during 
the whole program? (As is possible in Ocamel)?

Thx

Scott




Re: mutable records

2002-09-03 Thread Manuel M T Chakravarty

Scott J. [EMAIL PROTECTED] wrote,

 Is it possible to define  oject types in Haskell and what does one propose to do it?

Depends on what you mean by object types.  You can surely
define a record with funcions dubbing as methods and
non-functional values dubbing as object data.

 Is it possible to define parts of a record  with the help of the ST s monad mutable 
during the whole program? (As is possible in Ocamel)?

Just make the fields that you want to update be values of
`STRef s a'.  (You can also do the same with the IO monad
and `IORef's.)

Having said this, there are not that many situations where
you need to do this (and in consequence ST-monadify your
program).  Purely functional updates (using the record
syntax) where the system effectively copies the whole record
(not all data in it, just the references to that data) is
perfectly suitable in most cases.  If you are concerned
about efficiency first profile the code to see whether the
performance bottleneck is really where you think it is.

Cheers,
Manuel
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe



(no subject)

2002-09-03 Thread Chris . Angus

Does anyone know what happened to the wiki on haskell.org?

There was lots of stuff there last year (mostly to do with design patterns) which seems to have been lost.
Some of the links are still there but they don't go anywhere.

Cheers

Chris

Wiki problems

2002-09-03 Thread John C. Peterson

We're aware of the wiki problems.  We've got out wiki guy working on
it and I hope everything will be working again soon.  We won't lose
anything that's been posted to the wiki.  Please be patient!

  John

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe



Re: mutable records

2002-09-03 Thread Scott J.

Sorry for my late reply,

But is it possible to be more specific (little examples)

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

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.

Regards

Scott
- Original Message -
From: Manuel M T Chakravarty [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, September 03, 2002 10:37 AM
Subject: Re: mutable records


 Scott J. [EMAIL PROTECTED] wrote,

  Is it possible to define  oject types in Haskell and what does one
propose to do it?

 Depends on what you mean by object types.  You can surely
 define a record with funcions dubbing as methods and
 non-functional values dubbing as object data.

  Is it possible to define parts of a record  with the help of the ST s
monad mutable during the whole program? (As is possible in Ocamel)?

 Just make the fields that you want to update be values of
 `STRef s a'.  (You can also do the same with the IO monad
 and `IORef's.)

 Having said this, there are not that many situations where
 you need to do this (and in consequence ST-monadify your
 program).  Purely functional updates (using the record
 syntax) where the system effectively copies the whole record
 (not all data in it, just the references to that data) is
 perfectly suitable in most cases.  If you are concerned
 about efficiency first profile the code to see whether the
 performance bottleneck is really where you think it is.

 Cheers,
 Manuel


___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe



Re: mutable records

2002-09-03 Thread 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 [EMAIL PROTECTED]  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe