Dil tasarımcıları belirli bir özelliğin doğru çalıştığına karar vermek veya kanıtlamak için ne yapar?

Dil tasarımıyla ilgileniyorum ve genel olarak yaygın olarak bilinen özellikler (örneğin kalıtım, polimorfizm, delegeler, lambdalar, yakalamalar, çöp toplama, istisnalar, jenerikler, varyans, yansıma vb.), belirli bir dil, uygulanabilme biçimleri, sınırlamaları vb.

Son birkaç ay içinde, nesne yaşamlarını statik olarak doğrulanabilir olmaya zorlayarak bellek güvenliğini ve deterministik kaynak yönetimini sağlayan bir sahiplik sistemine sahip olan Rust hakkında okumaya başladım. Dilin sade bir kullanıcısı açısından, sistemi hemen alabilirim.

Bununla birlikte, bir dil tasarımcısı bakış açısından, Rust'daki şeylerin neden oldukları gibi olduğunu anlamak biraz zaman aldı. Kendimi, bu yönlere sahip olmasaydı bir sistemin bütünlüğünü ihlal edecek davaları ortaya çıkarmaya zorlayana kadar, sahiplik sisteminin bazı kısıtlamalarının ardındaki mantığı anlayamadım.

Benim ana sorum Rust ve onun mülkiyeti ile hiçbir ilgisi yok - ama gerekirse yorumlarınızda / cevaplarınızda örnek olarak kullanmaktan çekinmeyin.

Dil tasarımcıları yeni bir özellik tasarladığında, özelliğin düzgün çalıştığına karar vermek için hangi metodoloji veya süreci kullanıyorlar?

"Yeni" demek istediğim, mevcut dillerde zaten test edilmiş bir şey değil (ve dolayısıyla işin büyük kısmı diğer tasarımcılar tarafından yapılmıştır). "Düzgün çalışıyor" ile, özelliğin amaçlanan sorunu doğru bir şekilde çözdüğünü ve makul derecede kurşun geçirmez olduğunu kastediyorum. "Makul kurşun geçirmez" ile, dilde veya dilin belirli bir alt kümesinde (örneğin "güvenli olmayan" kodu olmayan bir alt küme) özelliğin bütünlüğünü ihlal edecek hiçbir kod yazılamayacağı anlamına gelir.

• Özelliğin basit bir formunu bulmanız, daha sonra onu ihlal etmenin yollarını bulmaya çalışın, ardından başarılı bir şekilde ihlal ederseniz yama yapın ve tekrarlayın. Ve sonra, başka olası ihlalleri düşünemediğinizde, bir şey kalmayacağını ve bir gün diyeceğini umuyor musunuz?

• Yoksa özelliğinizin işe yaradığını (kelimenin matematiksel anlamıyla) gerçekten kanıtlamanın resmi bir yolu var mı ve daha sonra özelliği en baştan (veya çoğunlukla doğru) güvenle elde etmek için bu kanıtı mı kullanıyorsunuz?

(Bilgisayar bilimi değil, mühendislik geçmişim olduğunu belirtmeliyim. Bu yüzden CS çalışanlarına açık olacak bir şeyi kaçırırsam, lütfen bunu belirtmekten çekinmeyin.)

Şu anda tam referansı bulmakta zorlanıyorum, ancak bir süre önce Haskell'in tasarımına büyük katkıda bulunan Simon Peyton Jones'un birkaç videosunu izledim . Bu arada tip teorisi, dil tasarımı ve benzerleri üzerine mükemmel bir konuşmacıdır ve youtube'da ücretsiz olarak birçok videoya sahiptir.

Haskell, çalışmayı kolaylaştırmak için birkaç basit şeyle zenginleştirilmiş lambda hesabı olan bir ara temsile sahiptir. Lambda hesabı bir bilgisayar sadece şeyleri hesaplayan bir kişi olduğu için kullanılmıştır ve kanıtlanmıştır. Simon Peyton Jones sık sık ilginç bir nokta, dil ile vahşi ve çılgın bir şey yaptıklarında, sonunda o ara dile geri döndüğünde temelde sağlam olduğunu bilir.

Diğer diller neredeyse çok titiz değil, kullanım veya uygulama kolaylığı lehine. Diğer programcıların yüksek kalitede kod almak için yaptıkları aynı şeyi yaparlar: iyi kodlama uygulamalarını takip edin ve ölüme kadar test edin. Rust'un sahiplik semantiği gibi bir özellik, unutulmuş köşe vakalarını bulmak için hem çok fazla resmi analiz hem de test alır. Genellikle böyle özellikler birinin yüksek lisans tezi olarak başlar.

Yani dil tasarımı için kanıtlar (veya hatalar) var. Örneğin, sistemleri yazın. Türler ve Programlama Dilleri , tür sistemlerini tanımlayan standart bir kitaptır ve tür sisteminin doğruluğunu ve bütünlüğünü kanıtlamaya odaklanır. Dilbilgileri benzer analizlere sahiptir ve algoritmalar (tanımladığınız sahiplik sistemi gibi) kendi yöntemlerine sahiptir.

Dil uygulaması için diğer kodlar gibi kodlanır. Birim testleri yazıyorsunuz. Entegrasyon testleri yazıyorsunuz. Kod incelemeleri yaparsınız.

