Neden bir programlama dilden diğerine otomatik çevirmen yok? [kapalı]

Programlama dillerinin çoğu Turing tamamlandı, yani bir dilde çözülebilecek herhangi bir görevin başka bir dilde, hatta Turing makinesinde çözülebileceği anlamına geliyor. Öyleyse neden programları herhangi bir dilden başka bir dile çevirebilen otomatik çevirmenler yok? İki dilde çift girişimleri gördüm, ancak her zaman yalnızca bir dilin sınırlı bir alt kümesinde çalışıyorlar ve gerçek projeleri dönüştürmek için pek kullanılamıyorlar.

En azından teoride bütün diller arasında% 100 doğru tercüman yazmak mümkün müdür? Uygulamadaki zorluklar nelerdir? Çalışan herhangi bir tercüman var mı?

En büyük sorun program kodunun gerçek çevirisi değil, platform API'sinin taşınmasıdır.

Java çevirmen bir PHP düşünün. PHP ikilisinin bir kısmını gömmeksizin bunu yapmanın tek uygun yolu, Java'daki tüm PHP modüllerini ve API'leri yeniden uygulamaktır. Bu 10.000'in üzerinde fonksiyonun uygulanmasını içerir. Bununla karşılaştırıldığında, sözdizimini çevirme işi pasta kadar kolaydır. Bütün bu çalışmalardan sonra bile, Java kodunuz olmazdı, Java platformunda çalışacak bir tür canavarlığa sahip olacaktınız, ancak bu içeride PHP gibi yapılandırılmıştı.

Bu nedenle akla gelen tek araç, kodları daha sonra sürdürmemek için dağıtmak için kod çevirmekten ibarettir. Google’ın GWT’i Java’yı JavaScript’ten “derler”. Facebook'un hiphop PHP'yi C'ye derler.

Bir ara biçimi varsa, o zaman Dil X bir program çevirir şey uygulamak olabilir için bu biçimdeki ve ayrıca gelen Dili Y. bu formatta ilgilendiğiniz tüm diller için bu dönüşümleri uygulamak ve doğru, bitti mi?

Ne biliyor musun peki? Böyle bir format zaten var: montaj. Derleyici, zaten "X Diline Montaj" dönüşümünü gerçekleştiriyor ve "Dil-Y'ye Montaj" dönüşümünü söküyor.

Şimdi, derleme ters dönüşüm yapmak için harika bir dil değil, ancak MSIL aslında o kadar da kötü değil. İndir yansıtıcı ve farklı dillerde bir demet haline montaj bir .NET sökmeye seçenekleri var göreceksiniz (ve eklentileri daha da sağlamaktadır). Bu nedenle, C # 'da bir program almak, onu bir DLL (MSIL) olarak derlemek, sonra onu VB, C ++ / CLI, F # ve diğer gruplara ayırmak için reflektör kullanın. Tabii ki, diğer tüm dönüşüm işleri de. Bir F # dosyası alın, bir DLL dosyasını derleyin, C # 'ya dönüştürmek için Reflektör kullanın.

Elbette, bulacağınız iki büyük sorun:

