Existe uma definição canônica de função "pura"?


9

StackOverflow me apontou aqui, então a pergunta pode ser um pouco nos termos de um leigo.

A Wikipedia define funções puras como

Na programação de computadores, uma função pode ser descrita como uma função pura se ambas as instruções sobre a função se mantiverem:

  1. A função sempre avalia o mesmo valor de resultado, dados os mesmos valores de argumento. O valor do resultado da função não pode depender de nenhuma informação ou estado oculto que possa mudar à medida que a execução do programa prossegue ou entre diferentes execuções do programa, nem pode depender de qualquer entrada externa de dispositivos de E / S.
  2. A avaliação do resultado não causa nenhum efeito colateral ou saída semanticamente observável, como mutação de objetos mutáveis ​​ou saída para dispositivos de E / S.

No entanto, parece não citar nenhuma fonte - portanto, é difícil dizer se essa é uma definição aceita ou quem a definiu dessa maneira.

Quando observo o que os idiomas fazem quando incluem uma sintaxe / anotação para funções "puras", existem algumas abordagens diferentes:

  1. Em D, a única limitação é a não mutação do estado global. Funções "puras" podem alterar seus argumentos.
  2. No GCC, existem dois tipos de "puro": pure(sem efeitos colaterais, mas pode ler o estado global) e const(estritamente puro conforme a definição da Wikipedia).
  3. No C # , é definido como "não faz alterações visíveis no estado" (seja o que for).
  4. Haskell segue a definição da Wikipedia.

Então, minha pergunta é: existe uma definição canônica de função pura?
E se houver, qual é a sua fonte?


Perspectiva histórica relacionada , embora ninguém pareça dar respostas definidas ou de origem.
Guildenstern

1
Isso não vale a pena responder, mas aqui está a minha definição: se x = y (por sua definição), então fx = fy é verdadeiro ef não causa nenhuma mudança mensurável externamente no estado (ou seja, toda mudança de estado é interna a x, y, e f). Haskell tira vantagem disso. Ele implementa uma avaliação lenta, modificando os thunks e substituindo-os por funções que retornam o resultado imediatamente. Ou seja, se você avaliar (fx), ele pode realmente mudar fex sob o capô, mas você nunca pode dizer.
Jake

Respostas:


3

Como observado neste artigo Programação Funcional Imperativa (1993) de Peyton-Jones e Wadler (entre o grupo de pesquisadores que criou Haskell):

Focamos em soluções puramente funcionais, que descartam efeitos colaterais, por duas razões. Em primeiro lugar, a ausência de efeitos colaterais permite o uso irrestrito de raciocínio equacional e transformação de programas ...

o foco está na ausência de efeitos colaterais para permitir transformações de programa (ou seja, otimizações do compilador).

Quais são os efeitos colaterais? Este artigo, por sua vez, aponta para Integração da programação funcional e imperativa (1986) de Gifford e Lucassen, que menciona quatro tipos de classes de efeito : Pura, Função, Observador e Procedimento. Portanto, o termo "função pura" deriva deste artigo.

  • um PURE é referencialmente transparente: não causa efeitos colaterais, seu valor não é afetado por efeitos colaterais e retorna o mesmo valor cada vez que é avaliado.

Observe, no entanto, que Peyton-Jones e Wadler mencionaram deficiências nessa abordagem. É importante notar, dizem eles, a linguagem de programação Clean, que usa tipos lineares para introduzir efeitos colaterais de uma maneira segura (isto é, segura para o compilador). Basicamente, ele encadea o mundo como uma variável em todas as funções relacionadas à E / S, incluindo o principal ponto de entrada.

Com isso, é possível ter uma linguagem funcional pura interagindo com o mundo e tendo efeitos colaterais (E / S, sistema operacional, sistema de janelas, etc.), contradizendo parcialmente sua definição da Wikipedia. Pode-se dizer de fato que Haskell tem o Clean como um de seus influenciadores; embora se afaste de tipos lineares e use outra construção de nível de tipo (mônadas) para garantir linearidade, ou seja, uma referência única o tempo todo.


"Basicamente, encadea o mundo como uma variável ...". Você realmente quer dizer "tópicos". Existe uma conta informal disso na web?
babou 2/07/2014

Eu usei "threading" como uma metáfora. Isso significa que você deve passar a variável World de uma função para outra. E a digitação linear significa que essa variável World não é usada mais de uma vez. Isso implica, por exemplo, que para abrir um arquivo dentro de uma função que você gostaria (f_handle, world2) = fopen file_name, world(pseudocódigo) e uma próxima chamada precisará ser usada world2. Em essência, os programas são vistos como operando no universo como um todo. Coloque outra maneira, não há efeitos colaterais quando você está operando no Universo :-)
carlosayam

Enfiar o mundo, como você diz, parece ser a maneira padrão (se bem me lembro) de lidar com o meio ambiente na semântica denotacional. Portanto, o ponto principal deve ser a linearidade. Mas, então, a semântica denotacional (DS) deve ser puramente funcional, sem qualquer restrição de linearidade. Acho que o DS é uma abstração matemática e não tem escrúpulos em fazer malabarismos com muitos mundos. A computação é física, e a linearidade permite a evolução do mundo, mas apenas um mundo pode existir ao mesmo tempo (o que provavelmente sequencia a avaliação). Qual é a semântica de 2 programas limpos executados simultaneamente :-)?
babou

O documento de Gifford e Lucassen está acessível na web?
babou

Eu tenho acesso através da Uni.
Carlosayam

-1

A definição da Wikipedia é canônica. Os dois requisitos cruciais são:

  • O valor de retorno e o comportamento da função são uma função determinística dos argumentos que foram explicitamente passados ​​para a função.

  • Uma invocação da função não tem efeitos colaterais observáveis.

A rigor, D e gcc não devem usar a palavra "puro" da maneira que usam; é um abuso da terminologia padrão.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.