İlkay İlknur

just a developer...

The Roslyn Project - 5N1K (Ne,nerede,ne zaman,nasıl,neden,kim)

Merhaba Arkadaşlar,

C# 4.0 ve VB.NET 10 programlama dili sürümleriyle beraber Microsoft tarafında bu iki programlama dilini geliştiren ekipler tek bir çatı altında toplandı. Tek bir çatı altında toplanmasının temel nedeni de aslında programlama dillerini kullanan developerların benzer ihtiyaçlarının olması ve programlama dillerinin özelliklerinin birbirlerinden farklı olmasının önüne geçilerek  ortak temalar üzerinden ilerlenmesi idi.

Tüm bu çalışmalar kapsamında C# 4.0 sürümünün release olmasından sonra programlama dili ekipleri 2 ayrı takıma ayrılarak geliştirmelere devam etmekteler. Bir ekip şu anda C# 5.0 ve VB.NET 11 ( programlama dilleri arasındaki farklılıkları gidermek amacıyla VB 11 ile beraber C#’ta uzun zamandır bulunmakta olan Iterators özelliği geliyor olacak. ) dediğimiz programlama dillerinin bir sonraki versiyonu olan ve ana teması Asenkron Programlama olarak belirlenen geliştirmelere devam ederken bir diğer ekipte daha uzun soluklu bir proje olan Roslyn kod adlı projeye devam etmekteler.

Özellikler C# programlama dilinin geleceği ile ilgili araştırmalar yaptıysanız Compiler as a Service(CaaS) konseptiyle mutlaka karşılaşmışsınızdır. İşte Roslyn projesinin temel amacı da bu. Compiler as service, yani compiler’ın bir API vasıtasıyla servis olarak dışarıya açılması.

Şu anda C# ve VB compilerının yapısına  baktığımız zaman compilerların tam bir kara kutu olduğunu söyleyebiliriz. Çünkü compilerlar yazmış olduğumuz kaynak kodu input olarak alırlar , içeride sihir gerçekleşir ve output olarak .NET assemblyleri üretirler. Compiler aslında bu sihrin gerçekleşmesi sırasında yazmış olduğumuz kod ile ilgili pek çok analiz yapar ve bir takım yapılar oluşturur. Ancak .NET assemblysi üretilmesiyle beraber compiler yaratmış olduğu bu yapıları tamamen siler ve unutur.

Ayrıca syntax highlighting, go to definition, formatting veya refactoring gibi üretkenliğimizi arttıracak olan özelliklerde de baktığımız zaman IDE tarafından sağlanan bu özelliklere sıkı sıkıya bağlı olduğumuz görmekteyiz. Developer olarak kendi ihtiyaçlarımızı karşılayacak olan refactoring mekanizmalarını gerçekleştirmemiz oldukça zor. Aslında syntax highlighting, go to definition, formatting veya refactoring gibi özellikleri incelediğimizde tüm bu özellikler arka planda compiler’ın kodu derleme ve Assembly üretme sırasında kullanmış ve yaratmış olduğu yapıları kullanmakta.

Tüm okuduklarımızı düşündüğümüze Roslyn projesi ile amaçlanan compilerın kara kutu olmaktan çıkarılarak ve içerisinde bulunan bilgilerin bir API vasıtasıyla developerlara sunulmasıdır. Bu doğrultuda da C# ve VB compilerları kendi dillerinde !!! yani managed programlama dilleriyle yeniden implemente edilemekte. Evet yanlış okunmadınız :) Bir takım tarihsel nedenlerden dolayı C# ve VB compilerları C++ programlama dili ile yazılmıştır. Ancak Roslyn projesinden C# ve VB compilerları kendi dillerinde yeniden yazılmaktalar.

