
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

"Scott J."
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

hi, Manuel M T Chakravarty wrote:
... 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.
one situation in which i find mutable fields easier to use rather than pure updates is if the record is deep into another data structure (e.g. a list of records). modifying a record than becomes a hassle as one has to remove it from the list, create the new record, and then insert it in the list. this is particularly inconvinient if the order of the records in the list actually matters. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

"Scott J."
wrote, Is it possible to define oject types in Haskell and what does one
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"
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

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/

Hi,
You gave me a lot of thinking about .
Sill I want to make objects packed with their objects and functions. Doesn't
mean that I have to use existential data types?
Scott
----- Original Message -----
From: "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/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Sill I want to make objects packed with their objects and functions. Doesn't mean that I have to use existential data types?
Only if you need to hide the type of the object. If you don't need to hide the type then Haskell's typeclasses give you (what I understand of) what you want. I can write polymorphic functions which take an arbitrary type of object and invoke methods like ==, + and show (say) on it. foo :: (Eq a, Num a) => a -> String foo x = if x == 0 then "" else show (x+1) Actually, I suspect this is not quite what you want but the word 'object' has been used by so many people to mean so many things that it's only by throwing out strawmen like Haskell's typeclasses that we can understand what you actually do mean. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

"Object" in common parlance is an amalgam of: data structure, methods for that structure, state-boxes, and compositions of this amalgam. All developed over time using the age old method of accretion. It says something when Scott Meyer can make a living writing books about what you shouldn't do in C++. There's also a fellow who's put together an interesting piece of criticism of OO: http://www.geocities.com/tablizer/oopbad.htm. Shawn On Thursday 05 September 2002 12:58 pm, Alastair Reid wrote:
Sill I want to make objects packed with their objects and functions. Doesn't mean that I have to use existential data types?
Only if you need to hide the type of the object.
If you don't need to hide the type then Haskell's typeclasses give you (what I understand of) what you want.
I can write polymorphic functions which take an arbitrary type of object and invoke methods like ==, + and show (say) on it.
foo :: (Eq a, Num a) => a -> String foo x = if x == 0 then "" else show (x+1)
Actually, I suspect this is not quite what you want but the word 'object' has been used by so many people to mean so many things that it's only by throwing out strawmen like Haskell's typeclasses that we can understand what you actually do mean.

Scott J. writes: : | Sill I want to make objects packed with their objects and | functions. Doesn't mean that I have to use existential data types? Sometimes you can avoid using existentials by making all your object-updating functions return the post-update object explicitly. For example: module FiniteMap where data FM k v = FM {set :: k -> v -> FM k v, get :: k -> Maybe v, toList :: [(k, v)]} module RedBlack(empty) where import FiniteMap empty :: Ord k => FM k v -- a finite map implemented as a red/black tree ... In this case, the red/black tree itself is effectively a private field of the object. The privacy is achieved by *not* making the tree a field of the FM record. Instead, it gets passed around as the parameter of an auxiliary function: -- module RedBlack, continued empty = fm emptyRedBlackMap fm rb = FM {set = \k v -> fm (extendRedBlackMap rb k v), get = \k -> ..., toList = redBlackMapToList rb} HTH, Tom

hi,
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)?
you can find an example of how to do that at: http://icfpcontest.cse.ogi.edu/simulator/ look inside module Robo for example. there you will find examples of records with mutable fields and some useful functions to manipulate them. the state of the "objects" is not hidden so it is available for anyone to modify. to hide the state you could use fancy types as people already pointed out, or you could use the Haskell module system. unfortunatelly with the Haskell module system approach you soon run into recursive modules (when objects depend on each other) and this is not well supported by Haskell implementations at the moment. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

Hi, thx for this reply. Is there any overhead using this mutable? Are you also using Templates ? With this mutable I can adapt a lot of software from Ocamel. But the gnawing question remains: Shall it be possible to be almost as efficient (in native code) as Ocamel's code, I refer here to Doug Bagley's comparison of programming languages. Remarkably the fibonacci numbers test scores almost as well. But the code is not the same. Comparable code would have been to use the same code of Ocamel, to be more specific: how efficiently is recusivity implemented in Haskell. I cannot compare this on my Windows XP since I need MSVC6.0 on this machine which I don't have. On the other hand I have cygwin installed now. Unfortunately I can't make makefiles. Probably on the web I can find an explanation. In this way I can recompile Ocamel with Cygwin and compare the results a bit. There are also 5(?) failures of Haskell programms . Is there a flaw in these programms? Thx Scott P.S. does anyone know a good Haskell IDE for Windows XP? ----- Original Message ----- From: Iavor S. Diatchki Cc: haskell-cafe@haskell.org Sent: Monday, September 09, 2002 10:45 PM Subject: Re: mutable records hi,
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)?
you can find an example of how to do that at: http://icfpcontest.cse.ogi.edu/simulator/ look inside module Robo for example. there you will find examples of records with mutable fields and some useful functions to manipulate them. the state of the "objects" is not hidden so it is available for anyone to modify. to hide the state you could use fancy types as people already pointed out, or you could use the Haskell module system. unfortunatelly with the Haskell module system approach you soon run into recursive modules (when objects depend on each other) and this is not well supported by Haskell implementations at the moment. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ================================================== _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi, thx for this reply. Is there any overhead using this mutable?
I just thought I should point out that "Mutable" is not an haskell type. You can see in the Utils module that it is just a type synonim for IORef: http://icfpcontest.cse.ogi.edu/simulator/pfe.cgi?Utils#Mutable http://haskell.cs.yale.edu/ghc/docs/latest/html/base/Data.STRef.html I think that sometimes STRef might be a better choice...
Are you also using Templates ? With this mutable I can adapt a lot of software from Ocamel.
I think this John Hughes paper "Global Variables in Haskell" might be usefull to you: http://www.math.chalmers.se/~rjmh/Globals.ps
But the gnawing question remains: Shall it be possible to be almost as efficient (in native code) as Ocamel's code, I refer here to Doug Bagley's comparison of programming languages. Remarkably the fibonacci numbers test scores almost as well. But the code is not the same. Comparable code would have been to use the same code of Ocamel, to be more specific: how efficiently is recusivity implemented in Haskell. I cannot compare this on my Windows XP since I need MSVC6.0 on this machine which I don't have. On the other hand I have cygwin installed now. Unfortunately I can't make makefiles. Probably on the web I can find an explanation. In this way I can recompile Ocamel with Cygwin and compare the results a bit. There are also 5(?) failures of Haskell programms . Is there a flaw in these programms? P.S. does anyone know a good Haskell IDE for Windows XP?
I don't really use windows but I know there is support for the windows version of JCreator: http://www.students.cs.uu.nl/people/rjchaaft/JCreator/ You can always use Xemacs :) http://www.xemacs.org/Download/win32/ http://www.haskell.org/haskell-mode/ J.A.
participants (8)
-
Alastair Reid
-
Iavor S. Diatchki
-
Jorge Adriano
-
Manuel M T Chakravarty
-
Scott J,
-
Scott J.
-
Shawn P. Garbett
-
Tom Pledger