Início / coding / Perguntas / 78285401
Accepted
Enlico
Asked: 2024-04-07 02:00:15 +0800 CST

Para manter o estado em uma função do tipo a -> ReaderT r IO b, minha única opção é colocar um IORef no encerramento? Ou posso de alguma forma usar o StateT?

  • 772

Digamos que eu tenha que implementar uma função

f :: Foo -> ReaderT Bar IO Baz

que tenho que passar para um consumidor (ou seja, vou chamar ) c fonde Foo// são impostos o consumidor da função, e que o consumidor chamará essa função repetidamente com s diferentes.BarBazFoo

Tenho alguma chance de manter algum estado local entre chamadas sucessivas para f?

De alguma forma, já consegui isso através de um IORef, alterando a assinatura def

f :: IORef S -> Foo -> ReaderT Client IO a

e aplicá-lo parcialmente a algum estado que eu inicializei de antemão:

s <- initState :: IO (IORef S)
c $ f s

Dessa forma, o totalmente aplicado fpode alterar o state na IOmônada via atomicModifyIORef'e alguma ufunção pdate:

f s x = do
  liftIO $ atomicModifyIORef' s u
  -- ...

No entanto, a solução acima foi natural para mim porque esse state é realmente um estado mutável global que é modificado não apenas por chamadas para f, mas também por alguma outra parte do programa que é executada simultaneamente com f.

Mas agora preciso de falgum estado privado que não deva ser modificado por mais ninguém. Isso me faz pensar no StateTtransformador, mas não sei se posso aplicá-lo neste caso.

O caso prático em questão é que desejo uma notifyfunção com estado no contexto da implementação de um servidor de notificação. Veja aqui um exemplo de brinquedo da implementação. Neste cenário, Foo -> ReaderT Bar IO Bazé na verdade MethodCall -> ReaderT Client IO Reply( ReaderT Client IO ais DBusR a).

Como você pode ver, o que quer que eu faça com notify, devo acabar passando uma MethodCall -> DBusR Replyfunção para export, cliente essa função será chamada várias vezes e espera-se que retorne sempre, então me parece que a única maneira de manter o estado nela é o seu fechamento, ou seja, tenho que fornecer notifymais um argumento antes MethodCalle aplicá-lo parcialmente ao estado inicial, como expliquei acima. E a única maneira de fazer com que esse estado mude toda vez que a MethodCallfor passado é fazer com que o primeiro argumento adicional seja um estado verdadeiramente mutável, por exemplo, o que IORefmencionei acima.

É isso?

haskell

1 respostas

  1. Best Answer

    Imagine que a assinatura de ffosse:

    f :: Foo -> Reader Bar Baz

    e você de alguma forma "usou StateT" fpara encadear um estado local por meio de uma sequência de chamadas para f. Isso significaria que duas chamadas consecutivas fcom o mesmo Fooargumento com o leitor resultante seriam executadas usando o mesmo Barargumento:

    let baz1 = runReader (f foo) bar
    baz2 = runReader (f foo) bar
in ...

    poderia resultar em dois resultados diferentes baz1, baz2dependendo da mudança no estado local, certo? Em outras palavras, seria uma violação da transparência referencial.

    Então, a única razão pela qual você pode realizar um estado f :: Foo -> ReaderT Bar IO Bazé porque você tem sua mônada base IOdisponível, então qualquer solução que você encontrar terá que usar IOefeitos para manter o estado.

    No entanto, é fácil de usar StateTdentro da definição de f, ao mesmo tempo em que mantém o estado como IORefalgo privado para f. Se você escrever sua flógica principal usando StateT:

    f :: Foo -> StateT S (ReaderT Client IO) a
f foo = do ...

    você pode construir uma espécie de ffábrica:

    f_factory :: IO (Foo -> ReaderT Client IO a)
f_factory = do
  sref <- newIORef initS
  pure $ \foo -> do
    s <- liftIO $ readIORef sref
    (r, s') <- runStateT (f foo) s
    liftIO $ writeIORef sref s'
    pure r

    e em IO, você pode escrever:

    f_with_state <- f_factory
c f_with_state    -- pass to consumer

    Observe que, como sreffoi criado em f_factory, ele é incluído no encerramento resultante, f_with_statemas não está disponível em nenhum outro lugar. E, na definição principal de f, você pode apenas usar get,,, etc., sem se preocupar com o fato de que a função real está restaurando e salvando puto estado no IORef privado.modifyf_with_statesref

    • 5

relate perguntas