Enlico's questions

Aqui está um módulo:

module Foo where

foo ws = let ws' = take 3 $ ws ++ repeat mempty
             x = ws' !! 0
             y = ws' !! 1
             z = ws' !! 2
         in [x, y, z]

e aqui vai mais um

module Foo where

foo ws = let (x:y:z:_) = take 3 $ ws ++ repeat mempty
         in [x, y, z]

Via ghc -O2 -c foo.hs, eles compilam para 8072 e 5288 bytes, respectivamente. Não tenho certeza de qual é o melhor, nem como testá-los, mas acho que eles não podem se comportar de forma idêntica, em termos de desempenho, simplesmente porque são diferentes.

As duas funções se comportam de forma diferente? Se não, a diferença no binário gerado é devido a uma otimização perdida? Ou o quê?

Tenho muitas IOações baseadas em , sendo uma das mais simples a seguinte:

-- Loop.hs
module Loop where
import System.Console.ANSI (setCursorPosition)
type Pos = (Int, Int)
setCursorPosition' :: Pos -> IO ()
setCursorPosition' = uncurry setCursorPosition

Nesse ponto, partindo do exposto acima, decidi escrever essas funções em termos de uma restrição de tipo implementada por IO, em vez de codificar IO, como sugerido por esta resposta .

Então o que eu fiz consistiu em

• definindo um FakeIOtipo classe sua implementação trivial para IO:

  -- Interfaces.hs
  module Interfaces where
  import qualified System.Console.ANSI as ANSI (setCursorPosition)
  
  class FakeIO m where
    setCursorPosition :: Int -> Int -> m ()
  
  instance FakeIO IO where
    setCursorPosition = ANSI.setCursorPosition
  

• alterado setCursorPosition'para usar esta interface:

  -- Loop.hs
  module Loop where
  import Interfaces
  type Pos = (Int, Int)
  setCursorPosition' :: FakeIO m => Pos -> m ()
  setCursorPosition' = uncurry setCursorPosition
  

Isso fez com que o programa continuasse funcionando bem (via cabal run), atestando que a "refatoração" estava correta.

Mas quando tentei alavancar essa refatoração para fins de teste, fiquei preso. O que fiz foi escrever o seguinte teste:

-- test/Main.hs
module Main where

