Operatörler, anahtar kelimelerden veya işlevlerden daha net okunabilir mi? [kapalı]

Biraz öznel, ancak bir operatörün geniş ve zor olarak kullanılmasını hangi faktörlerin netleştirdiğini daha net bir şekilde anlamayı umuyorum. Son zamanlarda dil tasarımlarını göz önünde bulunduruyorum ve her zaman geri döndüğüm bir konu, dilde bazı önemli işlemleri ne zaman bir operatör haline getireceğimiz ve ne zaman bir anahtar kelime veya işlev kullanacağım.

Özel işleçlerin oluşturulması kolay olduğundan ve genellikle yeni bir veri türü üzerinde kullanılmak üzere birkaç işleçle paketleneceğinden Haskell bunun için biraz kötü şöhretlidir. Örneğin Parsec kütüphanesi, ayrıştırıcıları bir araya getirmek için bir sürü operatörle birlikte gelir, mücevherler gibi >.ve .> şu anda ne demek istediklerini bile hatırlayamıyorum, ama ne olduğunu ezberledikten sonra çok kolay çalıştıklarını hatırlıyorum aslında demek istedikleri. Böyle bir işlev çağrısı leftCompose(parser1, parser2)daha iyi olur muydu? Kesinlikle daha ayrıntılı, ancak bazı yönlerden daha net.

C benzeri dillerdeki operatör aşırı yüklemeleri benzer bir konudur, ancak +alışılmadık operatörlerin anlamını olağandışı yeni anlamlarla aşırı yüklemenin ek sorunu ile sınırlıdır.

Herhangi bir yeni dilde, bu oldukça zor bir konu gibi görünecektir. Örneğin F # 'da döküm, C # stili döküm sözdizimi veya ayrıntılı VB stili yerine matematiksel olarak türetilmiş bir tür döküm operatörü kullanır. C #: (int32) xVB: CType(x, int32)F #:x :> int32

Teoride, yeni bir dilde en yerleşik işlevsellik için operatörler bulunabilir. Yerine defya decya vardeğişken bildiriminde, neden olmasın için ! nameveya @ nameveya benzer bir şey. Kesinlikle bildirimi ve ardından bağlamayı kısaltır: @x := 5yerine declare x = 5veya let x = 5 Çoğu kod çok sayıda değişken tanımı gerektirecektir, neden olmasın?

Bir operatör ne zaman açık ve yararlıdır ve ne zaman gizlidir?

genel bir dil tasarımı açısından işlevler ve operatörler arasında herhangi bir fark olması gerekmez. Fonksiyonlar herhangi (veya değişken değişken) önek işlemleri olarak tanımlanabilir. Ve anahtar kelimeler yalnızca ayrılmış adları olan işlevler veya işleçler olarak görülebilir (bu, dilbilgisi tasarlamada yararlıdır).

Tüm bu karar nihayetinde gösterimin nasıl okunmasını istediğinizi ve söylediğiniz gibi sübjektif olduğunu, ancak herkesin bildiği gibi matematik için olağan infix operatörlerini kullanmak gibi açık bir rasyonalizasyonlar yapabilir.

Son olarak, Dijkstra kullandığı matematiksel notasyonların ilginç bir gerekçesini yazdı;

Bana göre, bir operatör artık kod satırını yüksek sesle veya kafanızda okuyamadığında ve mantıklı hale getiremediğinizde kullanışlı olmayı bırakıyor.

Örneğin, declare x = 5gibi okur "declare x equals 5"ya let x = 5kadar okunabilir "let x equal 5"ancak okuma, yüksek sesle okuduğunda çok anlaşılabilir bir @x := 5şekilde okunduğunda "at x colon equals 5"(veya "at x is defined to be 5"bir matematikçi iseniz) hiç mantıklı değil.

Bu yüzden bana göre, kod yüksek sesle okunabiliyorsa ve dile aşina olmayan makul derecede zeki bir kişi tarafından anlaşılabiliyorsa, bir işleç kullanın, ancak değilse işlev adlarını kullanın.

Bir operatör bilindiği zaman açık ve kullanışlıdır. Ve bu muhtemelen aşırı yük operatörlerinin, sadece seçilen operatör önceden kurulmuş bir uygulama olarak yeterli (form, öncelik ve ilişkilendirilebilirlik gibi) olduğunda yapılması gerektiği anlamına gelir.

Ama biraz daha kazmak, iki yönü var.

Sözdizimi (işlev çağrısı sözdizimi için önek yerine işleç için infix) ve adlandırma.

Sözdizimi için, ön ekin önekten yeterince açık olduğu başka bir durum daha vardır: çağrıların tanıdık gelmesini gerektirebilir: çağrılar zincirlendiğinde ve iç içe yerleştirildiğinde.

