İki sayıyı (veya diğer iyi düzenlenmiş varlıkları) karşılaştırmak istersem, bunu yapardım x < y. Üçünü karşılaştırmak istersem, lise cebir öğrencisi denemeyi önerecektir x < y < z. İçimdeki programcı "hayır, bu geçerli değil, yapmanız gerekiyor x < y && y < z" ifadesiyle cevap verecektir .

Karşılaştığım çoğu dil bu sözdizimini desteklemiyor gibi görünüyor, ki bu matematikte ne kadar yaygın olduğu belli. Python önemli bir istisnadır. JavaScript bir istisnaya benziyor , ancak bu aslında operatörün öncelikli ve örtülü dönüşümlerinin talihsiz bir yan ürünü; node.js dosyasında 1 < 3 < 2değerlendirir true, çünkü gerçekten (1 < 3) < 2 === true < 2 === 1 < 2.

Öyleyse sorum şu: Programlama dillerinde neden x < y < zbeklenen anlambilim ile yaygın olarak bulunmuyor?

Bunlar, zincirlendiklerinde normal ve doğal olarak aşağıdaki gibi soyut bir sözdizimi ağacı oluşturan ikili işleçlerdir:

Değerlendirildiğinde (bunu yapraklardan yaptığınız gibi), bu, bundan bir boole sonucu verir x < y, ardından yapmaya çalışırken bir tür hata alırsınız boolean < z. Bahsettiğiniz x < y < zşekilde çalışabilmek için , derleyicide şöyle bir sözdizimi ağacı üretmek için özel bir durum oluşturmanız gerekir:

Bunu yapmak mümkün değil. Belli ki öyle, ancak bu kadar sık ​​rastlanmayan bir durum için ayrıştırıcıya biraz karmaşıklık ekliyor. Temelde, bazen ikili bir operatör gibi davranan ve bazen üçlü bir operatör gibi davranan, hata yönetimi ve bunun gerektirdiği tüm sonuçları içeren bir sembol yaratıyorsunuz. Bu durum, dil tasarımcılarının mümkünse kaçınmasını tercih ettiği için yanlış giden şeyler için çok fazla alan ekler.

x < y < zProgramlama dillerinde neden yaygın olarak bulunmuyor?

Bu cevapta ben sonuç

• Her ne kadar bu yapı bir dilin gramerinde uygulamak için önemsiz olsa da ve dil kullanıcıları için değer yaratıyorsa,
• Bunun pek çok dilde bulunmamasının temel nedenleri, diğer özelliklere göre öneminden ve dillerin yönetim organlarından birinin isteksizliğinden kaynaklanmaktadır.
  • Potansiyel olarak kırılma değişiklikleri olan kullanıcıları üz
  • Özelliği uygulamak için hareket etmek (örneğin: tembellik).

Giriş

Bu konuda bir Pythonist'in bakış açısından konuşabilirim. Bu özelliği olan bir dilin kullanıcısıyım ve dilin uygulama ayrıntılarını incelemeyi seviyorum. Bunun ötesinde, C ve C ++ gibi dilleri değiştirme sürecine biraz aşina oldum (ISO standardı komite tarafından yönetiliyor ve yıllara göre uyarlanıyor.) Ve hem Ruby hem de Python'un kırılma değişiklikleri gerçekleştirmesini izledim.

Python'un dokümantasyonu ve uygulaması

Dokümanlar / gramerden, karşılaştırma operatörleriyle istediğiniz sayıda ifadeyi zincirleyebileceğimizi görüyoruz:

comparison    ::=  or_expr ( comp_operator or_expr )*
comp_operator ::=  "<" | ">" | "==" | ">=" | "<=" | "!="
                   | "is" ["not"] | ["not"] "in"

ve belgeler ayrıca şunları belirtir:

Karşılaştırmalar keyfi bir şekilde zincirlenebilir, örneğin, x <y <= z, x <y ve y <= z'ye eşittir, ancak y yalnızca bir kez değerlendirilir (ancak her iki durumda da z, x <y bulunduğunda hiç değerlendirilmez) yanlış olmak için).

Mantıksal Eşdeğerlik

Yani

result = (x < y <= z)

mantıksal olan eşdeğer değerlendirilmesi açısından x, yve zdışında, yiki kez değerlendirilir:

x_lessthan_y = (x < y)
if x_lessthan_y:       # z is evaluated contingent on x < y being True
    y_lessthan_z = (y <= z)
    result = y_lessthan_z
