
Object-oriented Haskell surprisingly appealing - complyue
https://github.com/complyue/ooh
======
Floegipoky
Sussman and Steele were quite surprised too! From the original Scheme paper:

"This work developed out of an initial attempt to understand the actorness of
actors... we discovered that the 'actors' and the lambda expressions were
identical in implementation."

[https://dspace.mit.edu/bitstream/handle/1721.1/5794/AIM-349....](https://dspace.mit.edu/bitstream/handle/1721.1/5794/AIM-349.pdf?sequence=2&isAllowed=y)

------
ulucs
This is some nice heresy

------
golergka
Reminds me of: [https://aphyr.com/posts/342-typing-the-technical-
interview](https://aphyr.com/posts/342-typing-the-technical-interview)

------
pierremenard
Basically making an OO DSL inside Haskell. It's a cool idea, but there have to
be nicer looking ways to do it right?

------
hopia
The benefits of introducing OOP to Haskell are unclear to me. Maybe the author
can point out what the purpose of this is?

~~~
andolanra
I'm not necessarily going to go to bat for the specific encoding of OOP
Haskell in the linked post, but _in general_ , there are problems where
objects are a good fit. William Cook (in the paper _On Understanding Data
Abstraction, Revisited_ ) claims that the key feature of objects is that they
are defined in terms of an external interface whose internals are hidden: this
captures, for example, SmallTalk-style message sends and duck typing as well
as the information-hiding found in languages like C++ or Java. One way of
encoding this idea into Haskell is with records of functions: to give a tiny
example, a set type can be represented as

    
    
        data Set a = Set { contains :: a -> Bool }
    

which leaves the actual structure of the set undefined. This means you can use
a variety of methods 'under the surface' to compute set membership and the
external interface can be identical and compatible:

    
    
        emptySet = Set { contains = \_ -> False }
        singletonSet x = Set { contains = \y -> x == y }
        union l r = Set { contains = \y -> contains l y && contains r y }
        fromList lst = Set { contains = \y -> y `elem` lst }
    

And while this example is a bit trivial, this pattern is invaluable for
writing things that OOP can traditionally excel at, like writing GUIs or
certain kinds of video games where you want to bundle heterogeneous behavior
into a single package:

    
    
        data GameObject = GameObject
          { render :: Pos -> GraphicsContext -> IO ()
          , currentPosition :: Pos
          , setPosition :: Pos -> GameObject
          }
    

Of course, this is only one (significantly simpler!) encoding of OOP, and it
might not be one that you think captures the key ideas of objects, but to the
degree that it is it demonstrates that ideas which are common in OOP (like
information-hiding behind an interface) can still be useful in Haskell when
judiciously applied in the right context.

The paper I cited can be read here, which has more details:
[https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf](https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf)

------
BubRoss
Appealing to who? This is a 1 star github repo made six hours ago and a hacker
news link made 1 hour ago.

~~~
klysm
At least one person

~~~
SonOfThePlower
... and at most one person.