Veya a * b + c * d + e * file karşılaştır (her ikisi de infix sürümü ile aynı durumda ayrıştırılabilir). Aslında bunun yerine uzun arada bunlardan bir öncekinin terimlerini ayırmak gözlerimde daha okunabilir kılmak (ancak önek sözdizimi için gerekli olmayan öncelik kuralları hatırlamak zorunda). Eğer şeyleri bu şekilde birleştirmeniz gerekiyorsa, uzun vadeli fayda yolu öğrenme maliyetine değecektir. Ayrıca, operatörlerinizi sembol kullanmak yerine harflerle adlandırsanız bile bu avantajı korursunuz.+(+(*(a, b), *(c, d)), *(e, f))+ + * a b * c d * e f+

Operatörlerin isimlendirilmesinde, yerleşik semboller veya açık isimden başka bir şey kullanmanın birkaç avantajı görüyorum. Evet, daha kısa olabilirler, ancak gerçekten şifrelenirler ve onları tanımak için iyi bir nedeniniz yoksa hızlı bir şekilde unutulurlar.

Bir üçüncü dil tasarımı POV alırsanız, operatör kümesinin açık veya kapalı olması gerekiyorsa - operatör ekleyebilir veya ekleyemezsiniz - ve öncelik ve ilişkilendirilebilirliğin kullanıcı tarafından belirlenebilir olması gerekip gerekmediğidir. İlk kullanımım dikkatli olmak ve kullanıcı tarafından belirlenebilir öncelik ve ilişkilendirilebilirlik sağlamak değil, açık bir sete sahip olmaya daha açık olacağım (operatör aşırı yüklemesini kullanma baskısını artıracak, ancak kötü bir tane kullanmak için olanı azaltacaktır) yalnızca yararlı olduğu yerde infix sözdiziminden yararlanmak için).

Sembol olarak operatörler, sezgisel olarak anlamlı olduklarında faydalıdır. +ve -açıkça toplama ve çıkarma, örneğin, bu yüzden hemen hemen her dil onları operatör olarak kullanır. Karşılaştırma ile aynı ( <ve >ilkokulda öğretilir ve <=ve >=standart klavyede hiçbir Altı çizili karşılaştırma tuşları var olduğunu anladığınızda temel karşılaştırmaların sezgisel uzantılarıdır.)

*ve /hemen daha az açıktır, ancak evrensel olarak kullanılırlar ve +ve -tuşlarının yanındaki sayısal tuş takımındaki konumları bağlam sağlamaya yardımcı olur. C'ler <<ve >>aynı kategoridedir: sola kaydırma ve sağa kaydırma ne olduğunu anladığınızda, okların arkasındaki anımsatıcıları anlamak çok zor değildir.

