H98, OOHaskell - getting started with objects in Haskell

[gutti]

CONTENTS DELETED

The author has deleted this message.

[Erik de Castro Lopo-34]

gutti wrote:

> I wanted to check whether Haskell offers reasonably easy object oriented
> programming -- I already had a look into "Haskell's overlooked object
> system" und "A Gentle Introduction to Haskell 98" [H98]

Its probably a bad idea to try and write Java style OO code in
Haskell. Trying to do this with be playing against Haskell's
strengths (type safe functional programming) and you will
likely find a whole bunch of weakness that regular Haskell
programmers never bump into.

> 2. is OOHaskell the right way to go - is it standardised (H98) or is it
> extension and is it widely used and recommended  ?

It is not widely used, the topic of OOHaskell rarely comes
up in this mailing list or on the #haskell IRC channel.

Since its not widely used, I would also think its not really
recommended.

> 3. Haskell 98 offers datatypes and some sort of monadic classes -- is it
> possible to build simple objects without OOHaskell ?  

Haskell is not an OO langauge. Trying to write Java style OO
code in Haskell will be painful.

> 4. When I want object properties to change, when should I use IORef when
> STRef ?

Thats a really, really bad idea. Haskell is designed to be a pure
functional language where mutable data is only used in limited
circumstances when there is no other way.

HTH,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Sean Leather]

Phil:

I wanted to check whether Haskell offers reasonably easy object oriented
programming

It depends on what you're looking for, but in general, you won't find the same thing you may be used to in native OO languages.

1. OOHaskell doesn't seem to be available in the HackageDB (cabal) -- so how
do I install it especially on Debian ?

The paper and source are available via links on the website: http://homepages.cwi.nl/~ralf/OOHaskell/ . It appears that you could use darcs with the new repository: http://code.haskell.org/OOHaskell/ .

2. is OOHaskell the right way to go - is it standardised (H98) or is it
extension and is it widely used and recommended  ?

It uses several language extensions beyond H98. AFAIK, it is not widely used. It was an interesting demonstration of the potential of the Haskell type system. I worked with it once, and it's nice research, but it hasn't yet been shown to be useful in practice.

3. Haskell 98 offers datatypes and some sort of monadic classes -- is it
possible to build simple objects without OOHaskell ?

4. When I want object properties to change, when should I use IORef when
STRef ?

Once you become comfortable with Haskell, you will most likely find other ways to do things than the OO way. If you ask questions on this list about something you want to do, I'm sure you will get answers on how to do it the functional way.

Sean

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Erik de Castro Lopo-34]

gutti wrote:

> I wanted to check whether Haskell offers reasonably easy object oriented
> programming

If you really insist on doing OO programming in a functional
language you may want to look at Scala and Ocaml, both of
which have proper OO additions.

I haven't used Scala myself but have done quite a bit of coding
in Ocaml. My adivce for anyone coming from an imperative OO
language to Ocaml is to avoid the OO stuff to start with and
learn to write good, clean, pure functional code before starting
to use references and OO.

The only time I ever used objects in Ocaml was when I was writing
code that used Ocaml's GTK+ GUI widget set bindings. These bindings
expose classes/objects to the programmer so the programmer has to
use OO.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[snk_kid]

gutti <philipp.guttenberg <at> gmx.net> writes:
>
>
> Hi,
>
> I wanted to check whether Haskell offers reasonably easy object oriented
> programming -- I already had a look into "Haskell's overlooked object
> system" und "A Gentle Introduction to Haskell 98" [H98]
>

I think you're better off starting by describing your problem, reason why do you
actually need to use OO for.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[gutti]

CONTENTS DELETED

The author has deleted this message.

[Wolfgang Jeltsch-2]

Am Donnerstag, den 13.01.2011, 15:23 -0800 schrieb gutti:
> I'm especially interestes in engineering calculation tasks where cellular
> automata could be used. In that case all u have to do is to give the class
> the right properties and that "let it grow".
>
> Such a localised intelligence approach seems an ideal OO - task. I don't
> know whether something functional could achieve the same.

Is this really ideal for OO? I thought that in a cellular automaton, all
cells have to change synchronously. In addition, cells have to access
the old states of their neighbours to compute their new states. So you
would have to heavily synchronize the objects.

In this light, I’d say that the distributed OO approach isn’t very
practical. A global control of the whole system might be better.

Note that I’m by no way an expert in cellular automata. I’m just
thinking of the game of life. :-)

Best wishes,
Wolfgang


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Albert Y. C. Lai]

On 11-01-13 06:23 PM, gutti wrote:
> I'm especially interestes in engineering calculation tasks where cellular
> automata could be used. In that case all u have to do is to give the class
> the right properties and that "let it grow".
>
> Such a localised intelligence approach

seems to be exactly existential type and/or message passing.

It looks OO because people's first exposure to existential type and
message passing is through OO. But OO also bundles a lot of things not
needed for this, for example I doubt that inheritance is needed. You
could use OO but you don't need OO.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Doralicio]

Hi Philipp,

depending on what engineering calculations you are interested in, you
might like http://timber-lang.org/ , a direct descendant of O'Haskell,
targeted at embedded real-time systems.

If you are just stepping out of the OO programming world, it might be
helpful to imagine OO as a rather narrow specialization of a concept
called type, so that from the FP perspective it is just one of so many
alternatives so that it gets lost a little -- which may be a useful
translation to use.

So the short answer to "where's OO?" in Haskell might just be "data",
while the expressive freedom of type classes / families might surprise
you. There have been some people playing with cellular automata, Google
helps, e.g.:

