Comment appelez-vous une fonction où la même entrée renvoie toujours la même sortie, mais a également des effets secondaires?

Disons que nous avons une fonction pure normale telle que

function add(a, b) {
  return a + b
}

Et puis nous le modifions pour qu'il ait un effet secondaire

function add(a, b) {
  writeToDatabase(Math.random())
  return a + b;
}

Autant que je sache, ce n’est pas considéré comme une fonction pure, car j’entends souvent les gens appeler des fonctions pures "des fonctions sans effets secondaires". Cependant, il se comporte comme une fonction pure dans la mesure où il renvoie la même sortie pour les mêmes entrées.

Existe-t-il un nom différent pour ce type de fonction, est-il anonyme, ou est-il toujours pur et je me trompe au sujet de la définition de la pureté?

Je ne suis pas sûr des définitions universelles de la pureté, mais du point de vue de Haskell (un langage dans lequel les programmeurs ont tendance à se préoccuper de choses telles que la pureté et la transparence référentielle), seule la première de vos fonctions est "pure". La deuxième version de addn'est pas pure . Donc, en réponse à votre question, je l'appellerais "impur";)

Selon cette définition, une fonction pure est une fonction qui:

1. Ne dépend que de son entrée. C'est-à-dire que, avec la même entrée, il retournera toujours la même sortie.
2. Est référentiellement transparent: la fonction peut être remplacée librement par sa valeur et le "comportement" du programme ne changera pas.

Avec cette définition, il est clair que votre deuxième fonction ne peut pas être considérée comme pure, car elle enfreint la règle 2. Autrement dit, les deux programmes suivants ne sont PAS équivalents:

function f(a, b) { 
    return add(a, b) + add(a, b);
}

et

function g(a, b) {
    c = add(a, b);
    return c + c;
}

En effet, même si les deux fonctions renverront la même valeur, la fonction fécrira deux fois dans la base de données, mais gune fois! Il est très probable que les écritures dans la base de données fassent partie du comportement observable de votre programme. Dans ce cas, j'ai montré que votre deuxième version de addn'est pas "pure".

Si les écritures dans la base de données ne font pas partie du comportement de votre programme, les deux versions de addpeuvent être considérées comme équivalentes et pures. Mais je ne peux pas penser à un scénario où écrire dans la base de données importe peu. Même l'exploitation forestière compte!

Comment appelez-vous une fonction [pour laquelle] la même entrée retournera toujours la même sortie, mais aura également des effets secondaires?

Une telle fonction s'appelle

déterministe

Un algorithme dont le comportement peut être complètement prédit à partir de l'entrée.

termwiki.com

En ce qui concerne l'état:

Selon la définition de la fonction que vous utilisez, une fonction n'a pas d'état. Si vous venez du monde orienté objet, rappelez-vous que x.f(y)c'est une méthode. En fonction, cela ressemblerait f(x,y). Et si vous êtes dans des fermetures avec une portée lexicale incluse, rappelez-vous que cet état immuable pourrait aussi bien faire partie de l'expression des fonctions. Ce n'est que l'état mutable qui aurait un impact sur la nature déterministe des fonctions. Donc, f (x) = x + 1 est déterministe tant que le 1 ne change pas. Peu importe où le 1 est stocké.

Vos fonctions sont déterministes. Votre première est également une fonction pure. Votre seconde n'est pas pure.

Fonction pure

1. La fonction évalue toujours la même valeur de résultat avec les mêmes valeurs d'argument. La valeur du résultat de la fonction ne peut dépendre d'aucune information cachée ni d'aucun état susceptible de changer pendant l'exécution du programme ou entre différentes exécutions du programme, pas plus que de toute entrée externe provenant de périphériques d'E / S.

2. L'évaluation du résultat ne provoque pas d'effet secondaire ou de sortie observable sémantiquement, tel que la mutation d'objets mutables ou la sortie sur des périphériques d'E / S.

wikipedia.org

Le point 1 signifie déterministe . Le point 2 signifie transparence référentielle . Ensemble, ils signifient qu'une fonction pure ne permet que ses arguments et sa valeur renvoyée à changer. Rien d'autre ne provoque le changement. Rien d'autre n'est changé.

Si vous ne vous souciez pas de l'effet secondaire, il est transparent par référentiel. Bien sûr, il est possible que vous ne vous en souciiez pas, mais que quelqu'un d'autre le fasse. L'applicabilité du terme dépend donc du contexte.

Je ne connais pas de terme général pour désigner précisément les propriétés que vous décrivez, mais un sous-ensemble important est celui qui est idempotent . En informatique, un peu différemment en mathématiques *, une fonction idempotente est une fonction qui peut être répétée avec le même effet; c’est-à-dire que l’effet net de le faire plusieurs fois est le même que de le faire une fois.