Sonra gerçekten garip olanlardan bazılarına gelirsiniz, C kodunu okunamayan operatör çorbasına dönüştürebilirsiniz. (Burada C'yi seçmek, çünkü sözdizimi hemen hemen herkesin aşina olduğu, C ile veya alt dillerle çalışarak çok operatör ağır bir örnektir.) Örneğin, %operatör. Herkes bunun ne olduğunu biliyor: yüzde işareti ... değil mi? C hariç, 100'e bölünmesi ile hiçbir ilgisi yoktur; bu modül operatörüdür. Bu anımsatıcı olarak sıfır mantıklı, ama işte burada!

Daha da kötüsü, boole operatörleri. &Bir şekilde ve mantıklı orada iki farklı olduğunu hariç &rağmen sadece bir tanesi şimdiye kadar, iki farklı şeyler yapmak operatörler ve her ikisi bunlardan biri geçerlidir her durumda sözdizimsel geçerlidir aslında mantıklı herhangi bir durumda. Bu sadece karışıklık için bir reçete! Veya , xor ve değil onlar mnemonically yararlı semboller kullanmayın ve ya tutarlı değildir beri operatörler, çok daha kötüdür. (Hayır çift xor operatör ve bitsel mantıklı ve değil iki farklı semboller yerine bir sembol ve bir iki büklüm olmuş bir sürümünü kullanın.)

Ve sadece daha da kötüleştirmek için, &ve *operatörler tamamen farklı şeyler için yeniden kullanılır, bu da dili hem insanlar hem de derleyiciler için ayrıştırmayı zorlaştırır. (Bu ne anlama A * Bgeliyor? Tamamen bağlama bağlıdır: Abir tür mü değişken mi?)

Kuşkusuz, Dennis Ritchie ile hiç konuşmadım ve ona dilde yaptığı tasarım kararlarını sormadım, ancak çoğu, operatörlerin arkasındaki felsefenin "semboller uğruna semboller" olduğunu hissettiriyor.

Bunu, C ile aynı operatörlere sahip olan ancak onları temsil etmede farklı bir felsefeye sahip olan Pascal ile karşılaştırın: operatörler sezgisel ve okunması kolay olmalıdır. Aritmetik işleçler aynıdır. Modül operatörü kelimedir mod, çünkü klavyede açıkça "modül" anlamına gelen hiçbir sembol yoktur. Mantıksal operatörleri and, or, xorve notve yalnızca biri yoktur; derleyici, booleans veya sayılarda çalışıp çalışmadığınıza bağlı olarak boolean veya bitwise sürümüne ihtiyacınız olup olmadığını bilir ve tüm hata sınıflarını ortadan kaldırır. Bu , özellikle sözdizimi vurgulamalı modern bir düzenleyicide Pascal kodunun anlaşılmasını çok kolaylaştırır, böylece operatörler ve anahtar kelimeler görsel olarak tanımlayıcılardan farklıdır.

Bence operatörler işlevleri tanıdık, matematiksel amaçlarını yakından yansıttığında çok daha okunabilir. Örneğin, +, -, vb. Standart operatörler toplama ve çıkarma işlemlerinde Toplama veya Çıkarma'dan daha okunabilir. Operatörün davranışı açıkça tanımlanmalıdır. Örneğin, liste birleştirme için + anlamının aşırı yüklenmesine tahammül edebilirim. İdeal olarak, operasyonun mutasyona uğramak yerine bir değer döndürerek yan etkileri olmazdı.

Katlama gibi işlevler için kısayol operatörleriyle uğraştım. Açıkçası onlarla daha fazla deneyim bunu kolaylaştıracaktır, ancak foldRightdaha okunabilir buluyorum /:.

Operatörlerle ilgili sorun, bunların yerine kullanılabilecek sensical (!) Yöntem adlarının sayısıyla karşılaştırıldığında çok az sayıda olmasıdır. Bir yan etki, kullanıcı tanımlı operatörlerin çok fazla aşırı yüklenme eğilimi göstermesidir.

Elbette, satırın C = A * x + b * cyazılması ve okunması daha kolaydır C = A.multiplyVector(x).addVector(b.multiplyScalar(c)).

Ya da kafanızdaki tüm operatörlerin aşırı yüklenmiş sürümlerine sahipseniz yazmak kesinlikle daha kolaydır. Ve sondan ikinci hatayı düzeltirken daha sonra okuyabilirsiniz.

Şimdi, orada kodlanacak olan çoğu kod için, sorun değil. “Proje tüm testleri geçiyor ve çalışıyor” - birçoğu için isteyebileceğimiz bir yazılım parçası.

Ancak kritik alanlara giren yazılımlar yaparken işler farklı şekilde işler. Güvenlik açısından kritik şeyler. Güvenlik. Uçakları havada tutan veya nükleer tesislerin çalışmasını sağlayan yazılım. Veya son derece gizli e-postalarınızı şifreleyen yazılımlar.

Denetim kodu konusunda uzmanlaşmış güvenlik uzmanları için bu bir kabus olabilir. Çok sayıda kullanıcı tanımlı işleç ve operatör aşırı yüklemesinin karışımı, onları en sonunda hangi kodun çalıştırılacağını bulmakta zorlandıkları hoş olmayan durumlarda bırakabilir.

Yani, orijinal soruda belirtildiği gibi, bu oldukça öznel bir konudur. Operatörlerin nasıl kullanılması gerektiğine dair birçok öneri tam anlamıyla mantıklı gelse de, sadece birkaç tanesinin kombinasyonu uzun vadede çok fazla sorun yaratabilir.

En aşırı örnek APL olduğunu varsayalım aşağıdaki program "yaşam oyunu" dir:

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

Ve eğer referans kılavuzu ile birkaç gün harcamadan bunun ne anlama geldiğini çözebilirseniz, size iyi şanslar!

Sorun şu ki, neredeyse herkesin sezgisel olarak anladığı bir dizi sembolünüz var: +,-,*,/,%,=,==,&

ve anlaşılmadan önce biraz açıklama gerektiren geri kalanlar ve genellikle belirli bir dile özgüdür. Örneğin, bir dizinin hangi üyesini, [], () ve hatta "." İstediğinizi belirten belirgin bir sembol yoktur. kullanılmış, ancak aynı şekilde kolayca kullanabileceğiniz belirgin bir anahtar kelime yoktur, bu nedenle operatörlerin mantıklı kullanımı için bir durum söz konusudur. Ama çok fazla değil.