modulos - palindromo en haskell

¿Se puede implementar el patrón de pastel de Scala en Haskell?

Question

Mediante el uso de una serie de funciones de lenguaje más nuevas en Scala, es posible implementar un sistema de componentes compositivos y crear componentes utilizando el llamado Patrón de Torta, descrito por Martin Odersky en el resumen de componentes escalables de papel y también en una reciente charla .

Varias de las funciones de Scala utilizadas en el Patrón de la torta tienen características correspondientes de Haskell. Por ejemplo, las implicaciones de Scala corresponden a clases de tipo Haskell y los miembros de tipo abstracto de Scala parecen corresponder a los tipos asociados de Haskell. Esto me hace preguntarme si el Patrón de Torta podría implementarse en Haskell y cómo se vería.

¿Se puede implementar el patrón de torta en Haskell? ¿A qué características de Haskell corresponden las características de Scala en dicha implementación? Si no se puede implementar Cake Pattern en Haskell, ¿qué características de idioma faltan para que esto sea posible?

Answer 1

Hay varias soluciones. El "obvio" es tener varias instancias para determinadas clases de tipos (por ejemplo, Loader , Player , GUI para un juego) que pueden combinarse libremente, pero en mi opinión, tal diseño es más adecuado para los idiomas OO.

Si piensa fuera de la caja y reconoce que los bloques de construcción fundamentales en Haskell son funciones (¡D''oh!), Llegará a algo como esto:

data Game = Game
  { load    :: String -> IO [Level]
  , player1 :: Level -> IO Level
  , player2 :: Level -> IO Level
  , display :: Level -> IO ()  
  }  

play :: Game -> IO ()

Con este diseño es muy fácil de reemplazar, por ejemplo, los jugadores humanos por robots. Si esto se vuelve demasiado complejo, usar la mónada Reader podría ser útil.

Answer 2

Oleg proporcionó una respuesta muy detallada aquí: http://okmij.org/ftp/Haskell/ScalaCake.hs

Answer 3

Tomando this como ejemplo, me parece que el siguiente código es bastante similar:

{-# LANGUAGE ExistentialQuantification #-}

module Tweeter.Client where

import Data.Time
import Text.Printf
import Control.Applicative
import Control.Monad

type User = String

type Message = String

newtype Profile = Profile User

instance Show Profile where
  show (Profile user) = ''@'' : user

data Tweet = Tweet Profile Message ZonedTime

instance Show Tweet where
  show (Tweet profile message time) =
    printf "(%s) %s: %s" (show time) (show profile) message

class Tweeter t where
  tweet :: t -> Message -> IO ()

class UI t where
  showOnUI :: t -> Tweet -> IO ()
  sendWithUI :: Tweeter t => t -> Message -> IO ()
  sendWithUI = tweet

data UIComponent = forall t. UI t => UIComponent t

class Cache t where
  saveToCache :: t -> Tweet -> IO ()
  localHistory :: t -> IO [Tweet]

data CacheComponent = forall t. Cache t => CacheComponent t

class Service t where
  sendToRemote :: t -> Tweet -> IO Bool
  remoteHistory :: t -> IO [Tweet]

data ServiceComponent = forall t. Service t => ServiceComponent t

data Client = Client UIComponent CacheComponent ServiceComponent Profile

client :: (UI t, Cache t, Service t) => t -> User -> Client
client self user = Client
  (UIComponent self)
  (CacheComponent self)
  (ServiceComponent self)
  (Profile user)

instance Tweeter Client where
  tweet (Client (UIComponent ui)
                (CacheComponent cache)
                (ServiceComponent service)
                profile)
        message = do
    twt <- Tweet profile message <$> getZonedTime
    ok <- sendToRemote service twt
    when ok $ do
      saveToCache cache twt
      showOnUI ui twt

Y para la implementación dummy:

module Tweeter.Client.Console where

import Data.IORef
import Control.Applicative

import Tweeter.Client

data Console = Console (IORef [Tweet]) Client

console :: User -> IO Console
console user = self <$> newIORef [] where
  -- Tying the knot here, i.e. DI of `Console'' into `Client'' logic is here.
  self ref = Console ref $ client (self ref) user

instance UI Console where
  showOnUI _ = print

-- Boilerplate instance:
instance Tweeter Console where
  tweet (Console _ supertype) = tweet supertype

instance Cache Console where
  saveToCache (Console tweets _) twt = modifyIORef tweets (twt:)
  localHistory (Console tweets _) = readIORef tweets

instance Service Console where
  sendToRemote _ _ = putStrLn "Sending tweet to Twitter HQ" >> return True
  remoteHistory _ = return []

test :: IO ()
test = do
  x <- console "me"
  mapM_ (sendWithUI x) ["first", "second", "third"]
  putStrLn "Chat history:"
  mapM_ print =<< localHistory x

-- > test
-- Sending tweet to Twitter HQ
-- (2012-10-21 15:24:13.428287 UTC) @me: first
-- Sending tweet to Twitter HQ
-- (2012-10-21 15:24:13.428981 UTC) @me: second
-- Sending tweet to Twitter HQ
-- (2012-10-21 15:24:13.429596 UTC) @me: third
-- Chat history:
-- (2012-10-21 15:24:13.429596 UTC) @me: third
-- (2012-10-21 15:24:13.428981 UTC) @me: second
-- (2012-10-21 15:24:13.428287 UTC) @me: first

Sin embargo, este es el caso más simple. En Scala tienes:

• Clases con valor abstracto y miembros de tipo (recuerda a los funtores de ML y los registros dependientes, como en Agda).

• Tipos dependientes del camino.

• Linealización automática de clases.

• esto y super

• Autotipos.

• Subtitulado.

• Implícitos

• ...

Es solo, bueno, diferente de lo que tienes en Haskell.