Kavşak ve sendika tipleri ile ilgili pratik konular nelerdir?

Öğrenme deneyimi olarak basit ve statik olarak yazılmış işlevsel bir programlama dili tasarlıyorum.

Şimdiye kadar uyguladığım tip sisteminin, (biraz fazladan bir çalışma ile) kesişme ve sendika tipleri içerebileceği anlaşılıyor, örneğin:

• <Union String Integer>
• <Union Integer Foo>
• Yukarıdaki iki türün kesişimi düz olacaktır Integer
• İki tür birliği olurdu <Union String Integer Foo>

Bunun mümkün olması elbette gerekli değil, iyi bir tasarım fikri olduğu anlamına gelmez. Özellikle, türleri birbirinden ayırma ve / veya çakışmalarla ilgilenme konusundaki uygulama zorlukları konusunda biraz endişeliyim.

Bu özelliklerin tip sistemine dahil edilmesinin artıları / eksileri nelerdir?

Akılda tutulması gereken birkaç şey:

• Genellikle biz seti-teorik kesişme ve birlik ile ne demek biliyorum rağmen, birkaç farklı tam kavşak ve sendika türleri ne alır olmuştur vardır . Bu yüzden, bir uygulamaya başlamadan önce bunu tespit etmeye değer.
• Kavşakları ve sendikaları anlamak için çok önemli olduğunu düşündüğüm bir unsur, tür iyileştirme kavramıdır , temel olarak bir programın belirli bir içsel "arketip" (ör. " Foo , tamsayıdan tamsayıya kadar bir fonksiyondur") olduğu fikridir. daha sonra daha kesin özellikleri ifade etmek için rafine edilmelidir (örneğin, " foo , tamsayıları bile tam sayılara, tek tamsayıları tek tamsayılara bile götürür"). Eldeki inceltme kavramıyla, kavşakları ve sendikaları ürünlerden ve toplamlardan ayıran en önemli özellik, iki tipteki kesişme / birleşmenin ancak aynı arketipi geliştirmeleri halinde oluşturulabilmesidir. Başka bir deyişle, kavşaklar ve sendikalar için tip oluşturma kuralları şöyle ifade edilebilir (okundu).$S \sqsubset A$$S$$A$ $$\frac{S\sqsubset A \quad T \sqsubset A}{S\cap T\sqsubset A}\qquad \frac{S\sqsubset A \quad T \sqsubset A}{S\cup T\sqsubset A}$$ $$\frac{S\sqsubset A \quad T \sqsubset B}{S* T\sqsubset A*B}\qquad \frac{S\sqsubset A \quad T \sqsubset B}{S+T\sqsubset A+B}$$
• Bir programın çalışma zamanı davranışı hakkında daha kesin iddialarda bulunmak için kesişimler ve sendikalar kullanılabileceğinden, yazmanın değerlendirme sırasına duyarlı olması doğaldır. Örneğin, aşağıdaki kağıtlar (2) ve (4) , kesişmeler ve sendikalar için "açık" (ve oldukça standart) yazım ve alt yazma kurallarının neden ML benzeri diller için (yan etkiler var ve olmayanlar nedeniyle) gerçekte sade olmadığını açıklamıştır. sonlandırma). Uyarıldın!
• Benzer nedenlerden ötürü, küresel tip çıkarımı genellikle pratik değildir veya kararlaştırılamaz hale gelir. Aslında, bütün "ana tip" kavramı tartışılabilir bir şekilde kırmızı bir ringa balığıdır, çünkü bir işlev, kullanım amacı ile ilgisi olmayan birçok farklı özelliği yerine getirebilir (örneğin, " foo , 7'den büyük tamsayılar için asal tamsayıları alır"). Bunun yerine, kavşaklara ve sendikalara pratik yaklaşımlar (bkz. (3) , (4) ) genellikle çıkarım ve kontrol kombinasyonuna dayanır.

Sanırım yukarıdaki noktalardan bazıları olumsuz gelebilir, ancak ben onlara "eksilerini" değil, sadece kesişme ve sendika tiplerinin "gerçeklerini" söyleyemem. Öte yandan, dil tasarımı açısından bakıldığında, kavşakları ve sendikaları destekleme çabasını gösterme nedenlerinden biri (ve doğru olmaları için!) Programların daha kesin özelliklerinin oldukça artımlı bir şekilde ifade edilmesine izin vermesi ve Bağımlı tip teorisinden çok daha az şiddetli dönüşüm.

Kısa bir okuma listesi:

1. John C. Reynolds tarafından programlanan dil forsythe tasarımı
2. Rowan Davies ve Frank Pfenning'in Kavşak Tipleri ve Hesaplamalı Etkileri
3. Rowan Davies tarafından Pratik Arıtma Tipi Kontrol (tez çalışması)
4. Joshua Dunfield ve Frank Pfenning'den Üç Yönlü Tipik Kontrol