http://mjsottile.wordpress.com/
http://trac.haskell.org/gloss/

Both cases might give you an impression how it's done with Haskell types.

If you really are interested in using the OO class concept together with
the Haskell type system by a more than practical motivation, an expert
in the field who is interested in the subject for a long time is Peter
Padawitz (http://fldit-www.cs.uni-dortmund.de/~peter/ 
<http://fldit-www.cs.uni-dortmund.de/%7Epeter/>); he has presented a
beautiful synthesis based on category theory, swinging types
(http://fldit-www.cs.uni-dortmund.de/~peter/Swinging.html 
<http://fldit-www.cs.uni-dortmund.de/%7Epeter/Swinging.html>). Of
course, he did also use O'Haskell for his programming works in the past.

Cheers,

     Nick

On 01/14/2011 12:23 AM, gutti wrote:

> Hi,
>
> thanks for all Your answers (and again I'm amazed how active and good this
> forum is).
>
> I expected OOHaskell to be on the somewhat "extended" side, but I didn't
> expect it to be so uncommon.
> This very strong and clear feedback is indeed very valuable.
>
> I think I see the complexities of OO-programming in larger programs
> (unforeseen interactions), but I'm still doubtfull, that functional
> programming can equally adress all tasks equally efficient.
>
> I'm especially interestes in engineering calculation tasks where cellular
> automata could be used. In that case all u have to do is to give the class
> the right properties and that "let it grow".
>
> Such a localised intelligence approach seems an ideal OO - task. I don't
> know whether something functional could achieve the same.
>
> Sounds like a nice challenge. -- I'll chew on a small example.
>
> Cheers Phil

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Alberto G. Corona]

Hi!

2011/1/14 gutti <[hidden email]>

I'm especially interestes in engineering calculation tasks where cellular
automata could be used. In that case all u have to do is to give the class
the right properties and that "let it grow".

Such a localised intelligence approach seems an ideal OO - task. I don't
know whether something functional could achieve the same.

Thanks to your question, I took another look and the old and wonderful OOHaskell paper. It is very well written and describes almost exhaustively the haskell alternatives and their shortcomings:

http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf

Honestly, with the information I can have, my view is that the ·"let it grow" issue in the full is only achievable by following the OOHaskell path, but you can use the other ways paying a little price.

This past discussion also applies:

http://www.haskell.org/pipermail/haskell-cafe/2006-January/013925.html

 

Sounds like a nice challenge. -- I'll chew on a small example.

Cheers Phil
--
View this message in context: http://haskell.1045720.n5.nabble.com/H98-OOHaskell-getting-started-with-objects-in-Haskell-tp3338991p3340604.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[gutti]

CONTENTS DELETED

The author has deleted this message.

[gutti]

CONTENTS DELETED

The author has deleted this message.

[caseyh]

If you want to use an OO approach: try thinking of a sparse array of  
objects (previous and current generations) where each object "knows"  
its coordinates by being linked into a sparse array data structure.


Quoting gutti <[hidden email]>:

>
> On Fri, 14 Jan 2011 12:36:22 -0800 (PST)
> "Wolfgang Jeltsch-2 [via Haskell]"
> <[hidden email]> wrote:
>
>> Is this really ideal for OO? I thought that in a cellular automaton,
>> all cells have to change synchronously. In addition, cells have to
>> access the old states of their neighbours to compute their new
>> states. So you would have to heavily synchronize the objects.
>>
>> In this light, I?d say that the distributed OO approach isn?t very
>> practical. A global control of the whole system might be better.
>>
>> Note that I?m by no way an expert in cellular automata. I?m just
>> thinking of the game of life. :-)
>>
>> Best wishes,
>> Wolfgang
>
> Hi Wolfgang,
>
> I don't yet have experience with cellular automata either. What u say
> seems plausible, but then the life game might have been coded that way,
> because most OO language don't offer concurrent objects and the
> distributed OO approach (seems to be a very recent concept).
>
> Looking at life u probably could save time, if u only would evaluate
> code on cells, where the neighbors have changed status. So rather than
> triggering them all centrally and each checks its neighbours, we could
> use the concept:
>
> - let the active ones trigger the neighbours & so pass on activity
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Wolfgang Jeltsch-2]

Am Sonntag, den 16.01.2011, 14:48 -0800 schrieb gutti:
> Looking at life u probably could save time, if u only would evaluate
> code on cells, where the neighbors have changed status. So rather than
> triggering them all centrally and each checks its neighbours, we could
> use the concept:
>
> - let the active ones trigger the neighbours & so pass on activity

But then you would have to take care to avoid cycles. You could also use
on-demand updates with a centralized approach, and a centralized
approach would probably make cycle detection easier.

Best wishes,
Wolfgang


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Luke Palmer-2]

On Mon, Jan 17, 2011 at 1:44 AM, Wolfgang Jeltsch
<[hidden email]> wrote:

> Am Sonntag, den 16.01.2011, 14:48 -0800 schrieb gutti:
>> Looking at life u probably could save time, if u only would evaluate
>> code on cells, where the neighbors have changed status. So rather than
>> triggering them all centrally and each checks its neighbours, we could
>> use the concept:
>>
>> - let the active ones trigger the neighbours & so pass on activity
>
> But then you would have to take care to avoid cycles. You could also use
> on-demand updates with a centralized approach, and a centralized
> approach would probably make cycle detection easier.

Don't forget about the double buffering you will need to do if you
have a simultaneous rule.  It doesn't take long before the dragons in
imperative programming start messing with your "easy" specification.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[gutti]

CONTENTS DELETED

The author has deleted this message.