else:
    result = x_lessthan_y

Yine fark, y'nin yalnızca bir kez değerlendirildiğidir (x < y <= z).

(Not: Parantezler tamamen gereksiz ve gereksizdir, ancak bunları diğer dillerden gelenlerin yararına kullandım ve yukarıdaki kod oldukça yasal Python'dur.)

Ayrıştırılmış Soyut Sözdizimi Ağacını İnceleme

Python'un zincirleme karşılaştırma işleçlerini nasıl ayrıştırdığını inceleyebiliriz:

>>> import ast
>>> node_obj = ast.parse('"foo" < "bar" <= "baz"')
>>> ast.dump(node_obj)
"Module(body=[Expr(value=Compare(left=Str(s='foo'), ops=[Lt(), LtE()],
 comparators=[Str(s='bar'), Str(s='baz')]))])"

Böylece Python veya başka bir dilin ayrıştırılması için bunun gerçekten zor olmadığını görebiliyoruz.

>>> ast.dump(node_obj, annotate_fields=False)
"Module([Expr(Compare(Str('foo'), [Lt(), LtE()], [Str('bar'), Str('baz')]))])"
>>> ast.dump(ast.parse("'foo' < 'bar' <= 'baz' >= 'quux'"), annotate_fields=False)
"Module([Expr(Compare(Str('foo'), [Lt(), LtE(), GtE()], [Str('bar'), Str('baz'), Str('quux')]))])"

Ve şu anda kabul edilen cevabın aksine, üçlü işlem, ilk ifadeyi alan, belirli karşılaştırmaların yinelemeli ve gerektiği gibi değerlendirmek için ifade düğümlerinin yinelenebilen genel bir karşılaştırma işlemidir. Basit.

Python Üzerine Sonuç

Kişisel olarak anlam semantiklerini oldukça şık buluyorum ve tanıdığım çoğu Python uzmanı, zarar vermeyi düşünmek yerine, özelliğin kullanımını teşvik edecektir - anlambilim, tanınmış belgelerde (yukarıda belirtildiği gibi) oldukça açık bir şekilde belirtilmiştir.

Kodun yazıldığından çok daha fazla okunduğunu unutmayın. Kodun okunabilirliğini artıran değişiklikler, Korku, Belirsizlik ve Şüphe'nin jenerik hayaletlerini artırarak indirgenmemelidir .

Öyleyse neden programlama dillerinde x <y <z yaygın olarak bulunmuyor?

Özelliğin göreceli önemine ve dil valilerinin izin verdiği değişimin göreceli momentum / ataletine odaklanan nedenlerin bir birleşimi olduğunu düşünüyorum.

Diğer daha önemli dil özellikleri için de benzer sorular sorulabilir.

Neden Java veya C # ile birden fazla devralma mevcut değil? Her iki soruya da iyi bir cevap yok . Belki de Bob Martin’in iddia ettiği gibi geliştiriciler çok tembeldi ve verilen sebepler sadece bahaneler. Ve çoklu kalıtım, bilgisayar bilimlerinde oldukça büyük bir konudur. Operatör zincirlemesinden kesinlikle daha önemlidir.

Basit geçici çözümler var

Karşılaştırma operatörü zincirleme zarif, ancak hiçbir şekilde çoklu kalıtım kadar önemli değildir. Ve Java ve C # 'nin bir geçici çözüm olarak arayüzleri olduğu gibi, çoklu dil karşılaştırmaları için her dilin yaptığı gibi - kolayca ve basit bir şekilde çalışan Boolean "ve" s ile yapılan karşılaştırmaları zincirlemelisiniz.

Çoğu dil komite tarafından yönetilir

