O referencial Date.now é transparente?

DateTime.Now ouDate.now o referencial é transparente?

Esse é um dos tópicos controversos em um artigo de programação funcional noQiita.

Antes de tudo, devemos ter muito cuidado, pois a palavra "referencial transparente" é uma palavra / conceito complicado em um sentido, e existe uma discussão importante em

O que é transparência referencial?

O questionador declara:

O que significa o termo transparência referencial? Ouvi isso descrito como "significa que você pode substituir iguais por iguais", mas isso parece uma explicação inadequada.

Uma explicação muito típica, mas a idéia que normalmente nos leva a mal-entendidos é a seguinte: (resposta nº 2 da página acima por @Brian R. Bondy)

Transparência referencial, um termo comumente usado em programação funcional, significa que, dada uma função e um valor de entrada, você sempre receberá a mesma saída. Ou seja, não há estado externo usado na função.

As afirmações típicas que sempre ouvi e pensei errado são assim:

Em uma linguagem de programação,Date.now sempre retorna umvalor diferente que corresponde à hora atual e de acordo com

dada uma função e um valor de entrada, você sempre receberá a mesma saída.

Portanto,Date.now Não é referencial transparente!

Eu sei que alguns programadores (funcionais) acreditam firmemente que a reivindicação acima é confiável, no entanto, as respostas 1 e 3 de @Uday Reddy explicam da seguinte maneira:

Qualquer conversa sobre "transparência referencial" sem entender a distinção entre valores L, valores R e outros objetos complexos que preenchem o universo conceitual do programador imperativo é fundamentalmente equivocada.

A idéia de transparência referencial dos programadores funcionais parece diferir da noção padrão de três maneiras:

Enquanto os filósofos / lógicos usam termos como "referência", "denotação", "designatum" e "bedeutung" (termo alemão de Frege), programadores funcionais usam o termo "valor". (Isso não é inteiramente deles. Observo que Landin, Strachey e seus descendentes também usaram o termo "valor" para falar sobre referência / denotação. Pode ser apenas uma simplificação terminológica que Landin e Strachey introduziram, mas parece fazer uma grande diferença quando usado de maneira ingênua.)

Programadores funcionais parecem acreditar que esses "valores" existem dentro da linguagem de programação, não fora. Ao fazer isso, eles diferem dos filósofos e dos semanticistas da linguagem de programação.

Eles parecem acreditar que esses "valores" devem ser obtidos por avaliação.

Venha para pensar sobre isso, "estado externo" também é palavra / conceito complicado.

Transparência referencial, um termo comumente usado em programação funcional, significa que, dada uma função e um valor de entrada, você sempre receberá a mesma saída. Ou seja, não há estado externo usado na função.

"Hora atual" é "estado externo" ou "valor externo"?

Se chamamos "hora atual" é "estado externo", que tal "evento do mouse" ??

"evento do mouse" não é um estado que deve ser gerenciado pelo contexto de programação, é umevento externo.

dada uma função e um valor de entrada, você sempre receberá a mesma saída.

Então, podemos entender o seguinte:

"hora atual" não é "valor de entrada" nem "valor externo" nem "estado externo" eDate.now sempre retorna a mesma saída corresponde ao evento em andamento "hora atual".

Se alguém ainda insiste oudeseja chamar "hora atual" como um "valor", novamente,

Programadores funcionais parecem acreditar que esses "valores" existem dentro da linguagem de programação, não fora. Ao fazer isso, eles diferem dos filósofos e dos semanticistas da linguagem de programação.

O valor de "tempo atual" nunca existe na linguagem de programação, mas apenas fora, e o valor de "horário atual" fora, obviamente, é atualizado vianão contexto de programação, mas o fluxo de tempo do mundo real.

Portanto, eu entendo que Date.now é referencial transparente.

Eu gostaria de ler sua ideia. Obrigado.

EDIT1

NoO que é programação reativa (funcional)?

Conal Elliott @Conal também explica a programação reativa funcional (FRP).

Ele é o primeiro a desenvolver FRP e explica assim:

O FRP é sobre - "tipos de dados que representam um valor" ao longo do tempo ""

Valores dinâmicos / em evolução (ou seja, valores "ao longo do tempo") são valores de primeira classe em si mesmos.

Nesta perspectiva do FRP,

Date pode ser visto como um valor de primeira classe "ao longo do tempo" que é um objeto imutável no eixo do tempo.

.now é uma propriedade / função para abordar "a hora atual" dentro doDate

PortantoDate.time retorna um valor transparente imutável e referencial que representa nosso "tempo atual".

EDIT2

(em JavaScript)

função intransparente referencial

let a = 1;

let f = () => (a);

entrada deFunction:f não é nenhum; saída deFunction:f depende dea isso depende de um contexto externof

função transparente referencial

let t = Date.now();

let f = (Date) => (Date.now());

