Home » forums » LtU Forum

Mutable objects with monadic methods

Hi! This is my first post, and I am just a Ph.D. student, so please be twice patient in case my question is really dumb.

I was wondering if anyone ever tried mixing monads (especially state/continuation monads) and object encodings to achieve an "Objective Haskell". This way we could get mutable objects which behave very closely to Java/C# ones and with a relatively similar syntax thanks to syntactic sugar for monads.

By giuseppemag at 2010-02-08 19:37 | LtU Forum | previous forum topic | next forum topic | other blogs | 7048 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

O'Haskell

O'Haskell main page

Rationale: A Monadic approach to Objects

Also, OOHaskell [LtU], though I first confused it with O'Haskell.

However, objects in O'Haskell are highly concurrent, which deviates considerably from Java and C++ effects. I think this is a good thing, but it might not match your goals.

By dmbarbour at Mon, 2010-02-08 20:42 | login or register to post comments

subsumed, apparently

by Timber? (i hope Timber gets traction, it seems like there are some fun ideas there.)

By raould at Mon, 2010-02-08 22:25 | login or register to post comments

Lecture: Object Encoding in Haskell

In Lecture: Object Encoding in Haskell, Ralf Lämmel shows a few ways to encode an object. At the end he discusses a mutable encoding using the IO monad.

By RayNbow at Mon, 2010-02-08 23:42 | login or register to post comments

Thanks. If I understand

Thanks. If I understand correctly, we have reactive, message-passing objects on one hand (Timber, O'Haskell) and mutable objects based on the IO monad on the other.

With respect to O'Haskell, is the IO monad a bit too opaque? Couldn't they just turn
setX :: int -> Shape
into
setX :: int -> Shape-> Unit,Shape
and use it in the state monad?

By giuseppemag at Tue, 2010-02-09 06:26 | login or register to post comments

Reactive Objects

I suspect hooking to the IO monad much better allows reactivity to hardware and network resources. It also allows capturing some non-determinism for the ordering of operations when, say, two concurrent objects each invoke a shared reference to a third object.

Admittedly, I haven't looked into this all that much.

By dmbarbour at Tue, 2010-02-09 18:24 | login or register to post comments

I'm not sure I understand

I'm not sure I understand your example, setX sounds like a setter, but the (first) type is not monadic. Objects in Timber have (mutable) state variables but the type of the setter has to be monadic since there are obviously side effects from the method.

If you are interested in the reactive objects there's a short paper describing the idea and there's also an older paper with a longer description on how to get rid of the Evil I.

By Peter A Jonsson at Mon, 2010-02-15 01:12 | login or register to post comments

OOHaskell

OOHaskell has it.
By Sean Leather at Tue, 2010-02-09 11:06 | login or register to post comments