Bir programlama dili belirtimi yazmaya nasıl devam edebilirim?

Programlama dili tasarımından gerçekten hoşlanıyorum. Bazen dil projelerimin ve potansiyel kullanıcılarının kapsamlı bir standart belgesinden faydalanacağını düşünüyorum. Ben çok resmi (C ++) oldukça gayri resmi (ECMAScript) kadar değişen birçok dil standartlarına baktım, ama ben nasıl olsa ben bir şey kırmak ve böyle bir belgeyi düzenlemek nasıl gerçekten bir ele alamıyorum genel olarak teknik yazı konusunda oldukça iyi olduğumu düşünüyorum.

Uzun bir öğretici veya daha çok resmi bir matematik kağıdı gibi mi yazmalıyım? Bir referans uygulamasının yanında geliştirirsem nasıl güncel tutabilirim? Uygulama ve dokümantasyondan vazgeçip de fiili standart olarak mı davranmalıyım? Ayrıca, bir standarda sahip olmanın gerçekten önemli bir yararı var mı? Standart istemek , dilin gereksiz yere karmaşık olduğu anlamına mı geliyor?

Java dil özelliklerini hem resmi hem de okunabilir buldum ve bence makul bir yapıya sahip. Bazı W3C spesifikasyonları da iyi örnekler olabilir.

Resmi işi yapmak, dil karmaşıklığını düşük tutmanıza ve köşe vakalarını görmenize yardımcı olabilir.

Başlıklar beyin dökümü: kaynak kodlama, lexing, temel türler, değişmez değerler, operatörler, ifadeler, basit ifadeler, koşullu, döngüler, işlevler (tanımlar ve çağrılar), tür bildirimleri, modüller, derleme birimleri, değişken kapsam belirleme, çeşitli ad çözümlemeleri (ör. içe aktarma, yöntem), bellek modeli, yan etkiler, yazım, eşzamanlılık…

Bir sürü okuyun ve basit tutun

Yeni bir dil tasarlamak zor. Gerçekten zor. Ama sonuçta popüler hale gelir ve insanların zarif bir şekilde yaşadıkları bir sorunu gerçekten çözerse çok tatmin edici.

Yorumlarda da bahsettiğim gibi, Martin Fowler'ın Etki Alanına Özgü Diller'i aşağıdaki nedenlerle okumanızı tavsiye ederim :

1. Neden bir dil tasarlamanız gerektiği konusunda birçok pratik derinliğe giriyor
2. Nasıl yapılacağı hakkında ayrıntılar var (ayrıştırıcılar, sözlük analizörleri, dil çalışma tezgahları vb.)
3. Seçtiğiniz sözdiziminin kapanışlar, ek açıklamalar, sabit listeler, dinamik alım vb.

Spesifikasyonunuzu nasıl yazacağınıza gelince, kitlenizi düşünün. Açıkçası, dilinizi tasarlamak için parmağınızı klavyeye koymadan önce ne yapması gerektiğini dikkatlice düşünmüş olacaksınız.

JavaScript'in yerini almak için yeni ve yorumlanmış bir dilse, web geliştiricilerine sınırlı bir dikkat süresi ve anında sonuç alma arzusu ile veya mümkün olduğunda daha hızlı bir şekilde ulaşmak için çok laissez faire yaklaşımı isteyeceksiniz.

Titan'ın bir sonraki görevinde kullanılacaksa, her bir bileşenin davranışının kesin resmi kanıtlarını gösteren son derece ayrıntılı özellikler minimum giriş seviyesi olacaktır.

Yani, bu basit bir şey değil. Spesifikasyona yaklaşmak için, muhtemelen dillerinizi oluştururken ve bunları gerçekten günlük olarak kullanan kişilerle çalışırken çok fazla deneyim kazanmanız daha iyi olur. İstekli kurbanlarınız varsa ... geliştiricileriniz, işinizde dilinizi öğrenmek için biraz zaman ayırabilecekleri takdirde, onu kullanmaları için neye ihtiyaç duydukları hakkında geri bildirimde bulunabilirler.

Kısacası, basit tutun ve daha fazla kişi onu kullanacaktır.

Wirth birçok programlama dili tasarladı ve uyguladı: Bunlardan Oberon ve Oberon2 dillerinin özellikleri tamlık, sağlamlık ve okunabilirlik açısından dikkat çekicidir.

Ortak Lisp ve Haskell dil standartlarına sahiptir. Ruby ve Python'un uygulamaları ve belgeleri vardır. Bu yüzden bir dil standardının gerekli olmadığını söyleyebilirim, ancak tasarladığınız dilin birden fazla uygulanmasını bekliyorsanız yardımcı olabilir. Öte yandan, dil tanımınızda önemli değişiklikler bekliyorsanız, standart bir prematürdür.

herhangi bir şartname kısa olmalı ve zaman testine dayanabilmelidir

bu yüzden birçok dil standardı için kullanılan BNF gibi bir soyutlama görüyorsunuz ... terse ve mevcut araçlarımızın birçoğu geride bırakıldıktan çok sonra anlaşılacak.

tabii ki sadece bir gramerden daha fazlası var. başkalarının ne yaptığını görün ... perl6, şema, C ... uygulayıcının da önem verdiği konuları ele alıyorlar.