import Control.Monad (unless)
import System.Exit (exitFailure)
import MTLPrelude (State, execState, modify')
import Test.QuickCheck

import Loop
import Interfaces

data MockTerminal = MockTerminal {
  pos :: (Int, Int)
} deriving Eq

instance FakeIO (State MockTerminal) where
  setCursorPosition y x = modify' $ \m -> MockTerminal { pos = (y, x) }

main :: IO ()
main = do
  result <- quickCheckResult tCenter
  unless (isSuccess result) exitFailure

tCenter :: Bool
tCenter = (setCursorPosition' (1,1))
          `execState` MockTerminal { pos = (0,0)}
          == MockTerminal { pos = (1,1) }

que falha ao compilar (via cabal test) porque

error: [GHC-39999]
    • No instance for ‘snakegame-0.1.0.0:Loop:Interfaces.FakeIO
                         (StateT MockTerminal Identity)’
        arising from a use of ‘setCursorPosition'’
    • In the first argument of ‘execState’, namely
        ‘(setCursorPosition' (1, 1))’
      In the first argument of ‘(==)’, namely
        ‘(setCursorPosition' (1, 1))
           `execState` MockTerminal {pos = (0, 0)}’
      In the expression:
        (setCursorPosition' (1, 1)) `execState` MockTerminal {pos = (0, 0)}
          == MockTerminal {pos = (1, 1)}
   |
41 | tCenter = (setCursorPosition' (1,1))
   |            ^^^^^^^^^^^^^^^^^^

o que eu não entendo, porque instance FakeIO (State MockTerminal)deveria ser exatamente a snakegame-0.1.0.0:Loop:Interfaces.FakeIO (StateT MockTerminal Identity)instância que o compilador está alegando que não existe.

Além disso, se eu alterar o teste para usar setCursorPosition 1 1em vez de setCursorPosition' (1,1), ele compila e passa, revelando que o instanceestá realmente fazendo seu trabalho.

Então deve haver algo errado com a forma como isso instancese integra à definição de setCursorPosition'.

Reduzi o exemplo para os 4 arquivos a seguir:

$ tree !(dist-newstyle)
cabal.project  [error opening dir]
LICENSE  [error opening dir]
Session.vim  [error opening dir]
snakegame.cabal  [error opening dir]
src
├── Interfaces.hs
├── Loop.hs
└── Main.hs
test
└── Main.hs

2 directories, 8 files

dos quais:

-- src/Main.hs
module Main where

import Loop

main :: IO ()
main = setCursorPosition' (1,1)

-- src/Loop.hs
module Loop (setCursorPosition') where

import Interfaces
type Pos = (Int, Int)

setCursorPosition' :: FakeIO m => Pos -> m ()
setCursorPosition' = uncurry setCursorPosition

-- test/Main.hs
module Main where

import Control.Monad (unless)
import System.Exit (exitFailure)
import MTLPrelude (State, execState, modify')
import Test.QuickCheck

import Loop
import Interfaces

data MockTerminal = MockTerminal {
  pos :: (Int, Int)
} deriving Eq

instance FakeIO (State MockTerminal) where
  setCursorPosition y x = modify' $ \m -> MockTerminal { pos = (y, x) }
  putChar _ = modify' id

main :: IO ()
main = do
  result <- quickCheckResult tCenter
  unless (isSuccess result) exitFailure

tCenter :: Bool
tCenter = (setCursorPosition' (1,1))
          `execState` MockTerminal { pos = (0,0)}
          == MockTerminal { pos = (1,1)}

cabal-version: 3.0
name: snakegame
version: 0.1.0.0

common common
    default-language: GHC2024
    build-depends: base >= 4.19.1.0
                 , ansi-terminal
                 , mtl-prelude

common warnings
    ghc-options: -Wall

executable snakegame
    import: warnings, common
    main-is: Main.hs
    other-modules: Loop
                 , Interfaces
    hs-source-dirs: src

library Loop
    import: warnings, common
    exposed-modules: Loop
    hs-source-dirs: src

library Interfaces
    import: warnings, common
    exposed-modules: Interfaces
    hs-source-dirs: src

test-suite Test
    import: warnings, common
    type: exitcode-stdio-1.0
    main-is: Main.hs
    build-depends: QuickCheck
                 , Interfaces
                 , Loop
    hs-source-dirs: test

packages: .

with-compiler: ghc-9.10.1

Reproduções:

cabal repl --build-depends=mtl-prelude,transformers

λ> import Data.Mayb
λ> import Control.Monad
λ> import Control.Monad.Trans.Identity
λ> import MTLPrelude
λ> :{
ghci| maybeQuit :: MonadPlus m => Maybe Char -> MaybeT m (Maybe Char)
ghci| maybeQuit key = do
ghci|   case key of
ghci|     Just 'q' -> mzero
ghci|     Just '\ESC' -> mzero
ghci|     _ -> return key
ghci| :}
λ> runIdentityT $ runMaybeT $ maybeQuit (Just 'c')
Just (Just 'c')
λ> runIdentityT $ runMaybeT $ maybeQuit (Just 'q')
Nothing

Até agora tudo bem.

Mas então:

λ> (runIdentityT $ runMaybeT $ maybeQuit (Just 'q')) == Nothing 
False
λ> isNothing (runIdentityT $ runMaybeT $ maybeQuit (Just 'q'))
False

O que?!

Eu vejo que a expressão é um pouco polimórfica,

λ> :t runIdentityT $ runMaybeT $ maybeQuit (Just 'q')
runIdentityT $ runMaybeT $ maybeQuit (Just 'q')
  :: MonadPlus f => f (Maybe (Maybe Char))

mas não tenho certeza de como isso pode implicar que algo impresso como Nothingpoderia ser diferente de (==) Nothing.

Para contextualizar, estou executando maybeQuitem uma pilha monádica (há MaybeTe outros transformadores nela) com um IOna parte inferior, e está funcionando como esperado, mas suas implementações, portanto o tipo, não requerem o poder de IO, então eu estava tentando testá-lo em uma mônada diferente de IO, e foi assim que cheguei a fazer essa pergunta.

Em retrospecto, começo a ver outra coisa que não entendo muito bem: vejo :t runMaybeT $ maybeQuit (Just 'q')is MonadPlus m => m (Maybe (Maybe Char)), que é o que espero, mas, ao aplicar runIdentityTa isso, obtenho o tipo MonadPlus f => f (Maybe (Maybe Char), que é a mesma coisa, então devo estar entendendo mal o significado/propósito de IdentityT, e não consigo deixar de pensar que essa é a razão pela qual não obtenho o que acho que deveria obter no exemplo original.

À luz do raciocínio acima, tentei forçar m === []a expressão runMaybeT $ maybeQuit (Just 'c')aplicando- heada a ela, e o resultado é mais o que eu esperava:

λ> isNothing (head $ runMaybeT $ maybeQuit (Just 'q'))
True
λ> isNothing (head $ runMaybeT $ maybeQuit (Just 'c'))
False

mas ainda não entendi o que há de errado em usar runIdentityT.

(Relacionado a uma pergunta anterior .)

Se eu puder imprimir um caractere no terminal via Prelude.putCharem uma posição que eu decidi via System.Console.ANSI.setCursorPosition, como posso obter o caractere nessa posição?

O caso de uso é que eu quero fazer algo assim

do
  setCursorPosition a b
  c <- getTheCharacterHere
  putChar $ if c == 'x' then 'y' else 'z'

onde getTheCharacterHereé a ação desejada para recuperar o caractere atualmente mostrado na posição definida via setCursorPosition.

Resumindo, estou perguntando se o código a seguir invoca o UB somente se /* body */de fato altera o valor de i, ou também se não altera, em virtude da chamada da const maybeChangefunção não membro em um constobjeto.

// header.hpp
struct Foo {
  int i;
  void maybeChange();
};

void work(Foo const& foo);

// foo.cpp
#include "header.hpp"
void Foo::maybeChange() {
  /* body */
}

// work.cpp
#include "header.hpp"
void work(Foo const& foo) {
  const_cast<Foo&>(foo).maybeChange();
}

// main.cpp
#include "header.hpp"
Foo const foo{6};

int main() {
  work(foo);
}

Vejo que o problema existe caso a modificação realmente ocorra, porque isso viola uma suposição legítima que o compilador pode fazer, ou seja, que o fooobjeto global não muda.

Mas, por outro lado, http://eel.is/c++draft/dcl.type.cv#4 não mostra nenhum exemplo de chamada de constfunção não membro em constobjeto para o qual constfoi const_casted away, mas isso não o modifica de fato, como no meu exemplo acima. Ele mostra exemplos triviais como

const int* ciq = new const int (3);     // initialized as required
int* iq = const_cast<int*>(ciq);        // cast required
*iq = 4;                                // undefined behavior: modifies a const object

onde a última linha realmente modifica o objeto *ciq.

O que (eu acho) eu preciso

Como posso definir uma característica de tipo que verifica se, para um tipo T, a função ::foo(T)é declarada?

O que estou achando difícil é ter ::foouma maneira amigável ao SFINAE. Por exemplo, se o compilador chegou ao ponto em que o seguinte é definido,

template<typename T>
void f(T t) { foo(t); }

está tudo bem se nada foofoi visto até agora.

Mas assim que mudo foopara ::foo, recebo um erro grave.

O caso de uso (caso você ache que não preciso do acima)

Tenho um ponto de personalização como este:

// this is in Foo.hpp
namespace foos {
inline constexpr struct Foo {
    template <typename T, std::enable_if_t<AdlFooable<std::decay_t<T>>::value, int> = 0>
    constexpr bool operator()(T const& x) const {
        return foo(x);
    }
} foo{};
}

que permite personalizar o comportamento de uma chamada foos::foodefinindo uma foosobrecarga ADL para o tipo desejado.

A definição da característica é simples:

// this is in Foo.hpp
template <typename T, typename = void>
struct AdlFooable : std::false_type {};

template <typename T>
struct AdlFooable<T, std::void_t<decltype(foo(std::declval<T const&>()))>>
    : std::true_type {};

Dado que, se alguém define

// this is in Bar.hpp
namespace bar {
    struct Bar {};
    bool foo(bar::Bar);
}

então uma chamada para

// other includes
#include "Foo.hpp"
#include "Bar.hpp"
bool b = foos::foo(bar::Bar{});

funciona como esperado, com foos::fooroteamento da chamada para bar::foo(bar::Bar), que é encontrado via ADL. E isso funciona bem independentemente da ordem dos dois #includes, o que é bom, porque eles podem ser incluídos em qualquer ordem, se // other includestransitivamente os incluir.

Até agora tudo bem.

O que eu realmente não gosto dessa abordagem é que alguém poderia definir erroneamente, em vez do segundo trecho acima, o seguinte,

// this is in Bar.hpp
namespace bar {
    struct Bar {};
}
bool foo(bar::Bar);

com fooescopo global.

Nesse caso, se o #include "Bar.hpp"vier antes de #include "Foo.hpp", o programa de código funcionará, porque o corpo de Foo::operator()será selecionado ::foo(bar::Bar)por pesquisa comum.

Mas assim que a ordem do #includes é invertida, o código quebra.

Sim, o bug está na definição foo(bar::Bar)do namespace global, mas acho que também é um bug que pode passar despercebido por puro acaso.

É por isso que eu gostaria de mudar o traço de tipo para expressar que "uma chamada não qualificada para foo(T)é encontrada, mas não por meio de uma pesquisa comum " ou, mais diretamente, " foo(std::declval<T>())deve compilar, mas não::foo(std::declval<T>()) deve compilar" .

Uma vez perguntei se std::ranges::views::enumerateusa o tipo errado ( long) para indexação no GCC, mas aparentemente não é o caso , porque

std::views::enumerateé especificado para ser usado range_difference_t<Base>como seu valor de índice.

No entanto, a partir do rascunho

O tipo size_té um tipo inteiro sem sinal definido pela implementação que é grande o suficiente para conter o tamanho em bytes de qualquer objeto ( [expr.sizeof] ).

Portanto, pode-se pensar em uma matriz tão longa que os elementos finais de algum índice em diante não se encaixam no tipo usado para enumerateindexação, embora ainda se encaixem std::size_tpor definição, desde que em uma determinada máquina, o seguinte seja válido

static_assert(std::numeric_limits<std::size_t>::max() > std::numeric_limits<long>::max());

Por exemplo, tal matriz seria esta:

std::vector<int> v(std::numeric_limits<std::size_t>::max());

para o qual eu gostaria de saber como kevolui o seguinte:

auto w = v | std::ranges::views::enumerate;
for (auto [k, _] : w) {
    std::cout << k << std::endl;
}

Infelizmente, std::vectornão parece permitir esse tamanho de forma alguma, lançando exceções, enquanto um std::arraycom esse mesmo tamanho nem é compilável (exemplo completo aqui ), mas presumo que nenhum comportamento seja obrigatório pelo padrão. Ou é?

Se eu compilar o seguinte com-O3

#include <vector>
int foo() {
    std::vector<int> const v{17,2,3};
    return v[0] + v[2];
}

a montagem que eu recebo é

foo():
        mov     eax, 20
        ret

( pelo menos com Clang ).

E eu entendo como isso funcionaria quando chamado por alguma outra TU.

Mas se eu compilar com -O0, obtenho isto :

_Z3foov:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $112, %rsp
        movl    $17, -84(%rbp)
        movl    $2, -80(%rbp)
        movl    $3, -76(%rbp)
        leaq    -84(%rbp), %rax
        movq    %rax, -72(%rbp)
        movq    $3, -64(%rbp)
        leaq    -85(%rbp), %rcx
        movq    %rcx, -32(%rbp)
        movq    -32(%rbp), %rax
        movq    %rax, -8(%rbp)
        movq    -72(%rbp), %rsi
        movq    -64(%rbp), %rdx
        leaq    -56(%rbp), %rdi
        callq   _ZNSt6vectorIiSaIiEEC2ESt16initializer_listIiERKS0_
        jmp     .LBB0_1
.LBB0_1:
        leaq    -85(%rbp), %rax
        movq    %rax, -24(%rbp)
        leaq    -56(%rbp), %rdi
        xorl    %eax, %eax
        movl    %eax, %esi
        callq   _ZNKSt6vectorIiSaIiEEixEm
        movl    (%rax), %eax
        movl    %eax, -108(%rbp)
        leaq    -56(%rbp), %rdi
        movl    $2, %esi
        callq   _ZNKSt6vectorIiSaIiEEixEm
        movq    %rax, %rcx
        movl    -108(%rbp), %eax
        addl    (%rcx), %eax
        movl    %eax, -104(%rbp)
        leaq    -56(%rbp), %rdi
        callq   _ZNSt6vectorIiSaIiEED2Ev
        movl    -104(%rbp), %eax
        addq    $112, %rsp
        popq    %rbp
        retq
        movq    %rax, %rcx
        movl    %edx, %eax
        movq    %rcx, -96(%rbp)
        movl    %eax, -100(%rbp)
        leaq    -85(%rbp), %rax
        movq    %rax, -16(%rbp)
        movq    -96(%rbp), %rdi
        callq   _Unwind_Resume@PLT

__clang_call_terminate:
        pushq   %rbp
        movq    %rsp, %rbp
        callq   __cxa_begin_catch@PLT
        callq   _ZSt9terminatev@PLT

.L.str:
        .asciz  "cannot create std::vector larger than max_size()"

.L.str.1:
        .asciz  "/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_vector.h"

.L__PRETTY_FUNCTION__._ZNKSt6vectorIiSaIiEEixEm:
        .asciz  "const_reference std::vector<int>::operator[](size_type) const [_Tp = int, _Alloc = std::allocator<int>]"

.L.str.2:
        .asciz  "__n < this->size()"

DW.ref.__gxx_personality_v0:
        .quad   __gxx_personality_v0

onde _ZNKSt6vectorIiSaIiEEixEmé chamado quando computando v[0]e v[2]. Mas eu realmente não entendo onde esses 2 calls saltam. Quer dizer, a string _ZNKSt6vectorIiSaIiEEixEmaparece apenas 3 vezes, 2 são o calls, e um é este:

.L__PRETTY_FUNCTION__._ZNKSt6vectorIiSaIiEEixEm:
        .asciz  "const_reference std::vector<int>::operator[](size_type) const [_Tp = int, _Alloc = std::allocator<int>]"

Como isso pode resultar na retirada dos elementos do vetor?

Ou, em outras palavras, se eu vincular a TU acima com outra que a chama e retorna o valor, por exemplo

int foo();
int main() {
  return foo();
}

onde encontro o código o código que executa v[0]e v[2]? Se não está no assembly, nem está no binário, certo? Então como o programa roda?

A seguinte função não-template (ou seria?) retornando um lambda não genérico e com estado,

auto foo(double a) {
    return [a](double b) -> double {
        return a + b;
    };
}

compilado para isso com GCC ou Clang . Por quê?

foo(double):
        ret

Eu esperaria que não gerasse nenhuma saída .

A origem da questão

Nem me lembro por que comecei a escrever o trecho acima, mas enfim...

Inicialmente pensei que deveria ter sido compilado para algo um pouco maior, pois esperava ver addpelo menos uma instrução.

Mas então percebi que o fooacima não pode ser compilado sozinho, em um cpp, e então vinculado a outra TU onde é usado, porque não consigo nem escrever uma declaração - somente para ele!

Então chego ao ponto em que a única razão para escrever essa função em um arquivo sem cabeçalho é que ela é usada nesse arquivo sem cabeçalho, e nesse ponto o compilador pode presumivelmente incorporá-la onde quer que ela seja usada.

Mas se esse é o caso... então por que copilar foopara baixo para qualquer coisa , se é a única coisa na TU? Não há nada para vincular, então por que qualquer saída é gerada para isso?

Usar um struct+ operator()não muda nada, pois isso

struct Bar {
    double a;
    double operator()(double b) const {
        return a + b;
    }
};

Bar bar(double a) {
    return Bar{a};
}

gera o mesmo retcódigo -only, o que também é óbvio em retrospecto, pois não há como vincular essa barfunção a outras TUs, se Barestiver oculta no arquivo cpp.

Costumo me limitar às versões "recomendadas":

┌──────────────────────────────────GHCup──────────────────────────────────┐
│    Tool  Version         Tags                          Notes            │
│─────────────────────────────────────────────────────────────────────────│
│✔✔  GHCup 0.1.30.0   latest,recommended                                  │
│─────────────────────────────────────────────────────────────────────────│
│✗   Stack 2.15.7     latest                                              │
│✗   Stack 2.15.5     recommended                                         │
│✗   Stack 2.15.3                                                         │
│─────────────────────────────────────────────────────────────────────────│
│✗   HLS   2.9.0.1    latest                                              │
│✗   HLS   2.9.0.0                                                        │
│✗   HLS   2.8.0.0                                                        │
│✔✔  HLS   2.7.0.0    recommended                                         │
│✗   HLS   2.6.0.0                                                        │
│─────────────────────────────────────────────────────────────────────────│
│✗   cabal 3.12.1.0   latest                                              │
│✔✔  cabal 3.10.3.0   recommended                                         │
│✗   cabal 3.6.2.0-p1                                                     │
│─────────────────────────────────────────────────────────────────────────│
│✗   GHC   9.10.1     latest,base-4.20.0.0                                │
│✗   GHC   9.8.2      base-4.19.1.0                 hls-powered,2024-02-23│
│✗   GHC   9.6.6      base-4.18.2.1                                       │
│✗   GHC   9.6.5      base-4.18.2.1                                       │
│✔✔  GHC   9.4.8      recommended,base-4.17.2.1     hls-powered           │
│✗   GHC   9.2.8      base-4.16.4.0                 hls-powered           │
│✗   GHC   9.0.2      base-4.15.1.0                                       │
│✗   GHC   8.10.7     base-4.14.3.0                                       │
│✗   GHC   8.8.4      base-4.13.0.0                                       │
│✗   GHC   8.6.5      base-4.12.0.0                                       │
│✗   GHC   8.4.4      base-4.11.1.0                                       │
└─────────────────────────────────────────────────────────────────────────┘

No entanto, parece que estou tendo problemas para desenvolver o Hackage , e talvez seja porque o Hackage está usando um GHC mais recente do que aquele que o GHCup me diz ser a versão recomendada.

Então, qual é a relevância de “recomendado” e de onde ele vem?

Pegue isso

#include <range/v3/view/remove_if.hpp>
#include <range/v3/range/conversion.hpp>
#include <vector>

std::vector<int> foo(std::vector<int> v, bool(*p)(int)) {
    return v | ranges::views::remove_if(p) | ranges::to_vector;
}

em comparação com isso

#include <range/v3/action/remove_if.hpp>
#include <vector>

std::vector<int> bar(std::vector<int> v, bool(*p)(int)) {
    return std::move(v) | ranges::actions::remove_if(p);
}

Não há modelos disponíveis, apenas duas TUs fornecendo, cada uma, uma função pura com a mesma assinatura. Dada a sua implementação, esperaria que as duas funções realizassem a mesma tarefa, do ponto de vista do chamador. E é isso que eles parecem fazer.

No entanto, eles compilam em códigos bastante diferentes, a tal ponto que o GCC (tronco, pelo menos) produz código mais curto para o último, enquanto o Clang (tronco) produz código mais curto para o primeiro.

Não vejo nenhuma razão para as duas funções compilarem em códigos diferentes, a não ser "é muito difícil para o compilador criar o mesmo código para ambos" , mas o que está tornando isso tão difícil? Ou, se estiver errado, por que as duas funções devem ser compiladas em assembly diferente?

E, além do benchmarking, existe uma razão pela qual eu deveria preferir uma em vez de outra implementação?

Exemplo completo .

Aqui está o trecho de código

#include<memory>
#include<unordered_map>

struct
__declspec(dllexport)
Foo {
    std::unordered_map<const int*, std::unique_ptr<int>> foo;
};

Foo foo();

que falha assim :

C:/data/msvc/14.39.33321-Pre/include\list(1299): error C2679: binary '=': no operator found which takes a right-hand operand of type 'const std::pair<const int *const ,std::unique_ptr<int,std::default_delete<int>>>' (or there is no acceptable conversion)
C:/data/msvc/14.39.33321-Pre/include\utility(315): note: could be 'std::pair<_Kty,_Ty> &std::pair<_Kty,_Ty>::operator =(volatile const std::pair<_Kty,_Ty> &)'
        with
        [
            _Kty=const int *,
            _Ty=std::unique_ptr<int,std::default_delete<int>>
        ]
C:/data/msvc/14.39.33321-Pre/include\list(1299): note: 'std::pair<_Kty,_Ty> &std::pair<_Kty,_Ty>::operator =(volatile const std::pair<_Kty,_Ty> &)': cannot convert argument 2 from 'const std::pair<const int *const ,std::unique_ptr<int,std::default_delete<int>>>' to 'volatile const std::pair<_Kty,_Ty> &'
        with
        [
            _Kty=const int *,
            _Ty=std::unique_ptr<int,std::default_delete<int>>
        ]
C:/data/msvc/14.39.33321-Pre/include\list(1299): note: Reason: cannot convert from 'const std::pair<const int *const ,std::unique_ptr<int,std::default_delete<int>>>' to 'volatile const std::pair<_Kty,_Ty>'
        with
        [
            _Kty=const int *,
            _Ty=std::unique_ptr<int,std::default_delete<int>>
        ]

... see linked example for complete error

Vejo que o problema é o fato de std::unique_ptrnão ser copiável, como está implícito, por exemplo, em Reason: cannot convert from 'const std::pair<const int *const ,std::unique_ptr<int,std::default_delete<int>>>' to 'volatile const std::pair<_Kty,_Ty>', mas por que a capacidade de cópia é exigida apenas no Windows e somente com o dllexport?

Na base de código de onde isso foi extraído, __declspec(dllexport)está a expansão de uma macro que se expande para valores diferentes em outras plataformas, por exemplo, __attribute__ ((visibility("default")))no Linux, caso em que o código é compilado perfeitamente.

Eu tenho um programa como este,

start :: [Q] -> R -> IO R
start qs = fix $ \recurse r -> do
  q <- select qs
  (r', exit) <- askQ q r
  (if exit
    then return
    else recurse) r'

que pega uma lista de Qperguntas, uma Report, e retorna uma nova Report, na IOmônada porque selectprecisa escolher uma pergunta aleatoriamente (e também porque askQvai esperar pela entrada do teclado do usuário); no entanto, o usuário não escolheu exitdurante a execução askQ, startirá chamar a si mesmo recursivamente. ( fix $ \recurseé o truque para escrever um lambda recursivo. )

O código acima se parece muito com algumas coisas:

• a Statemônada , ou, mais apropriadamente, o StateTtransformador de mônada , porque Restá evoluindo durante starta recursão de;
• o forevercombinador de aplicativos, porque starté recursivo e pode potencialmente ser executado para sempre, se o usuário desejar (ou seja, se ele nunca pedir para sair);
• o MaybeTtransformador mônada , porque Maybeimplementa MonadPlusque deve poder entrar em curto-circuito forever, com base no que li antes foreverda implementação .

Mas não é possível dizer se alguma ou mais dessas abstrações podem ser usadas para escrever o código acima de uma forma mais idiomática, evitando o mais importante a recursão explícita.

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?

Pela documentação, estou inclinado a pensar que, se eu habilitar a DerivingStrategiesextensão, não preciso habilitar GeneralizedNewtypeDerivingor DeriveAnyClass, nem qualquer outra extensão listada atualmente antes de §6.6.7.1 , por exemplo DerivingVia.

No entanto, este exemplo de brinquedo

{-# LANGUAGE DerivingStrategies #-}

newtype MyNum = MyNum Int
 deriving stock (Eq, Ord, Show, Read)
 deriving newtype (Num, Enum, Real, Integral)

main :: IO ()
main = print $ MyNum 0

compila muito bem via ghc this-file.hs(GHC 9.4.8), mas não via cabal build(Cabal 3.10.2.1), porque neste último caso, também é necessário que eu adicione

{-# LANGUAGE GeneralizedNewtypeDeriving #-}

Alguma pista do porquê disso?

O foo.cabalarquivo fictício que estou usando é

cabal-version:   3.8
name:            foo
version:         1.0

executable foo
    main-is:          main.hs
    build-depends:    base

Brincando com o xmobar, quando vi isso

  , commands = [ Run $ Weather "EGPH" ["-t","<station>: <tempC>C",
                                        "-L","18","-H","25",
                                        "--normal","green",
                                        "--high","red",
                                        "--low","lightblue"] 36000
               , Run $ Network "eth0" ["-L","0","-H","32",
                                        "--normal","green","--high","red"] 10
               , Run $ Network "eth1" ["-L","0","-H","32",
                                        "--normal","green","--high","red"] 10
               , Run $ Cpu ["-L","3","-H","50",
                             "--normal","green","--high","red"] 10
               , Run $ Memory ["-t","Mem: <usedratio>%"] 10
               , Run $ Swap [] 10
               , Run $ Com "uname" ["-s","-r"] "" 36000
               , Run $ Date "%a %b %_d %Y %H:%M:%S" "date" 10
              , Run HelloWorld
              ]

Eu sem pensar muito falei "ah, posso tirar isso Run" e escrevi

  , commands = Run <$> [Weather {- ... -}
               , Network {- ... -}
               , Network {- ... -}
               , Cpu {- ... -}
               , Memory {- ... -}
               , Swap {- ... -}
               , Com {- ... -}
               , Date  {- ... -}
               , HelloWorld
               ]

mas isso obviamente não funciona, porque, por exemplo Data, HelloWorlde Weathersão tipos diferentes.

Mas alguns podem ir juntos dentro de uma lista, por exemplo, este tipo verifica

foo = [ Weather undefined undefined undefined
      , Cpu undefined undefined
      , DiskU undefined undefined undefined
      , Memory undefined undefined ]

mas isso não

foo = [ Weather undefined undefined undefined
      , Cpu undefined undefined
      , DiskU undefined undefined undefined
      , Date undefined undefined undefined -- because of this
      , Memory undefined undefined ]

Agora vejo que é um tipo Daterealdata , mas quais são os outros?

Se eu abrir, Weathernem vejo uma única palavra Weatheralém de um comentário e no nome do arquivomodule .

Então, o que é Weather? E onde vejo sua definição?

O fato de Weathere, digamos, Memorypoderem estar na mesma lista me faz pensar em tipos existenciais dos quais tenho pouca experiência. No entanto, nessa página wiki, vejo que isso

data Worker x y = forall b. Buffer b => Worker {buffer :: b, input :: x, output :: y}

é a maneira de definir a Workerque pode conter a bufferde qualquer tipo, desde que esse tipo implemente Buffer.

Agora, dado que o tipo do primeiro fooacima tem type [Monitors], acho que Monitorsestá desempenhando o papel de Worker, o tipo existencial, e Weather, Memorye outros são construtores de valor de tipos que implementam qualquer interface (correspondente a Buffer) que esteja restringindo o tipo que o tipo existencial Monitorspode quebrar. Mas Datenão implementa essa interface, então não pode combinar com as outras.

É assim?

Mas se for esse o caso... então onde estão as definições Weatherde ', Memory' e outros, juntamente com a implementação da interface?

conv.qual#1 :

Uma decomposição de qualificação de um tipo Té uma sequência de cvi e Pi tal que Té

“cv0 P0 cv1 P1 ⋯ cv_n-1 Pn-1 cvn U” para n  ≥ 0,

onde cada cvi é um conjunto de qualificadores cv ([basic.type.qualifier]), e cada Pi é um “ponteiro para” ([dcl.ptr]), […]

[Exemplo 1: O tipo denotado pelo type-id const int **tem três decomposições de qualificação, tomando U como “ int”, como “ponteiro para const int” e como “ponteiro para ponteiro para const int”. - exemplo final]

Não entendo como a descrição " “cv0 P0 cv1 P1 ⋯ cv_n-1 Pn-1 cvn U” para n  ≥ 0," é compatível com o exemplo.

Quero dizer, o exemplo é para T == const int**e diz-se que existe uma decomposição possível para U ser int. Como isso é possível? Como const int**( T) pode ser escrito como cv0 P0 cv1 P1 ⋯ cv_n-1 Pn-1 cvn int ?

Mas, de maneira mais geral, não entendo por que U está no final e não no início daquele cv0 P0 cv1 P1 ⋯ cv_n-1 Pn-1 cvn U_. Como pode algo que começa com, digamos, const * volatile * const*ser um tipo?