[ACCEPTED]-Does Haskell support object oriented programming-haskell

How do you separate declaration and implementation in Haskell?

In Haskell you can define a typeclass, which is rather 33 different from an object oriented class 32 so don't let the name fool you. Using the 31 keyword class, you can declare function names 30 and type signatures which can be instantiated 29 (implemented) elsewhere for a particular 28 data type.

For example, the Hashable typeclass defines 27 the hash function, which can turn any instantiated 26 data type into an Int. Have a new, funky data 25 type you want to be able to hash? Fine, make 24 an instance of Hashable. The most common 23 data types are instantiated by the module 22 that defines Hashable (see the linked documentation 21 for 'Instances').

Typeclasses aren't the 20 only way to define an interface. A method 19 that is often under-rated is a plain old 18 data structure. Because Haskell has first 17 class functions, you can define a data structure 16 that has functions as fields:

data ShuttleInterface =
  SI { launch    :: Delay -> IO Handle
     , deploy    :: Payload -> IO ()
     , getStatus :: IO Status
     }

And your functions 15 can build or consume this data structure:

deployAllSensors :: ShuttleInterface -> IO ()
deployAllSensors shuttle = do
    status <- getStatus shuttle
    let notDeployed = filter (not . deployed) (sensors status)
    when (isOrbiting status) (mapM_ deploySensor notDeployed)

-- we used the well-known Haskell functions: filter, not, , when, mapM_
-- and some supporting functions were assumed:
isOrbitting :: Status -> Bool
deploySensor :: Sensor -> IO ()
sensors :: Status -> [Sensor]
deployed :: Sensor -> Bool

How do you restrict access to data in Haskell?

To 14 provide abstraction, Haskell uses Algebraic Data Types. To 13 protect fields developers declare a data 12 type but don't export it's constructors 11 - instead they only export a set of safe 10 primitives that maintain desired invariants.

For 9 example, the Map module provides a balanced 8 tree. It couldn't guarantee balance if 7 anyone could just declare a Map using the 6 primitives of Branch and Leaf, so the makers didn't 5 export those. Construction of a map must 4 rely on what is exported from Data.Map (and 3 those have access to/use the constructors 2 by virtue of being in the same module) such 1 as fromList, empty, singleton, and a whole bunch of modifiers.

See Haskell's Overlooked Object System by Oleg Kiselyov and Ralf Laemmel for 6 a detailed explanation of how OO concepts 5 can be implemented in Haskell. But as Antal 4 said in the comments, don't try to write 3 a Java program in Haskell.

Remember that 2 objects are a poor man's closure, and closures 1 are a poor man's object.

Type classes are indeed the only constructs 24 that remind remotely on OO concepts - in 23 this case, on interfaces. Though, unlike 22 in java, type classes are not types.

One 21 good thing about type classes is that I 20 can make totally unrelated, already existing 19 types members of a type class. Whereas in 18 java, sometimes one thinks: These classes 17 A from package org.a and B from com.b that 16 I am using ought really be implementing 15 interface Y from a third package, but there 14 is no way to do it that would not require 13 a lot of boilerplate code, additional indirections, marshalling 12 etc.

BTW, as an elderly programmer I'd like 11 to note that "separation of declaration 10 and implementation" has per se nothing to 9 do with OOP. Just because most OO-langugaes 8 support it does not mean the concept was 7 not well known for a long time before OO 6 was invented. Interested youngsters who 5 think that programming before mainstreaming 4 of OO must have been on a "stone age" level 3 may look up MODULA, for example, where separation 2 of declaration and implementation is not 1 only possible, but enforced by the language.

One thing might be good to mention is lenses. They 5 allow you to write the kind of a.b.c.d.e "expression" in 4 a compose-able way.

The . can be defined 3 for each data structure. So in some sense 2 the . is a first class citizen in Haskell. It 1 can be named, stored, two .-s can be composed, etc.

I just discovered sth by accident, see https://github.com/complyue/ooh for 11 a runnable program with full machinery (full 10 code is still extremely short though).

I 9 never imagined OO stylish program can be written 8 in Haskel in such a way so straight forward!

Constructing 7 object:

!o <- classC $^ (777, "hahah")

Calling direct methods:

  cx0 <- o $. getNumC $ ()
  o $. setNumC $ 888

Calling base 6 methods:

  bx0 <- (o $.. cast'C'as'B) getNumB ()
  (o $.. cast'C'as'B) setNumB 999

Method arguments have to be uncurried as 5 prototyped here, I suppose it's the preferable 4 flavor when writing OO style code though.

While 3 the object class definition appears verbose 2 as hand-crafted for now, I believe Template Haskell has 1 much to offer for better syntax sugar.