[EDIT: Voilà hakkında her biri birkaç kelime]
HM tipi çıkarımı genişletmenin birkaç yolu vardır. Benim cevabım, birçoğunu hayata geçirme girişimlerine dayanıyor. Tökezlediğim ilk parametrik polimorfizm . HM'yi bu yönde uzatmaya çalışan tip sistemleri, Sistem F'ye yönelir ve bu nedenle tip ek açıklamaları gerektirir. Bu yönde karşılaştığım iki önemli uzantı:
HMF, tüm System-F tipleri için tip çıkarımına izin verir, yani bir tipin "ortasında" evrensel bir niceme sahip olabilirsiniz, görünüşleri HM polimorfik tipler gibi en yüksek kapsamda yer almaz. Belge açıkça ne tür ve hangi tür açıklamaların gerekli olabileceği konusunda net bir kural bulunmadığını açıkça ifade eder. Ayrıca, Sistem F'ye ait olan türler, terimler genellikle bir ana tür değildir.
MLF, yalnızca HM'nin bir uzantısı değildir, aynı zamanda, türler üzerinde bir tür sınırlı miktar belirlemesi yaparak, HM'nin temel tip özelliğini yeniden kazanmış olan Sistem F'nin bir uzantısıdır. Yazarlar arasında bir karşılaştırma yapılmıştır, MLF kesinlikle HMF'den daha güçlüdür ve ek açıklamalar yalnızca polimorfik olarak kullanılan parametreler için gereklidir.
HM'yi genişletmenin bir başka yolu, kısıtlama alanının değişmesidir.
HM (X), bir kısıtlama alanı X üzerinde parametreleştirilmiş Hindley-Milner'dir. Bu yaklaşımda, HM algoritması, X için bir alan çözücüsüne gönderilen kısıtlamaları oluşturur. Her zamanki HM için, alan çözücüsü birleştirme prosedürüdür ve alan; terimler kümesinin türlerinden ve tür değişkenlerinden derleme.
X için bir başka örnek, Presburger aritmetiği diliyle ifade edilen kısıtlamalar olabilir (bu durumda tür çıkarımı / kontrol edilebilir durumdadır) veya Peano aritmetiği dilinde (artık reddedilemez). X, her biri ihtiyaç duyulan ve hepsinden hepsine kadar olmayan tip açıklamaların miktarı ve lokalizasyonu ile ilgili kendi gereklilikleri olan bir dizi teori boyunca değişmektedir.
Haskell'in tür sınıfları da formun tür tahminlerini ekleyerek bir sınırlama alanının bir uzantısıdır MyClass(MyType)(yani, MyType türü için bir MyClass örneği olduğu anlamına gelir).
Yazım sınıfları, yazım çıkarımını korur çünkü temelde adhoc polimorfizmini uyguladıkları (neredeyse) dikgen kavramlardır .
Bir örnek olarak, bir sembol almak valÇeşidi val :: MyClass a => asen örneği bulunabilir kendisi için MyClass A, MyClass Btür kesmesi zaten derleyici kullanımına sınıfın hangi örneğini anlaması anlamına gerçekleştirilir çünkü kodunuzda bu sembole söz ettiğimizde vb, aslında bu. Bu, türün valkullanıldığı bağlamına bağlı olduğu anlamına gelir . Bu nedenle, tek bir valifadenin çalıştırılmasının birambiguous type error : derleyici, içeriğe bağlı olarak herhangi bir tür çıkartamaz.
GADT'ler, tip aileleri, Bağımlı tipler, Sistem (F) ω vb. Gibi daha gelişmiş tip sistemler için tip artık “tip” değildir, karmaşık hesaplama nesneleri haline gelirler. Örneğin, aynı görünmeyen iki tipin mutlaka farklı olmadığı anlamına gelir. Bu yüzden tür eşitliği önemsiz hale gelmez (hiç olmazsa).
: Size gerçek karmaşıklık Bir örnek vermek gerekirse en listesinin bağımlı tip düşünelim listesindeki nesnelerin türünü ve onun uzunluğudur.
Ekleme fonksiyonu tipe sahip olacak ve zip işlevi olacaktır .
Hayal et artık lambdamız var . Burada zip'in ilk argümanı tür ve ikincisidir .
Neredeyse aynı, ancak tür denetleyicisi "+" nın doğal sayılarla işlem yaptığını bilmediği sürece, (n + m) tam anlamıyla (m + n) olmadığı için işlevi reddetmelidir. Artık tür çıkarımı / tür kontrolü ile ilgili değil, teorem kanıtlamayla ilgili.NList a nan
append :: NList a n -> NList a m -> NList a (n + m)zip :: NList a n -> NList b n -> NList (a, b) n
\a: NList t n, b: NList t m -> zip (append a b) (append b a)NList t (n + m)NList t (m + n)
Sıvı tipleri bazı bağımlı tip çıkarım yapıyor gibi görünmektedir. Ama anladığım kadarıyla, gerçekten bağımlı bir tip değil, daha çok statik sınırları hesaplamak için ek çıkarım yapan normal HM tipleri gibi bir şey.
Umarım bu yardımcı olur.