Início / coding / Perguntas / 79011368
Accepted
An5Drama
Asked: 2024-09-22 18:07:08 +0800 CST

O modelo de ambiente é necessário para procedimentos de ordem superior?

  • 772

Ao aprender SICP, 6.001 lec15 tem:

Um bom entendimento do modelo de ambiente me diz por que (na minha humilde opinião) C++ nunca terá um mapa totalmente funcional , filtro e procedimentos fold-right/fold-left que sejam tão convenientes quanto os do Scheme

O SICP implementamap :

(define (map proc items)
  (if (null? items)
      nil
      (cons (proc (car items))
            (map proc (cdr items)))))

Aqui, cada chamada recursiva mapcriará um novo ambiente para cada lista de argumentos (proc items), para que eles possam ser independentes (semelhante a for proce consetc).

Mas na minha opinião, em C++ o código acima pode ser feito com as mesmas ideias baseadas em stack . Então a independência ainda é mantida.

Por que a aula diz "C++ nunca terá um mapa totalmente funcional " devido ao "modelo de ambiente"?

c++

1 respostas

  1. Best Answer

    Como outros disseram, esse link é muito antigo. As coisas mudaram muito desde então.

    A resposta curta, na minha opinião, é que o que mapvocê descreve já existe em C++ (C++20) e é chamado de std::ranges::views::transform, que pode ser usado assim

    auto w = v | transform(f);

    que "corresponde" a

    (define w (map f v))

    no Esquema.

    Eu citei corresponde porque não sei exatamente como as coisas acontecem em tempo de execução para o código Scheme acima. Eu sei que isso std::ranges::views::transformé preguiçoso, ou seja, nenhum trabalho é realmente executado (no sentido de fnão ser invocado de forma alguma) ao escrever a linha C++ acima. Somente ao acessar os valores de wvia API range, esses valores serão realmente computados, portanto fserão chamados.

    Mas eu sei que funciona, em termos de preguiça, como o código Haskell correspondente (que se assemelha muito ao código Scheme):

    let w = map f v

    Além disso, o conceito de "mapeamento" não é tão restrito quanto o implícito no trecho de código e na afirmação de que

    C++ nunca terá um mapa totalmente funcional

    porque essa map é uma implementação ad-hoc de mapfor lists. Então é tão "funcional" quanto um programa que lida explicitamente com listas o tempo todo sem nunca definir abstrações de alto nível.

    ... O que é bom no Scheme porque tudo é uma lista, verdade, mas você ainda teria que redefinir map_assocmappara executar uma função nos valores de um "mapa associativo" (que ainda seria uma lista, no final das contas, no Scheme, por exemplo (define myassocmap '((k1 v1) (k2 v2) (k3 v3))), mas map_assocmapnão seria map, porque (map_assocmap f myassocmap)teria que chamar fapenas em v1, v2, v3.)

    Mas a questão é que o conceito de mapping é mais geral e diz respeito aos Functores , como são conhecidos na e .

    E C++ oferece algo nessa direção. Por exemplo, você pode mapear um opcional, em C++: dado a std::optional<T>e uma função do tipo U(T), faz sentido executar essa função no valor dentro do opcional, se houver um, obtendo assim um opcional não vazio do tipo std::optional<U>, ou retornar um vazio std::optional<U>( std::nullopt) se o opcional original estiver vazio. Isso, em C++, é a função membro std::optional<T>::transform.

    Isto corresponderia ao seguinte, no Esquema

    (define (mapOpt f opt)
  (if (nullOpt? opt)
      'nullOpt
      (f (makeOpt (unwrapOpt opt)))))

    assumindo que alguém tenha definido a API nullOpt?+ 'nullOpt+ makeOpt+ unwrapOpt.

    • 1

relate perguntas