Apesar,Date valor reside em nosso mundo físico,Date pode ser visto como um valor imutável de primeira classe de FRP "ao longo do tempo".

Desde aDate referenciado de qualquer contexto de programação é idêntico, geralmente podemos omitir implicitamenteDate como valor de entrada e simplesmente como

let f = () => (Date.now());

EDIT3

Na verdade, enviei um email para Conal Elliott @Conal, que é um dos primeiros desenvolvedores do FRP. Ele gentilmente respondeu e me informou que há uma pergunta semelhante aqui.

Como pode existir uma função de tempo na programação funcional?

O questionador declara:

Então, minha pergunta é: pode uma função de tempo (que retorna o tempo atual) existir na programação funcional?

Se sim, então como pode existir? Não viola o princípio da programação funcional? Isso viola particularmente a transparência referencial, que é uma das propriedades da programação funcional (se bem entendi).

Ou, se não, como saber a hora atual da programação funcional?

e, a resposta de Conal Elliott @Conal no stackoverflow:

Sim, é possível que uma função pura retorne a hora, se ela tiver esse tempo como parâmetro. Argumento de tempo diferente, resultado de tempo diferente. Em seguida, forme também outras funções do tempo e combine-as com um vocabulário simples de funções de transformação de funções (de tempo), de ordem superior. Como a abordagem é apátrida, o tempo aqui pode ser contínuo (independente da resolução) e não discreto, aumentando bastante a modularidade. Essa intuição é a base da Programação Reativa Funcional (FRP).

Edit4 Agradeço a resposta de @Roman Sausarnes.

Permita-me apresentar minha perspectiva para programação funcional e FRP.

Antes de tudo, acho que a programação é fundamentalmente sobre matemática, e a programação funcional busca esse aspecto. Por outro lado, a programação imperativa é uma maneira de descrever etapas da operação da máquina, que não é necessariamente matemática.

Programação funcional pura como Haskel tem alguma dificuldade em lidar com "state" ou IO, e acho que todo o problema vem do "time".

"estado" ou "tempo" é praticamente uma entidade subjetiva para nós, humanos. Acreditamos naturalmente que o "tempo" está fluindo ou passando, e o "estado" está mudando, isto éRealismo ingênuo.

Eu acho que o realismo ingênuo para o "tempo" é um risco fundamental e uma razão para toda a confusão na comunidade de programação e muito poucos discutem esse aspecto. Na física moderna, ou mesmo na Newton Physics, tratamos o tempo de maneira matemática pura; portanto, se apresentarmos nosso mundo de maneira física, nada deve ser difícil de tratar nosso mundo com pura programação funcional matemática.

Então, eu tenho uma visão geral de que nosso mundo / universo é imutável como um DVD pré-gravado e apenas nossa visão subjetiva é mutável, incluindo "tempo" ou "estado".

Na programação, a única conexão entre o universo imutável e nossa experiência subjetiva mutável é "evento". Linguagem de programação funcional pura, como Haskell, basicamente não possui essa visão, embora alguns pesquisadores perspicazes, incluindo Cornel Elliott, façam FRP, mas a maioria ainda acha que o método FRP ainda é menor ou difícil de usar, e muitos deles tratam o estado mutável como uma questão natural.

Naturalmente, o FRP é a única solução inteligente e, especialmente, Cornel Elliott como fundador aplicou essa perspectiva filosófica e declarou:valor de primeira classe "ao longo do tempo". Talvez, infelizmente, muitos programadores não entendam o que ele realmente quis dizer, pois estão presos ao realismo ingênuo e acham difícil ver que o "tempo" é uma entidade filosoficamente ou fisicamente imutável.

Então, se eles discutem "puro funcional"ou"transparência referencial"para a vantagem da integridade / consistência matemática," Date.now "é naturalmente referencial transparente dentro de uma programação funcional pura, simplesmente porque" Date.time "acessa um certo ponto da linha do tempo imutável do universo imutável.

Então, o que dizertransparência referencial na semântica denotacional como @Reddy ou @Roman Sausarnes desilude?

Eu tenho uma visão geral da transparência referencial no FP, especialmente na comunidade Haskell, sobre integridade / consistência matemática.

Claro, talvez eu possa seguir a definição atualizada de "transparência referencial" da comunidade Haskell e, praticamente, julgamos que o código é matematicamente inconsistente se julgamos que não é transparente referencial, correto?

Na verdade, novamente,

Como pode existir uma função de tempo na programação funcional?

Um programador questionou o seguinte:

Então, minha pergunta é: pode uma função de tempo (que retorna o tempo atual) existir na programação funcional?

Se sim, então como pode existir? Não viola o princípio da programação funcional? Isso viola particularmente a transparência referencial, que é uma das propriedades da programação funcional (se bem entendi).

Ou, se não, como saber a hora atual da programação funcional?

Consenso

violar o princípio da programação funcional

= viola a transparência referencial, que é uma das propriedades da programação funcional