Çoğu dil, komite tarafından gelişmektedir (Python'daki gibi makul bir Benevolent For Life Diktatörüne sahip olmak yerine). Ve bu konunun ilgili komitelerinden çıkarmak için yeterli destek görmediğini düşünüyorum.

Bu özelliği sunmayan diller değişebilir mi?

Bir dil x < y < zbeklenen matematiksel anlambilim olmadan izin verirse , bu kırıcı bir değişiklik olur. İlk etapta izin vermediyse, eklemek neredeyse önemsiz olurdu.

Değişiklikleri kırmak

Değişen değişiklikler içeren dillerle ilgili: Değişen davranış değişiklikleriyle dilleri güncelleriz - ancak kullanıcılar bundan hoşlanmaz, özellikle de kırılabilecek özellikler kullanıcıları. Bir kullanıcı önceki davranışına güveniyorsa, x < y < zmuhtemelen yüksek sesle protesto ederdi. Ve çoğu dil komite tarafından yönetildiğinden, böyle bir değişikliği desteklemek için çok fazla siyasi irade alacağımızdan şüpheliyim.

Bilgisayar dilleri mümkün olan en küçük birimleri tanımlamaya ve bunları birleştirmenize izin verir. Mümkün olan en küçük birim, boolean bir sonuç veren "x <y" gibi bir şey olacaktır.

Üçlü bir operatör isteyebilirsiniz. Bir örnek, x <y <z olacaktır. Şimdi hangi operatör kombinasyonlarına izin veriyoruz? Açıkçası x> y> z veya x> = y> = z veya x> y> = z veya belki x == y == z girilmelidir. Peki ya x <y> z? x! = y! = z? Sonuncusu ne anlama geliyor, x! = Y ve y! = Z veya üçünün de farklı olduğu nedir?

Şimdi argüman promosyonları: C veya C ++ 'da argümanlar ortak bir türe yükseltilir. Öyleyse, x <y <z'nin anlamı x'in çift olduğu ancak y ve z'nin uzun uzun int olduğu? Üçü de ikiye katlanacak mı? Ya da y bir kez iki katı, diğer zaman ise o kadar uzun mu alınır? C ++ 'da operatörlerden biri veya her ikisi aşırı yüklenirse ne olur?

Ve son olarak, herhangi bir sayıda operata izin veriyor musunuz? Bir <b> c <d> e <f> g gibi?

Her şey çok karmaşıklaşıyor. Şimdi umursamadığım şey, sözdizimi hatası üreten x <y <z. Çünkü faydası, x <y <z'nin gerçekte ne yaptığını bulamayan yeni başlayanlara verilen zararla karşılaştırıldığında küçüktür.

Birçok programlama dilinde, x < yiki operand'ı kabul eden ve tek bir boolean sonucu değerlendiren ikili bir ifadedir . Bu nedenle, eğer birden çok ifadeyi zincirlerseniz true < zve false < zmantıklı olmazsa ve bu ifadeler başarılı bir şekilde değerlendirilirse, yanlış sonuç vermeleri muhtemeldir.

İki parametre alan ve tek bir boolean sonuç üreten bir işlev çağrısıx < y olarak düşünmek çok daha kolaydır . Aslında, bu kadar dil onu kaputun altında uygular. Beste, kolay bir şekilde derlenebilir ve sadece çalışır.

x < y < zSenaryo çok daha karmaşıktır. Şimdi derleyici, aslında, moda zorundadır üç fonksiyonları: x < y, y < zve bu iki değerin sonucu bütün bir tartışmalı kapsamında bir araya anded belirsiz dil grameri .

Neden diğer yoldan yaptılar? Belirgin dilbilgisi olduğu için uygulaması çok daha kolay ve düzeltilmesi çok daha kolay.

Çoğu ana dil (en azından kısmen) nesne yönelimlidir. Temel olarak, OO'nun temel prensibi, nesnelerin diğer nesnelere (veya kendilerine) mesaj göndermesi ve bu mesajın alıcısının , bu mesaja nasıl cevap vereceği üzerinde tam kontrol sahibi olmasıdır.

Şimdi, nasıl bir şey uygulayacağımızı görelim

a < b < c

Kesinlikle soldan sağa (soldan ilişkili) değerlendirebiliriz:

a.__lt__(b).__lt__(c)

Ama şimdi bunun __lt__sonucudur a.__lt__(b), ki bu bir Boolean. Bu hiç mantıklı değil.

Doğru ilişkisel deneyelim:

a.__lt__(b.__lt__(c))

Hayır, bu da mantıklı değil. Şimdi, biz var a < (something that's a Boolean).

Tamam, peki ya sentaktik şeker gibi davranıyorsun. Bir n <karşılaştırma zinciri yapalım, bir n-1 ary mesajı gönderelim. Bu bizim mesaj göndermek, anlamına gelebilir __lt__için a, geçen bve cbağımsız değişkenleri olarak:

a.__lt__(b, c)

Tamam, bu işe yarıyor, ama burada tuhaf bir asimetri var: adaha az olup olmadığına karar veriyor b. Ama bbu daha az olup olmadığına karar vermek almaz ckarar olduğunu bunun yerine, aynı zamanda yapılan a.

Peki ya bunu bir mesajın gönderileceği gibi yorumlamaya ne dersiniz this?

this.__lt__(a, b, c)

En sonunda! Bu işe yarayabilir. Bununla birlikte, nesnelerin sıralanmasının artık nesnenin bir özelliği olmadığı anlamına gelir (örneğin , ne mülkünün ne de özelliğinden aaz olup olmadığı ) bunun yerine bağlamın (yani ) bir özelliğidir .babthis

Bir garip bakış açısına göre garip görünüyor. Ancak, örneğin Haskell'de bu normaldir. Orada birden çok farklı uygulamaları olabilir Ord, örneğin typeclass, ve olsun veya olmasın aen az bir bkapsamda olması umulur typeclass örneği bağlıdır.

Ama aslında, hiç de garip değil ! Hem Java ( Comparator) hem de .NET ( IComparer), örneğin sıralama algoritmalarına kendi sipariş ilişkinizi enjekte etmenizi sağlayan arayüzlere sahiptir. Bu nedenle, siparişin bir türe göre sabit bir şey olmadığını, bunun yerine içeriğe bağlı olduğunu kabul ederler.

Bildiğim kadarıyla, şu anda böyle bir çeviri yapan dil yok. Bir öncelik Ancak, var: Her iki Ioke ve Seph onların tasarımcı "trinary operatörleri" dediği var - olan operatörler sözdizimsel ikili, ancak semantik üçlü. Özellikle,

a = b

olduğu değil mesajı göndererek olarak yorumlanır =için ageçen bargüman olarak değil, olduğu gibi mesaj göndererek ="Mevcut Ground" (benzer ama aynı değil bir konsepte this) geçen ave bargümanlar olarak. Yani, a = byorumlanır

=(a, b)

ve yok

a =(b)

Bu kolayca n-ary operatörleri için genelleştirilebilir.

Bunun gerçekten OO dillerine özgü olduğuna dikkat edin. OO'da, daima bir mesaj gönderisini yorumlamaktan nihayet sorumlu olan tek bir nesneye sahibiz ve gördüğümüz gibi, a < b < changi nesnenin olması gerektiği gibi bir şey için hemen belli değil .

Bu olsa da işlemsel veya işlevsel diller için geçerli değildir. Örneğin, Scheme , Common Lisp ve Clojure'da , <işlev n-ary'dır ve rastgele sayıda argümanla çağrılabilir.

Özellikle, <does not mean "az", daha doğrusu bu işlevler biraz farklı yorumlanır:

(<  a b c d) ; the sequence a, b, c, d is monotonically increasing
(>  a b c d) ; the sequence a, b, c, d is monotonically decreasing
(<= a b c d) ; the sequence a, b, c, d is monotonically non-decreasing
(>= a b c d) ; the sequence a, b, c, d is monotonically non-increasing

Sadece dil tasarımcılarının bunu düşünmediği veya iyi bir fikir olduğunu düşünmediği için. Python, basit bir (neredeyse) LL (1) gramer ile tanımladığınız gibi yapar.

Aşağıdaki C ++ programı, en yüksek seviyeye ayarlanmış uyarılar da dahil olmak üzere, nary clang dan bir dikizlemekle derlenir -Weverything:

#include <iostream>
int main () { std::cout << (1 < 3 < 2) << '\n'; }

Diğer taraftan gnu derleyici paketi bu konuda beni uyarıyor comparisons like 'X<=Y<=Z' do not have their mathematical meaning [-Wparentheses].

Öyleyse benim sorum şudur: x <y <z programlama dillerinde, beklenen anlambilimiyle neden yaygın olarak bulunmuyor?

Cevap basit: Geriye dönük uyumluluk. Doğada eşdeğerini kullanan 1<3<2ve sonucun gerçek olmasını bekleyen çok sayıda kod vardır .

Bir dil tasarımcısının bu "doğru" olma şansından başka bir şansı yoktur ve bu, dilin ilk tasarlandığı zamanın noktasıdır. Başlangıçta "yanlış" olması, diğer programcıların bu "yanlış" davranıştan hızlıca faydalanacakları anlamına gelir. İkinci kez "doğru" olarak almak, bu mevcut kod tabanını kıracak.