Donc, si votre effet secondaire était de mettre à jour une base de données avec une certaine valeur dans une certaine ligne, ou de créer un fichier avec un contenu parfaitement cohérent, alors ce serait idempotent , mais s'il était ajouté à la base de données ou ajouté à un fichier alors ce ne serait pas.

Les combinaisons de fonctions idempotentes peuvent être ou non idempotentes dans leur ensemble.

* En informatique, l'utilisation d' idempotent différemment des mathématiques semble provenir d'une utilisation incorrecte du terme mathématique qui a ensuite été adopté parce que le concept est utile.

Je ne sais pas comment on appelle de telles fonctions (ni même s'il y a même un nom systématique), mais j'appellerais une fonction qui n'est pas pure (comme les autres réponses sont étouffées) mais qui retourne toujours le même résultat si elle est fournie avec les mêmes paramètres " paramètres "(comparé à la fonction de ses paramètres et à un autre état). J'appellerais cela juste une fonction, mais malheureusement, lorsque nous parlons de "fonction" dans le contexte de la programmation, nous entendons quelque chose qui ne doit pas nécessairement être une fonction réelle.

Cela dépend fondamentalement de si vous vous souciez de l'impureté ou non. Si la sémantique de cette table est que vous ne vous souciez pas du nombre d'entrées, alors c'est pur. Sinon, ce n'est pas pur.

Autrement dit, tant que les optimisations basées sur la pureté n'enfreignent pas la sémantique du programme, c'est bien.

Un exemple plus réaliste serait si vous essayiez de déboguer cette fonction et d’ajouter des instructions de journalisation. Techniquement, la journalisation est un effet secondaire. Les bûches le rendent-il impur? Non.

Je dirais que la meilleure chose à demander n'est pas comment nous l'appellerions, mais comment nous analyserions un tel code. Et ma première question clé dans une telle analyse serait:

• L'effet secondaire dépend-il de l'argument de la fonction ou du résultat de l'effet secondaire?
  • Non: la "fonction efficace" peut être reformulée en une fonction pure, une action efficace et un mécanisme permettant de les combiner.
  • Oui: la "fonction efficace" est une fonction qui produit un résultat monadique.

Ceci est simple à illustrer dans Haskell (et cette phrase n’est qu’une demi-plaisanterie). Un exemple du cas "non" serait quelque chose comme ceci:

double :: Num a => a -> IO a
double x = do
  putStrLn "I'm doubling some number"
  return (x*2)

Dans cet exemple, l'action que nous effectuons (imprimer la ligne "I'm doubling some number") n'a aucun impact sur la relation entre xet le résultat. Cela signifie que nous pouvons le refactoriser de cette manière (en utilisant la Applicativeclasse et son *>opérateur), ce qui montre que la fonction et l'effet sont en fait orthogonaux:

double :: Num a => a -> IO a
double x = action *> pure (function x)
  where
    -- The pure function 
    function x = x*2  
    -- The side effect
    action = putStrLn "I'm doubling some number"

Donc, dans ce cas, je dirais personnellement que c'est un cas où vous pouvez factoriser une fonction pure. Cela concerne beaucoup de programmes Haskell - apprendre à décomposer les parties pures du code efficace.

Un exemple du type "oui", où les parties pures et effectives ne sont pas orthogonales:

double :: Num a => a -> IO a
double x = do
  putStrLn ("I'm doubling the number " ++ show x)
  return (x*2)

Maintenant, la chaîne que vous imprimez dépend de la valeur de x. La partie fonction (multiplier xpar deux), cependant, ne dépend pas du tout de l'effet, nous pouvons donc la factoriser:

logged :: (a -> b) -> (a -> IO x) -> IO b
logged function logger a = do
  logger a
  return (function a)

double x = logged function logger
  where function = (*2) 
        logger x putStrLn ("I'm doubling the number " ++ show x)

Je pourrais continuer à donner d’autres exemples, mais j’espère que c’est suffisant pour illustrer le point que j’avais commencé: vous n’appelez pas quelque chose, vous analysez la relation entre les parties pure et efficace et les factorisez quand c’est le cas. à votre avantage.

C'est l'une des raisons pour lesquelles Haskell utilise Monadtellement sa classe. Les monades sont (entre autres) un outil pour effectuer ce type d’analyse et de refactorisation.

Les fonctions destinées à provoquer des effets secondaires sont souvent qualifiées d' effet . Exemple https://slpopejoy.github.io/posts/Effectful01.html