Як ви називаєте функцію, коли той самий вхід завжди повертатиме один і той же вихід, але також має побічні ефекти?

Скажімо, у нас є нормальна чиста функція, така як

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

А потім ми його змінюємо таким чином, щоб він мав побічну дію

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

Наскільки я знаю, це не є чистою функцією, оскільки я часто чую, як люди називають чисті функції "функціями без побічних ефектів". Однак він поводиться як чиста функція, що стосується того, що він поверне той самий вихід на ті самі входи.

Чи є інша назва цього типу функцій, вона без назви, чи вона все-таки є чистою, і я помиляюсь щодо визначення чистоти?

Я не впевнений у універсальних визначеннях чистоти, але з точки зору Haskell (мови, де програмісти прагнуть дбати про такі речі, як чистота та референтна прозорість), лише перша з ваших функцій є "чистою". Друга версія addне є чистою . Отже, відповідаючи на ваше запитання, я б назвав це "нечистим";)

Згідно з цим визначенням, чиста функція - це функція, яка:

1. Тільки залежить від його вкладу. Тобто, враховуючи той самий вхід, він завжди буде повертати той самий вихід.
2. Є референційно прозорим: функцію можна вільно замінити своїм значенням і "поведінка" програми не зміниться.

З цим визначенням зрозуміло, що вашу другу функцію не можна вважати чистою, оскільки вона порушує правило 2. Тобто наступні дві програми НЕ еквівалентні:

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

і

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

Це тому, що, хоча обидві функції повернуть однакове значення, функція fзапише в базу даних двічі, але gзапише один раз! Цілком ймовірно, що запис у базу даних є частиною спостережуваної поведінки вашої програми, і тоді я показав, що ваша друга версія addне є "чистою".

Якщо записи в базу даних не є спостережуваною частиною поведінки вашої програми, то обидві версії addможна вважати рівнозначними та чистими. Але я не можу придумати сценарій, коли запис у базу даних не має значення. Навіть ведення журналу має значення!

Як ви називаєте функцію [для якої] той самий вхід завжди поверне той самий вихід, але також має побічні ефекти?

Така функція називається

детермінований

Алгоритм, поведінку якого можна повністю передбачити із вхідних даних.

termwiki.com

Щодо штату:

Залежно від того, чиє визначення функції ви використовуєте, функція не має стану. Якщо ви прийшли з об'єктно-орієнтованого світу, пам’ятайте, що x.f(y)це метод. Як функція це виглядало б f(x,y). І якщо ви замикаєтесь із закритим лексичним діапазоном, пам’ятайте, що незмінний стан також може бути частиною вираження функцій. Тільки стан, що змінюється, може впливати на функції детермінованого характеру. Тож f (x) = x + 1 є детермінованим до тих пір, поки 1 не зміниться. Не має значення, де зберігається 1.

Ваші функції обидві детерміновані. Ваше перше - це також чиста функція. Ваша друга не є чистою.

Чиста функція

1. Функція завжди оцінює одне і те саме значення результату, задаючи однакові значення аргументів. Значення результату функції не може залежати від будь-якої прихованої інформації або стану, яка може змінюватися під час виконання програми або між різними виконанням програми, а також не може залежати від зовнішнього вводу пристроїв вводу / виводу.

2. Оцінка результату не спричиняє жодних семантично помітних побічних ефектів або результатів, таких як мутація змінних об'єктів або вихід на пристрої вводу / виводу.

wikipedia.org

Точка 1 означає детерміновану . Пункт 2 означає референтну прозорість . Вони разом означають, що чиста функція дозволяє лише змінювати її аргументи та повернене значення. Ніщо більше не спричиняє змін. Нічого іншого не змінюється.

Якщо вам не байдужий побічний ефект, то він референтно прозорий. Звичайно, можливо, що вам не байдуже, але це робить хтось інший, тому застосовність терміна залежить від контексту.

Я не знаю загального терміна для саме описаних вами властивостей, але важливим підмножиною є ті, які є ідентичними . У інформатиці, дещо інакше, ніж у математиці *, ідентична функція - це та, яку можна повторити з тим же ефектом; це означає, що чистий побічний результат від цього багато разів такий самий, як і один раз.

Отже, якщо вашим побічним ефектом було оновити базу даних з певним значенням у певному рядку або створити файл із точно узгодженим вмістом, то це було б ідентично , але якщо його додати до бази даних або додати до файлу , то не буде.

Комбінації ідентифікованих функцій можуть або не можуть бути ідентичними в цілому.

* Використання idempotent в комп’ютерній науці відрізняється від математики, ніж, мабуть, пов'язане з неправильним використанням математичного терміна, який тоді був прийнятий, оскільки концепція корисна.

Я не знаю, як називаються такі функції (чи є навіть якесь систематичне ім'я), але я б назвав функцію, яка не є чистою (як інші відповіді ослаблені), але завжди повертає той самий результат, якщо постачається з тими ж параметрами "функція його параметри "(порівняно з функцією його параметрів та деяким іншим станом). Я б назвав це просто функцією, але, на жаль, коли ми говоримо "функція" в контексті програмування, ми маємо на увазі щось, що зовсім не повинно бути фактичною функцією.

Це в основному залежить від того, дбаєте ви про домішки чи ні. Якщо семантика цієї таблиці полягає в тому, що вам байдуже, скільки записів у них є, то це чисто. Інше, це не чисто.

Або кажучи інакше, це добре, доки оптимізації, засновані на чистоті, не порушують програмну семантику.

Більш реалістичним прикладом може бути, якби ви намагалися налагодити цю функцію та додали оператори журналу. Технічно лісозаготівля - це побічний ефект. Чи роблять це колоди нечистими? Немає.

Я б сказав, що найкраще запитати - це не те, як ми б це називали, а як би ми проаналізували такий фрагмент коду. І моє перше ключове питання в такому аналізі:

• Чи побічний ефект залежить від аргументу функції чи результату від побічного ефекту?
  • Ні: "Ефективна функція" може бути перетворена на чисту функцію, ефективну дію та механізм їх поєднання.
  • Так: "Ефективна функція" - це функція, яка дає монодічний результат.

Це просто проілюструвати в Haskell (і це речення - лише половина жарту). Приклад випадку "ні" може бути таким:

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

У цьому прикладі дія, яку ми вживаємо (друкуємо рядок "I'm doubling some number"), не впливає на взаємозв'язок між xрезультатом і результатом. Це означає, що ми можемо змінити його таким чином (використовуючи Applicativeклас та його *>оператор), що показує, що функція та ефект насправді є ортогональними:

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"

Тож я в цьому випадку особисто сказав, що це випадок, коли можна виділити чисту функцію. Про це багато програм Haskell - навчитися виділяти чисті частини від ефективного коду.

Приклад сортування "так", коли чисті та ефективні частини не є ортогональними:

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

Тепер, рядок, який ви друкуєте, залежить від значення x. Функція частина (помножити xна два), однак, не залежить від впливу на всіх, так що ми можемо по- , як і раніше враховувати це:

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)

Я можу продовжити написання інших прикладів, але сподіваюся, що цього достатньо, щоб проілюструвати точку, з якої я почав: ви не «називаєте» це чимось, ви аналізуєте, як чисті та ефективні частини співвідносяться та визначають їх, коли це на вашу користь.

Це одна з причин, що Haskell Monadтак широко використовує свій клас. Монади є (серед іншого) інструментом для проведення такого роду аналізу та рефакторингу.

Функції, які покликані викликати побічні ефекти, часто називають ефективними . Приклад https://slpopejoy.github.io/posts/Effectful01.html