Sözleşmeler ve bağımlı tipleme arasındaki ilişki

Bağımlı tipler ve programlama sözleşmeleriyle ilgili bazı makaleler okudum. Okuduklarımın çoğundan, sözleşmelerin dinamik olarak kontrol edilen kısıtlamalar olduğu ve bağımlı türlerin statik olarak kontrol edildiği görünüyor.

Kısmen statik olarak kontrol edilen sözleşmelerin mümkün olabileceğini düşündüren bazı makaleler var:

• Hibrit Tip Kontrolü (C. Flanagan - 2006)
• Hibrit Çeşitlerini ve Sözleşmeleri Birleştirme (J. Gronski, C. Flanagan - 2007)

Bununla birlikte, önemli miktarda örtüşme olduğu görülüyor ve sözleşmelere ve bağımlı türlere göre kategorize etmem ortadan kalkıyor.

Her iki kavramda da eksik olan daha derin bir şey var mı? Yoksa bunlar gerçekten aynı temel kavramı temsil eden bulanık kategoriler midir?

Pratik düzeyde, sözleşmeler iddiadır. Bir programın bireysel uygulamalarının özelliklerini (niceliksiz) kontrol etmenizi sağlarlar. Kontrat kontrolünün merkezinde kilit fikir, suçlama fikridir - temel olarak, bir sözleşme ihlali için kimin suçlu olduğunu bilmek istersiniz. Bu, bir uygulama (söz verdiği değeri hesaplamayan) veya arayan (bir işlevi yanlış türde bir değere geçiren) olabilir.

Temel fikir, alan teorisinin ters sınır yapısında gömme-projeksiyon çiftleriyle aynı makineleri kullanarak suçlamayı izleyebileceğinizdir. Temel olarak, iddialarla çalışmaktan, biri program içeriğini suçlayan, diğeri ise programı suçlayan iddia çiftleriyle çalışmak arasında geçiş yaparsınız. O zaman bu, üst düzey fonksiyonları sözleşmelerle sarmalamanıza izin verir, çünkü işlev çiftinin tutarsızlığını, iddia çiftini değiştirerek modelleyebilirsiniz. ( Örneğin Nick Newton'un "Dinamik Yazma İşlemini Geri Alma" adlı makalesine bakın .)

Bağımlı türler türlerdir. Tipler, belirli programların kabul edilebilir olup olmadığını iddia etmek için kuralları belirtir. Sonuç olarak, işlevleri kötü davranışlı programların ilk başta var olmasını engellemek olduğundan suçlama kavramı gibi şeyleri içermezler. Suçlanacak hiçbir şey yok, çünkü sadece iyi oluşturulmuş programlar bile gramer ifadeleridir. Pragmatik olarak, bu, nicelikleri olan terimlerin özelliklerinden bahsetmek için bağımlı türleri kullanmanın çok kolay olduğu anlamına gelir (örneğin, bir fonksiyonun tüm girdiler için çalıştığı).

Bu iki görüş aynı değildir ancak birbiriyle ilişkilidir. Temel olarak, mesele şu ki, sözleşmelerle evrensel bir değerler alanıyla başlıyoruz ve işleri kesmek için sözleşmeler kullanıyoruz. Ancak türleri kullandığımızda, daha küçük değer alanlarını (istenen özellikte) belirtmeye çalışırız. Böylece ikisini tip odaklı ilişkiler aileleri (yani mantıksal ilişkiler) aracılığıyla bağlayabiliriz. Örneğin, bkz. Ahmed, Findler, Siek ve Wadler’in “ Herkes İçin Suçlama” ya da Reynolds’un “Türlerin Anlamı: İçselden Dışsal Semantik” e bakınız .

Hem türlerin hem de sözleşmelerin saldırdığı (oldukça soyut) sorun "Programların belirli özelliklere sahip olmasını nasıl sağlarsınız?". Burada, daha geniş bir özellik sınıfını ifade edebilmek ve bir programın bir özellik olup olmadığını kontrol edebilmek arasında içsel bir gerginlik vardır. Tip sistemleri genellikle çok özel bir özellik sağlar (program hiçbir zaman belirli şekillerde çökmez) ve tip kontrol algoritması vardır. Öte yandan, sözleşmeler çok geniş bir özellik yelpazesi belirtmenize izin verir (örneğin, bu programın çıktısı bir asal sayıdır), ancak bir kontrol algoritması ile gelmez.

Bununla birlikte, kontrat kontrol algoritması olmaması (her zaman işe yarar), neredeyse kontrat kontrol algoritması olmadığı anlamına gelir (pratikte çalışma eğilimindedir). Spec # 'a ve Frama-C'nin Jessie eklentisine bakmanı tavsiye ederim . Her ikisi de "bu programın bu sözleşmeye uyduğunu" doğrulamak için doğrulama koşulu yaratma yoluyla birinci mertebeden bir mantık ifadesi olarak ifade etmek ve daha sonra bir SMT’ye sormakla çalışmaktadırlar.gitmek için çözücü bir kanıt bulmaya çalışın. Çözücü bir kanıt bulamazsa, program ya yanlıştır ya da, çözücüsü var olan bir kanıtı bulamamıştır. (Bu nedenle "neredeyse" bir sözleşme kontrol algoritması budur.) Sembolik yürütmeye dayalı araçlar da vardır, bu da kabaca "bu programa bu sözleşmeye uymak" ifadesinin bir demet önermesi olarak ifade edildiği anlamına gelir (bazı mantıklarda). Bakınız, örneğin, jStar .

Flanagan'ın çalışması, her iki dünyanın da en iyisini elde etmeye çalışır, böylece tür benzeri özellikleri hızlı bir şekilde kontrol edebilir ve daha sonra geri kalanlar için çalışabilirsiniz. Hibrit türlere pek aşina değilim, ancak yazarın motivasyonunun daha az ek açıklama gerektiren bir çözüm bulmak olduğunu (ESC / Java'daki önceki çalışmasından daha fazla) olduğunu söylediğini hatırlıyorum. Bununla birlikte, bir anlamda, ESC / Java (ve Spec #) 'daki tipler ve sözleşmeler arasında da bir miktar bütünleşme vardır: sözleşmeleri kontrol ederken, çözücüye tip kontrolünün başarılı olduğunu ve bu bilgiyi alabilmesi söylenir.

Sözleşmeler statik olarak kontrol edilebilir. Dana Xu'nun ESC / Haskell'deki eski çalışmasına bakarsanız, derleme zamanında tam kontrat kontrolü uygulayabildi, ancak yalnızca aritmetik için bir teoremi kanıtladı. Doğru hatırlıyorsam sonlandırma basit bir derinlik sınırıyla çözülür:

Hem sözleşmeler hem de türler, işlevlerde Hoare stili (ön / son koşul) belirtimlerini temsil etmenize olanak sağlar. Her ikisi de derleme zamanında statik olarak veya çalışma zamanında dinamik olarak kontrol edilebilir.

Bağımlı türler, tip sistemindeki çok çeşitli özellikleri, sözleşmeli programcıların beklediği mülk türlerini kodlamanıza olanak tanır. Bunun nedeni , türün değerlerine bağlı olmalarıdır . Bağımlı türlerin statik olarak kontrol edilme eğilimi vardır, ancak alıntı yaptığınız makalelerin alternatif yaklaşımlara baktığına inanıyorum.

Sonuçta, çok az fark var. Bence bağımlı tipler, spesifikasyonları ifade edebileceğiniz bir mantıktır, sözleşmeler ise spesifikasyonları ifade ettiğiniz bir programlama yöntemidir.