Compiler içerisindeki yapıları bir API ile dışarı sunulması peki developerlar için neler sağlayacak ? Aslında yapılabilecek pek çok şey bulunmakta. İlk aklımıza gelen, özellikle dinamik programlama dillerinde gördüğümüz Read-Eval-Print Loop’lar artık implemente edilebilir durumda olacak. Programlama dili içerisindeki scripting yeteneğinin bu şekilde hayata geçtiğini görüyor olacağız. Bunun yanında Meta-Programming dediğimiz aslında program yazan program olarak Türkçe’ye çevirebileceğimiz mekanizmalarda artık gerçekleştirilebiliyor olacak. Ayrıca Language-Object-Model’a sahip olarak, yazılan kod üzerinde tüm analizleri yapabiliyor olacağız. Kendi yazacağımız extensionlar veya uygulamalar ile çok çeşitli kendimize özel refactoring mekanizmalarını hayata geçirebiliyor olacağız. Ayrıca DSL(Domain – Spesific –Languages) Embeding dediğimiz kendi uygulamamıza has bir takım komutlar arasına C# veya VB kodu yerleştirebiliyor ve bu kodları da istediğimiz zaman işletebilir durumda oluyor olacağız.

Roslyn APIs

Yazmış olduğumuz kodların .NET assembly’si haline çevrilmesi süreci aslında compiler içerisinde 4 farklı süreci içerisinde barındırmakta. Bunlar,
  • Parser : Kaynak kodu geçmiş olduğu ilk süreçtir. Bu süreç içerisinde kaynak kod parse edilerek kod tokenlara ayrılır. Ayrılan tokenlar aynı zamanda yapısal bir veri yapısına getirilirler. (Syntax Tree)
  • Symbols & Metadata Import : Bu aşamada kaynak kod içerisindeki tanımlamalar bulunur ve analiz edilir. Daha sonrasında ise sembol tabloları oluşturulması amacıyla bu tanımlamalar ile ilgili metadatalar okunarak sembol tabloları oluşturulur.
  • Binder : Bu aşamada da sembol tablosundaki tanımlamalarla kod içerisinde yapılmış olan tanımlamalar eşleştirilir.
  • IL Emitter : Son aşama olan bu aşamada ise tüm oluşturulan yapılar ve bilgiler birleştirilerek .NET Assembly’si oluşturulur.
Peki Compiler API’ları tam olarak bu süreçlerin neresine oturmakta ?

Compiler API’larını incelediğimizde aslında her bir süreci ayrı olarak içerisinde barındıran farklı API’ları görmekteyiz. Parsing süreci içerisinde Syntax Tree API bulunurken bu API ile Parsing işlemi sürecinde üretilen Syntax Tree üzerinde işlemler gerçekleştirilebilmekte. Aynı şekilde Symbol API, Binding and Flow APIs ve Emit API da geri kalan süreçler ile ilgili işlemleri içerlerinde barındırmakta.

Önceki paragraflarda IDE içerisinde bulunan ve developerların özellikle üretkenliklerini arttıran özelliklerin aslında compiler tarafından üretilen yapıları kullandığından bahsetmiştik. Peki hangi özellikler hangi aşamadaki bilgileri ve API’ları kullanmakta ?

Formatting, colorizer ve outlining gibi özelliklerin Parsing işlemi sonrasında üretilen Syntax Tree’yi kullandığını görmekteyiz. Navigate To ve Object Browser özellikleri de Symbol API tarafından sunulan Sembol Tablosuna dayanmakta. Intellisense, Rename, Extract Method, Go To Definition gibi IDE içerisinde bulunan pek çok özellikte Binding işlemi sonucunda üretilen yapılara dayanmakta. Edit and Continue ise Emit API tarafından gerçekleştirilmekte.

Compiler as Service konsepti aslında oldukça geniş ve içerisinde pek çok bilgiyi barındıran bir konsept. Roslyn projesinin tamamlanmasıyla beraber pek çok özelliğin geleceğini ve çok yaratıcı uygulamaların ortaya çıkacağını söylemek sanırım yanlış olmaz. Bu uzun soluklu projeyi en başından itibaren takip etmenizi şiddetle öneriyorum.

Roslyn projesinin ne zaman tamamlanacağını soracak olursanız açıkcası bunun için süre vermenin çok doğru olacağını düşünmüyorum. Ancak şunu söyleyebilirim ki C# 5.0 ile gelmiyor olacak :)

Roslyn projesinin şu anda CTP sürümü bulunmakta. Bu sürümü buradaki adresten indirip kurabileceğiniz gibi aynı zamanda NuGet Package Manager’a Roslyn yazarak ta projenize ekleyebilirsiniz ;) .

Bir sonraki yazımızda Roslyn ile derinlere dalıyoruz ;)



Yorum Gönder