= Matematicamente inconsistente !!

Esta é a nossa percepção comum, correto?

Nesta pergunta, muitos responderam que "a função retornando o horário atual" não é transparente referencial, especialmente na definição de "transparência referencial" da comunidade Haskell, e muitos mencionaram que é sobre consistência matemática.

No entanto, apenas alguns responderam que "a função que retorna o horário atual" é referencial transparente e uma das respostas é da perspectiva do FRP de Conal Elliott @Conal.

IMO, FRP, uma perspectiva para lidar com um fluxo de tempo como um valor imutável de primeira classe "ao longo do tempo" é uma maneira correta com princípios matemáticos como a Física, como mencionei acima.

Então, como a função "Date.now" / "retornando a hora atual" se tornou referencial intransparente pelo contexto de Haskell?

Bem, a única explicação que consigo pensar é que a definição atualizada de "transparência referencial" da comunidade Haskell está um pouco errada.

Integridade / consistência matemática e orientada a eventos

Eu mencionei - Na programação, a única conexão entre o universo imutável e nossa experiência subjetiva mutável é "evento" ou "orientado a eventos".

A programação funcional é avaliada de maneira orientada a eventos, por outro lado, a programação imperativa é avaliada pelas etapas / rotina de operação da máquina descritas no código.

"Date.now" depende de "event" e, em princípio, "event" é desconhecido no contexto do código.

Então, o acionado por eventos destrói a integridade / consistência matemática? Absolutamente não.

Mapeando Sintaxe para Significado - indexical (dedo indicador)

C.S. Peirce introduziu o termo "indexical" para sugerir a ideia de apontar (como em "dedo indicador"). ⟦I⟧, [[aqui]], [[agora]] etc.

Provavelmente, este é o conceito matematicamente idêntico de coisas de "Mônada", "functor" em Haskell. Na semântica denotacional, mesmo em Haskell, [[agora]], como o 'dedo indicador' é claro.

O índice (dedo indicador) é subjetivo e, também, orientado a eventos

[[I]], [[aqui]], [[agora]], etc. é subjetivo e, novamente, na programação, a única conexão entre o universo objetivo imutável e nossa experiência subjetiva mutável é "evento" ou "Evento" -dirigido"

Portanto, enquanto [[agora]] estiver vinculado à declaração de eventos da Programação "orientada a eventos", a inconsistência matemática subjetiva (dependente do contexto) nunca ocorre, eu acho.

Edit5

@ Bergi me deu um excelente comentário:

Sim,Date.now, o valor externo, é referencialmente transparente. Sempre significa "hora atual".

MasDate.now() não é, é uma chamada de função retornando números diferentes, dependendo do estado externo. O problema com o "conceito de tempo atual" referencialmente transparente é que não podemos computar nada com ele.

@KenOKABE: Parece ser o mesmo caso queDate.now(). O problema é que isso não significa a hora atual ao mesmo tempo, mas em momentos diferentes - um programa leva tempo para ser executado, e é isso que o torna impuro.

Claro, poderíamos criar um referencial transparenteDate.now função / getter que sempre retorna a hora do início do programa (como se a execução do programa fosse imediata), mas não é assimDate.now()/Date.Now trabalhos. Eles dependem do estado de execução do programa. - Bergi

Eu acho que precisamos discutir isso.

Date.now, o valor externo, é referencialmente transparente.

[[Date.now]] é como mencionei em # Edit4, um indexical (indicador) subjetivo, mas enquanto permanecer no domínio indexical (sem uma execução / avaliação), é referencialmente transparente, que concordamos.

No entanto, @Bergi sugereDate.now() (com uma execução / avaliação) retorna "valores diferentes" em momentos diferentes e que não são mais referencialmente transparentes. Que não concordamos.

Eu acho que esse problema que ele mostrou com certeza, mas só existe na Programação Imperativa:

console.log(Date.now()); //some numeric for 2016/05/18 xx:xx:xx ....
console.log(Date.now()); //different numeric for 2016/05/18 xx:xx:xx ....

Nesse caso,Date.now() não é referencialmente transparente, eu concordo.

No entanto, no paradigma Programação Funcional / Programação Declarativa, nunca escreveríamos como o acima. Nós devemos escrever isto:

const f = () => (Date.now());

e istof é avaliado em algum contexto "orientado a eventos". É assim que um código de programação funcional se comporta.

Sim,esse código é idêntico ao

const f = Date.now;

Portanto, no paradigma Programação Funcional / Programação Declarativa,Date.now ouDate.now() (com uma execução / avaliação) nunca tem problemas para retornar "valores diferentes" em momentos diferentes.

Então, novamente, como eu mencionei emEDIT4, desde que [[agora]] esteja vinculado à declaração de eventos da Programação "orientada a eventos", a inconsistência matemática subjetiva (dependente do contexto) nunca ocorre, eu acho.

questionAnswers(1)

yourAnswerToTheQuestion