Saf Fonksiyonlar: "Yan Etki Yok" "Her Zaman Aynı Çıktı, Aynı Girdi Verildi" anlamına mı geliyor?

Bir işlevi tanımlayan iki koşul pureaşağıdaki gibidir:

1. Yan etki yok (yani yalnızca yerel kapsamda değişikliklere izin verilir)
2. Aynı girdi verildiğinde her zaman aynı çıktıyı döndür

İlk koşul her zaman doğruysa, ikinci koşulun doğru olmadığı zamanlar var mı?

Yani gerçekten sadece ilk şart için gerekli mi?

Dış kapsamı değiştirmeyen ancak yine de saf olmadığı kabul edilen birkaç karşı örnek:

• function a() { return Date.now(); }
• function b() { return window.globalMutableVar; }
• function c() { return document.getElementById("myInput").value; }
• function d() { return Math.random(); } (kuşkusuz PRNG'yi değiştirir, ancak gözlemlenebilir olarak kabul edilmez)

Sabit olmayan yerel olmayan değişkenlere erişim, ikinci koşulu ihlal edebilmek için yeterlidir.

Her zaman saflığın iki koşulunu tamamlayıcı olarak düşünüyorum:

• sonuç değerlendirmesinin yan durum üzerinde etkisi olmamalıdır
• değerlendirme sonucu yan durumdan etkilenmemelidir

Terimi, bir yan etki sadece ilk belirtir, yerel olmayan durumunu değiştirmekten fonksiyonu. Bununla birlikte, bazen okuma işlemleri de yan etkiler olarak kabul edilir: birincil amaçları bir değere erişmek olsa bile , işlem olduklarında ve yazmayı da içerdiklerinde. Bunun örnekleri, jeneratörün dahili durumunu değiştiren sözde rasgele bir sayı üretmek, okuma konumunu ilerleten bir giriş akışından okumak veya bir "ölçüm al" komutunu içeren harici bir sensörden okumaktır.

Saf bir fonksiyonun ne olduğunu ifade etmenin "normal" yolu , referans şeffaflığı ile ilgilidir . Referans olarak şeffafsa bir işlev saftır .

Referans Şeffaflığı , kabaca, programın anlamını değiştirmeden programın herhangi bir noktasında fonksiyon çağrısını dönüş değeriyle değiştirebileceğiniz anlamına gelir.

Dolayısıyla, örneğin, eğer printfC'ler referans olarak şeffafsa, bu iki programın aynı anlama sahip olması gerekir:

printf("Hello");

ve

5;

ve aşağıdaki programların tümü aynı anlama sahip olmalıdır:

5 + 5;

printf("Hello") + 5;

printf("Hello") + printf("Hello");

Çünkü printfyazılan karakter sayısını döndürür, bu durumda 5.

voidİşlevlerle daha da belirginleşir . Bir işlevim varsa void foo, o zaman

foo(bar, baz, quux);

ile aynı olmalı

;

Yani foohiçbir şey döndürmediği için, programın anlamını değiştirmeden onu hiçbir şeyle değiştirebilmeliyim.

Öyleyse açıktır ki, ne referans olarak şeffaf ne printfde fooşeffaftır ve dolayısıyla ikisi de saf değildir. Aslında bir voidişlev, işlemsiz olmadığı sürece, hiçbir zaman referans olarak şeffaf olamaz.

Bu tanımı verdiğiniz tanım olarak daha kolay ele alıyorum. Ayrıca, istediğiniz herhangi bir ayrıntı düzeyinde uygulamanıza olanak tanır: bunu tek tek ifadelere, işlevlere ve tüm programlara uygulayabilirsiniz. Örneğin, böyle bir işlev hakkında konuşmanıza olanak tanır:

func fib(n):
    return memo[n] if memo.has_key?(n)
    return 1 if n <= 1
    return memo[n] = fib(n-1) + fib(n-2)

Fonksiyonu oluşturan ifadeleri analiz edebilir ve değiştirilebilir bir veri yapısı, yani memodizi kullandıkları için, referans olarak şeffaf olmadıkları ve dolayısıyla saf olmadıkları sonucuna kolayca varabiliriz . Ancak, biz de işlevi bakabilirsiniz ve bu görebilirsiniz olduğu referentially şeffaf ve böylece saf. Bu bazen dış saflık olarak adlandırılır , yani dış dünyaya saf görünen ancak dahili olarak saf olmayan bir işlevdir.

Bu tür işlevler hala kullanışlıdır, çünkü kirlilik etrafındaki her şeye bulaşsa da, dış saf arayüz bir tür "saflık engeli" oluşturur, burada kirlilik işlevin yalnızca üç satırını etkiler, ancak programın geri kalanına sızmaz. . Bu üç satırın doğruluğu tüm programdan çok daha kolaydır.

Bana öyle geliyor ki, tarif ettiğiniz ikinci durum, birincisinden daha zayıf bir kısıtlama.

Size bir örnek vereyim, ayrıca konsola da günlüğü tutan bir fonksiyona sahip olduğunuzu varsayalım:

function addOneAndLog(x) {
  console.log(x);
  return x + 1;
}

Sağladığınız ikinci koşul karşılanmıştır: bu işlev, aynı girdi verildiğinde her zaman aynı çıktıyı döndürür. Ancak, konsolda oturum açmanın yan etkisini içerdiği için saf bir işlev değildir.

Saf işlev, tam anlamıyla, referans şeffaflık özelliğini karşılayan bir işlevdir . Bu, bir işlev uygulamasını, programın davranışını değiştirmeden ürettiği değerle değiştirebileceğimiz özelliktir.

Basitçe ekleyen bir fonksiyonumuz olduğunu varsayalım:

function addOne(x) {
  return x + 1;
}

Biz yerini alabilir addOne(5)ile 6programımız ve değişecek hiçbir şey her yerde.

Bunun aksine, davranışı değiştirmeden programımızın herhangi bir yerindeki addOneAndLog(x)değerle 6değiştiremeyiz çünkü ilk ifade konsola bir şeyin yazılmasıyla sonuçlanırken ikincisi olmaz.

addOneAndLog(x)Çıktı döndürmenin yanı sıra performans gösteren bu ekstra davranışlardan herhangi birini bir yan etki olarak görüyoruz .

Sistemin dışından bir rastgelelik kaynağı olabilir. Hesaplamanızın bölümünün oda sıcaklığını içerdiğini varsayalım. Daha sonra fonksiyonun yürütülmesi, oda sıcaklığının rastgele dış elemanına bağlı olarak her seferinde farklı sonuçlar verecektir. Program çalıştırılarak durum değiştirilmez.

Zaten tek düşünebildiğim.

FP tanımlarıyla ilgili sorun, çok yapay olmalarıdır. Her değerlendirme / hesaplamanın değerlendirici üzerinde yan etkileri vardır. Teorik olarak doğrudur. Bunun reddi, yalnızca FP savunucularının felsefeyi ve mantığı görmezden geldiğini gösterir: "değerlendirme", bazı akıllı ortamların (makine, beyin vb.) Durumunun değiştirilmesi anlamına gelir. Bu, değerlendirme sürecinin doğasıdır. Değişiklik yok - "kalkül" yok. Etki çok görünür olabilir: CPU'nun ısıtılması veya arızalanması, aşırı ısınma durumunda anakartın kapatılması vb.

Referans şeffaflık hakkında konuştuğunuzda, bu tür bir şeffaflık hakkındaki bilgilerin tüm sistemin yaratıcısı ve anlamsal bilginin sahibi olarak insanlar için mevcut olduğunu ve derleyici için mevcut olmayabileceğini anlamalısınız. Örneğin, bir işlev bazı harici kaynakları okuyabilir ve imzasında IO monad bulunur, ancak her zaman aynı değeri döndürür (örneğin, sonucu current_year > 0). Derleyici, işlevin her zaman aynı sonucu döndüreceğini bilmez, bu nedenle işlev saf değildir, ancak referans olarak şeffaf özelliğe sahiptir ve Truesabit ile değiştirilebilir .

Dolayısıyla, bu tür bir yanlışlıktan kaçınmak için, programlama dillerindeki matematiksel fonksiyonları ve "fonksiyonları" birbirinden ayırmalıyız. Haskell'deki işlevler her zaman saf değildir ve bunlarla ilgili saflık tanımı her zaman çok koşulludur: gerçek yan etkileri ve fiziksel özellikleri olan gerçek donanım üzerinde çalışıyorlar, bu matematiksel işlevler için yanlış. Bu, "printf" işlevine sahip örneğin tamamen yanlış olduğu anlamına gelir.

Ancak tüm matematiksel fonksiyonlar da saf değildir: tbir parametre olarak (zaman) 'a sahip olan her fonksiyon saf olmayabilir: tfonksiyonun tüm etkilerini ve stokastik doğasını tutar: genel durumda giriş sinyaliniz vardır ve gerçek değerler hakkında fikriniz olmaz, gürültü bile ol.

İlk koşul her zaman doğruysa, ikinci koşulun doğru olmadığı zamanlar var mı?

Evet

Aşağıdaki basit kod parçacığını düşünün

public int Sum(int a, int b) {
    Random rnd = new Random();
    return rnd.Next(1, 10);
}

Bu kod, verilen aynı girdi kümesi için rastgele çıktı döndürür - ancak herhangi bir yan etkisi yoktur.

Bahsettiğiniz her iki nokta # 1 & # 2 birlikte birleştirildiğinde genel etkisi şu anlama gelir: Herhangi bir zamanda Sum, aynı i / p'ye sahip işlev bir programda sonucuyla değiştirilirse, programın genel anlamı değişmez . Bu, Referans şeffaflıktan başka bir şey değildir .