Raku derleme zamanında ne tür kontroller yapar? Bu gelecekte değişebilir mi?

Aug 19 2020

Şu anda (Ağustos 2020 itibariyle) Rakudo, derleme zamanında işlevlerin dönüş değerlerini denetlemiyor; diğer bir deyişle, işlevlerin kendi dönüş sınırlamalarını karşıladığına dair statik garantiler sağlamaz. Somut olarak, aşağıdaki iki işlevin her ikisi de Raku olarak derlenir:

sub get-int(--> Int) { 'bug' }
sub get-int($a --> Int} { when $a == 5 { 'Rare bug' }
   default      { 42 }
}

İlgili iki sorum var:

  1. Şu anda hangi tip kontrolünün (varsa) derleme zamanında gerçekleştiğini bilmenin bir yolu var mı? (Ya birinin yazdığı bir liste aracılığıyla, belgelerde bir yerde ya da Rakudo kaynağında merkezi bir yerde) Ya da bundan daha geçici mi?

  2. Bu derleme zamanı eksikliği, kasıtlı bir tasarım kararını kontrol ediyor mu? Yoksa bir gün olması güzel olacak, ancak henüz uygulanmamış bir şeyi kontrol etmek için daha fazla statik yazı eklemek mi?

(Johnathan'ın Raku'daki türler / kısıtlamalar için performans cezaları? Sorusuna verdiği harika cevaba aşinayım , "Raku programa yazılan tür kısıtlamalarının en geç çalışma zamanında uygulanmasını zorunlu kılar ." Bu yanıt, çalışmayı önlemenin çeşitli yollarını açıklar. - typechecks zaman maliyetleri, ancak eğer varsa, typechecks derleme zamanında ne yapıldığını açıklamaz (bu kesinlikle çalışma zamanı maliyetlerinden kaçınacaktır!)

Yanıtlar

12 JonathanWorthington Aug 19 2020 at 12:04

Şu anda, derleme zamanında çok az tür denetimi yapılmaktadır; çoğunlukla statik optimize edicinin bir yan etkisi olarak yer alır. Bugünkü kontroller büyük ölçüde alt rutin çağrıları ile ilgilidir, burada:

  • Çağrının gerçekliğini belirleyebilir ve aktarılan argüman sayısının asla eşleşmeyeceğini biliriz
  • Gerçek argümanlarımız var ve bunların imzayla asla eşleşemeyeceğini görebiliyoruz

Bu, statik optimize edicinin daha fazla satır içi çalışma yaptığı zamandan kalma bir kalıntıdır. Bu günlerde, yalnızca yerel operatörleri derleme zamanında satır içi olarak sıralıyor ve geri kalanını sanal makinenin dinamik optimize edicisine bırakıyor, bu da çok daha fazla satır içi beceriye sahip ve aynı zamanda satır içi olmayan (spekülatif optimizasyona izin veriyor, ancak aynı zamanda orijinal yığın izlerinin kurtarılabileceği anlamına geliyor) statik optimize edici bu bilgiyi kaybetti).

Derleme zamanında daha fazlasını yapmak arzu edilen bir durumdur, ancak dikkate alınması gereken bazı pratik konular vardır.

  1. Ek kontrollerin uygulanması, daha önce işe yarayan kod kırılmasına da neden olabilir. Daha sıkı bir derleme süresi denetiminde başarısız olacak, ancak bu durumla asla karşılaşmayan sistemlerde kullanılan bir kod yoluna sahip bir modül düşünün. Derleyicinin daha yeni sürümlerinde derleme başarısız olmaya başlarsa, bir derleyici yükseltmesinden sonra bu sistemi dağıtmak imkansız hale gelir. Genel olarak bu, yapılan kontrollerin dil sürümü değişikliklerinde değişmesi gerektiği anlamına gelir. (Bu yine de insanların kod yazarken yazdıkları dil sürümünü beyan etmeleri gerektiği anlamına gelir.)
  2. Derleme zamanında daha fazla denetim yapılmasının "kesinlikle çalışma zamanı maliyetlerinden kaçınacağı" doğru olabilir, ancak mantık yürütmek önemsiz değildir. Yönetilen bir çalışma zamanı, verilen bayt kodunda verilen sözlere körü körüne güvenemez, çünkü bu, bellek güvenliği ihlallerine (SIGSEGV veya daha kötüsüne yol açar) yol açabilir. Bu, tip kontrolünün anlambiliminin programlanabilir olduğu Raku gibi bir dilde oldukça doğrudur, ancak JVM, CLR vb. İçin doğrudur. Raku'daki türle ilgili en büyük kazançlar, yerel türlerin kullanımından gelir, bu da çok fazla ayırmayı ve dolayısıyla çöp toplama işini önleyebilir.
  3. Daha fazla denetim uygulamak, derleyicinin karmaşıklığını ve ayrıca derleme için gereken süreyi artıracaktır. Bunlardan ilki zaten bir sorun; derleyici kullanıcı arabirimi, yaklaşık on yıldır herhangi bir önemli mimari değişiklik görmedi. Makrolar için temel oluşturan mevcut RakuAST çalışması, derleyici ön ucunun neredeyse yeniden yazılmasını da içerir. İyileştirilmiş mimari, daha fazla derleme zamanı türü denetimlerinin uygulanmasını kolaylaştırmalıdır, ancak derlemenin yönlerinin nasıl paralelleştirilebileceği üzerine de düşünülür, bu da derleyicinin wallclock derleme süresini artırmadan daha fazlasını yapmasını sağlayabilir.

Mevcut derleyici ön uç revizyonu tamamlandığında, daha fazla derleme zamanı kontrolünün tanıtılması (ancak yalnızca bir sonraki dil sürümünden etkinleştirilir) oldukça olası görünüyor - en azından birileri üzerinde çalıştığı sürece.

Bununla birlikte, bu alanda daha da heyecan verici bir fırsat doğuyor: Raku programlarına bir API olacağından ve özel derleyici geçişleri için bir araya gelen planlarla, tür denetleyicilerini modüller olarak uygulamak da yakında mümkün olacak ! Bunlardan bazıları, onu gelecekteki Raku dil sürümlerine dönüştüren kontrollere yol açabilir. Diğerleri, tamamen alana özgü olabilir ve belirli bir modülün daha doğru kullanımını sağlamayı amaçlayabilir. Diğerleri, temel dilin ruhuna uymayan, ancak bazı dil kullanıcılarının katılmak isteyebileceği katı kuralları uygulayabilir.