1. Kod temelde okunamıyor. MSIL (hata ayıklama bilgisiyle bile) orijinal kaynaktan çok fazla bilgi kaldırır, bu nedenle çevrilen sürüm% 100 aslına sahip değildir (teorik olarak bir C # -> MSIL-> C # dönüşümü orijinal kodu size geri vermelidir, ancak alışkanlık).
2. Birçok .NET dili kendi özel kütüphanelerine sahiptir (örneğin VB çalışma zamanı kütüphanesi, F # kütüphanesi vb.). Bunları da dönüşümünüzü yaptığınızda dahil etmeniz (veya dönüştürmeniz) gerekir.

Gerçekten # 2'yi çevreleyen bir şey yok, ancak MSIL'deki bazı ek açıklamalarla muhtemelen # 1'e geçebilirsiniz (belki de nitelikleriyle). Bu elbette ek iş olurdu.

En azından teoride bütün diller arasında% 100 doğru tercüman yazmak mümkün müdür? Uygulamadaki zorluklar nelerdir?

• Daha yapılandırılmış bir dilden, hala Turing tamamlanmış olan daha az yapılandırılmış bir dile çevrilmesi her zaman mümkündür.
  • Bu iddia kesinlikle teknik olarak görülmelidir: Tercüme edilen program, yürütüldüğünde aynı sonucu verecektir.
  • Tercüme edilmiş kodun okunabilirliği veya orijinal program yapılarının korunması hakkında hiçbir şey ima edilmez.
• Daha az yapılandırılmış bir dilden daha yapılandırılmış bir dile çevirmek mümkündür, ancak çevrilen kod daha az yapılandırılmış halde kalacaktır.

Neden bir programı dönüştürmek istiyorsun?

Her iki dilde, kaynak ve hedef dil yine de (sanal) makine koduna derlenir *, bu nedenle teknik nedenlerden dolayı başka bir üst seviyedeki dil için bir derleyiciye gerek yoktur.

Diller insanlar içindir. Bu nedenle, sorunuzun örtülü gereksinimi şudur: 'neden okunabilir kod üreten bir tercüman yok ' ' ve yanıt (imho) olacaktır: çünkü yeterince farklı olan iki dil varsa,' okunabilir kod 'yolları yazılmıştır. sadece algoritmaları çevirmeyi gerektirecek şekilde değil, farklı algoritmalar alabilecek şekilde farklıdır.

Örneğin, tipik bir yinelemeyi C ve bir tane lisp olarak karşılaştırın. Ya da pitonlar deyimsel yakutla 'en iyi yoldur'.

Burada aynı problemler, 'Kedileri ve köpekleri yağmur yağıyor' anlamına gelen 'Kovalardan dökülüyor' anlamını 'ingilizceden almancaya çevirirken,' 'kovadan dökülüyor' 'anlamına gelen bir şeye çeviriyormuş gibi gerçek dillerde var gibi görünmeye başlıyor. Artık kelime kelime çevirmek, ancak anlamı aramak zorunda.

Ve 'anlam' üzerinde çalışmak kolay bir kavram değildir.

*) iyi, kahve var ...

Teorik olarak mümkün ama çoğunlukla işe yaramaz. Neredeyse herhangi bir kaynak ve hedef dil kombinasyonu mümkündür, ancak çoğu durumda hiç kimse sonuca bakmak veya kullanmak istemez.

Oldukça fazla sayıda derleyici C'yi hedef alır, çünkü C derleyicileri var olan hemen hemen her platform için kullanılabilir (ve bir işlemci tasarlamanıza ve otomatik olarak yeni işlemcinizi hedefleyen bir C derleyicisi oluşturmanıza yardımcı olacak otomatik derleyici jeneratörleri vardır). Elbette, .NET, JVM, C-- ve LLVM gibi çeşitli sanal makineler tarafından kullanılan dilleri hedef alan çok sayıda uygulama vardır.

Bununla birlikte, kilit nokta, yalnızca, hedefi temelde, derleme işleminde yalnızca bir adım olarak kullanılan bir montaj dili olarak değerlendirirseniz gerçekten yararlı olmasıdır. Özellikle, genel olarak do not normal bir programcı okumak veya bu sonuçla çalışma istiyorum; genellikle çok okunaklı olmaz.

FWIW, Java'dan D'ye bir tercüman var. Buna TioPort adı verildi ve SWT'yi D'ye taşımak için oldukça ciddi bir girişimde kullanıldı. Karşılaştığı asıl sorun, Java standart kütüphanesinin büyük bölümlerini taşımak için gerekli olmasıydı. .

Kendi başına kod çevirisi olmasa da, dil tezgahları konsepti, tüm diller arasında% 100 doğru bir çevirmene nasıl bir şey uygulanabileceğini gösterir.

Mevcut yaklaşımımızda kaynak kod metin biçiminde saklanır. Derleme sırasında, insan tarafından okunabilen bu metin dosyaları, sırayla bytecode veya makine kodu üretmek için kullanılan soyut bir sözdizimi ağacı temsiline ayrıştırılır. Ancak bu soyut temsil derleyici için geçici ve içseldir.

Dil tezgahı yaklaşımında, benzer bir soyut sözdizimi ağacı temsili kalıcı, depolanan yapıdır. Hem makine kodu hem de metinsel 'kaynak' kodu bu soyut gösterime dayalı olarak oluşturulur. Böyle bir yöntemin sonuçlarından biri, programın soyut temsilinin aslında dil-agnostik olduğu ve herhangi bir uygulamalı dilde metin kodu üretmek için kullanılabildiğidir. Yani, bir kişi sistemin en uygun gördüğü dili kullanarak özgürce çalışabilir veya ekibin her bir üyesi, en aşina oldukları dilde ortak proje üzerinde çalışabilir.

Bildiğim kadarıyla, teknoloji hala ana akım gelişiminde kullanılabilir olmaktan uzak, ancak üzerinde bağımsız olarak çalışan birkaç grup var. Onlardan herhangi birinin vaatlerini yerine getirip getirmeyeceğini söylemek zor, ama bunun olacağını görmek ilginç olurdu.

Orada olan bazı otomatik çevirmen. Amacınız okunabilir kod yerine derlenebilir bir kod üretmekse, çok sık değil, oldukça mümkün ve zaman zaman kullanışlıdır. Ünlü olarak, ilk C ++ derleyicisi aslında bir derleyici değildi, ancak C ++ 'ı daha sonra C derleyicisi tarafından derlenen (gerçekten karmaşık) C kaynağına çevirdi. Birçok derleyici istek üzerine montaj kodu oluşturabilir - ancak montaj metnini dağıtmak ve daha sonra makine koduna çevirmek yerine normalde doğrudan makine kodunu oluşturabilirler.

A dilinin tam bir spesifikasyonu göz önüne alındığında, ilke olarak bazı B dilinde direktiflerini ifade eden bir program yazması o kadar da zor değildir. Ama genellikle belaya giren herkes "B dili" için çok düşük bir seviye seçecektir: Makine kodu veya bu günlerde bytecode: Jython, Java VM tarafından yorumlanan java bayt kodu üreten bir python uygulamasıdır. Java sınıfı hiyerarşilerini yazıp derlemeye gerek yok!

Bu her zaman yapılır.

Her derleyici , C ++ gibi "birincil dili", yorumlanmış diller durumunda makinenin ana derleme diline veya mimariden bağımsız bayt koduna çevirir .

Sanırım bahsettiğin şey bu değil. Muhtemelen C ++ 'ı Java veya Python gibi bir şeye çeviren bir tercüman istiyorsunuz. Bunun amacı ne? En iyi ihtimalle, sonuç, orijinal kaynak ile tam olarak aynı verime sahip olacaktır. (Pratik olarak, çok daha kötü olacak.)

Sadece kodun çevrilmesini istiyorsan, onu anladığın bir dil olarak okuyabilirsen, böyle bir çevirmen istenen etkinin tam tersine sahip olur. Bir miktar şifreli, sezgisel ve okunamayan kodla kalacaksınız.

Bunun nedeni, yalnızca en önemsiz şeylerin doğrudan bir dilden diğerine çevrilmesidir. Genellikle, bir dilde basit olan şey bir başkası için büyük kütüphaneler gerektirir - veya tamamen imkansız olabilir. Bu nedenle:

1. Program önemsiz ise, iyi bir sonuç alabilirsiniz. Ama öyleyse, bu kadar basitse, bir tercüman aracılığıyla çalıştırmanın amacı nedir?
2. Program önemsiz değilse, kod düşük kalitede olacaktır.

Sonunda, iyi kod yazmanın tek yolu gerçekten yazmaktır. Bilgisayarlar basitçe - en azından henüz değil - okunabilirlik, en iyi uygulamalar ve zarif çözümler konularında insanları eşleştiremezler.

Kısacası, buna değmez.

Programlama dilleri için dil tercümanları yok çünkü programlama dilleri inanılmaz derecede karmaşık. Varsayımsal olarak mümkün olsa da, birçok zorluk var.

İlk zorluk sadece dilin kabul edilebilir uygulamalarında. Java ve C ++ gibi iki nesne yönelimli dil arasında dönüştürme yapmak inanılmaz derecede karmaşık ve her ikisi de C tabanlı. Tercümanlık programı, her iki dil için de standart kütüphaneler hakkında mükemmel bilgiye sahip olmalı ve davranıştaki farklılıkları bilmelidir. Muazzam bir sözlük oluşturmanız gerekirdi ve o zaman bile, programlayıcıdan programlayıcıya kadar programlama stillerindeki farklılıklar, bazı değişikliklerin nasıl yapılacağı hakkında tahmin etmek zorunda kalacağı anlamına gelir.

Sözdizimi çevirisini düşürdüğünüzde, ilk dilde bir yapının ikinci dilde bir yapıya nasıl dönüştürüleceğini bulmanız gerekir. C ++ 'daki bir nesneyi Java'daki bir nesneye (nispeten kolay olan) gidecekseniz sorun değil, fakat C ++ yapılarınızla ne yapıyorsunuz? Veya C ++ sınıfları dışındaki fonksiyonlar? Bunun nasıl ele alınacağına karar vermek, başka bir soruna, yani bir blob nesnesinin yaratılmasına neden olabileceğinden, zor olabilir. Kabarcık yeterince yaygın olan bir kamaştırıcıdır.

Bu, sorunların tam bir listesi değildir, ancak bunlar sadece ikidir ve büyük sorunlardır. Profesörlerden biri, birisinin işverenini 80'lerde makine kodundan C'ye kadar yapabileceklerine ikna ettiğini belirtti, ancak o zaman işe yaramadı. Tamamen çalışan birisinin olacağından şüpheliyim.

Derlemenin amacı bilgisayar için yararlı bir şey elde etmektir. yani kaçabilecek bir şey. Neden yazdıklarından daha yüksek bir seviyeye sahip olan bir şeyi derleyelim?

.NET'in stratejisini daha çok seviyorum. Her şeyi ortak bir dilde derleyin. Bu, (N ^ 2) -N çapraz dil derleyicileri oluşturmaya gerek kalmadan iletişim kurabilen dillerin avantajını sağlar.

Örneğin, 10 programlama diliniz varsa, .NET modeli altında sadece 10 derleyici yazmanız gerekir ve hepsi birbirleriyle iletişim kurabilirdi. Bütün olası çapraz dilli derleyicileri yaptıysanız, 90 derleyici yazmanız gerekir. Küçük bir fayda için çok fazladan iş var.