Dilleri özel kılan tek şey, (neredeyse her zaman) sonsuz olmalarıdır. Kelimenin tam anlamıyla tüm girişleri test edemezsiniz. Dildeki herhangi bir hata yüzden Ve (ideal) onlar, garip ve ilginç şeyler yapıyor insanlar, tonlarca tarafından kullanılan edecektir sonunda bulunabilir.

Pratik olarak , nispeten az sayıda dil işlevlerini doğrulamak için prova kullanır ve bahsettiğiniz seçeneklerin bir karışımıyla sonuçlanır.

Bir dil tasarımcısının yeni özellikler getirirken dikkat etmesi gereken ilk ve en zor şey, dilini tutarlı tutmaktır:

• mevcut kodu bozmadan dil gramerine nasıl entegre edilebilir (bu matematiksel olarak kanıtlanabilir)
• varolan özellikler ile nasıl ilişkilidir (örneğin, 0..n-1 dizinli sabit dizileriniz varsa, 1..n dizinli yeni bir değişken dizi özelliği tanıtmazsınız) (bu tasarımın sanatsal kısmıdır)
• özelliğin tüm araç zinciri boyunca nasıl uygulanabileceği, böylece yeni özellik ekosistem, araç üreticileri ve programcılar tarafından absorbe edilebilir (fizibilite bir kavram kanıtı ile gösterilebilir, ancak tam uygulama programlamaya benzer bir yaklaşımdır)

Bu konuda yol göstermek için bir tasarımcı bir dizi tasarım kural ve ilkesine güvenir. Bu yaklaşım, dil tasarımına adanmış nadir kitaplardan biri olan Bjarne Stroustrup'un " C ++ tasarımı ve evrimi " bölümünde çok iyi açıklanmıştır . Çok ilginç olan, dillerin nadiren bir boşlukta tasarlandığını görmek ve tasarımcı aynı zamanda dillerinin benzer özellikleri nasıl uyguladıklarına bakmak. Başka bir kaynak (çevrimiçi ve ücretsiz) java dilinin tasarım ilkeleridir .

Standardizasyon komitelerinin kamuya açık işlemlerine bakarsanız, bunun daha çok deneme yanılma süreci olduğunu göreceksiniz. Burada C ++ modülünde bir örnek , dilin bir sonraki sürümünde tanıtılacak tamamen yeni bir konsept. Ve burada, bazı dil değişimlerinden sonra , başarısını değerlendirmek için hazırlanmış bir analiz . Ve burada yeni bir api gibi yeni Java özelliklerini tanımlamak için Java Topluluk Süreci . Bu çalışmanın yaratıcı bir konsept kâğıdı ve ilk öneri hazırlayan birkaç uzman tarafından yapıldığını göreceksiniz. Daha sonra bu teklifler, daha yüksek bir tutarlılık sağlamak için teklifi değiştirebilecek daha büyük bir topluluk / komite tarafından gözden geçirilir.

Programlama dili özellikleri nasıl test edilir? Bu çok iyi bir soru ve sanatın durumunun bu işte olduğundan emin değilim.

Her yeni özellik diğer tüm özelliklerle etkileşime girebilir. (Bu dili, belgeleri, derleyicileri, hata mesajlarını, IDE'leri, kitaplıkları vb. Etkiler) Özellikler Bir boşluk açmak için birleştiriliyor mu? Kötü kenar durumlarda oluşturmak için?

Tip sağlamlığını korumak için çok çalışan çok akıllı dil tasarımcıları bile bu Rust hatası gibi ihlalleri keşfederler . Rust'un tip sistemi benim için çok açık değil ama bu durumda tip sistem parça değer ömürlerine sahip olmak, ömür boyu "alt tip" (alt sınıflar), sıradan alt tipleme, zorlamalar, referanslar ve değişebilirlik, staticömür boyu nerede bir boşluk yaratıyorsa, çatışmalar anlamına geliyor. ref, yığına ayrılan bir değere işaret edebilir ve daha sonra sarkan bir referans haline gelebilir.

"Düzgün çalışıyor" ile, özelliğin amaçlanan sorunu doğru bir şekilde çözdüğünü ve makul derecede kurşun geçirmez olduğunu kastediyorum.

Üretim dili olması amaçlanan diller için , yani birçok programcı tarafından güvenilir üretim yazılımı oluşturmak için kullanılırsa, "düzgün çalışır" ayrıca amaçlanan sorunu hedef kitle için doğru bir şekilde çözmek anlamına gelmelidir .

Başka bir deyişle, kullanılabilirlik o tasarımın diğer türlü olduğu gibi dil tasarımına kadar önemlidir. Bu, (1) kullanılabilirlik (örneğin kitlenizi tanımak) için tasarım ve (2) kullanılabilirlik testi gerektirir.

Bu konuda örnek bir makale: “ Programcılar İnsanlar, Çok , Programlama dili ve API tasarımcıları insan faktörleri tasarımı alanında çok şey öğrenebilirler.”

Bu konudaki örnek bir SE sorusu, herhangi bir programlama dilinin sözdizimi kullanılabilirlik açısından test edildi mi?

Örnek bir kullanılabilirlik testi, bir liste yineleme özelliğini (hangi dili hatırlamıyorum) birden çok liste alacak şekilde genişletmeyi düşündü. İnsanlar listeden paralel mi yoksa çapraz çarpımdan mı yinelenmesini bekledi? Dil tasarımcıları kullanılabilirlik testi bulguları karşısında şaşırdılar.

Smalltalk, Python ve Dart gibi diller kullanılabilirlik vurgulanarak tasarlanmıştır. Açıkçası Haskell değildi.