Se voglio confrontare due numeri (o altre entità ben ordinate), lo farei con x < y. Se voglio confrontarne tre, lo studente di algebra delle superiori suggerirà di provare x < y < z. Il programmatore in me risponderà quindi con "no, non è valido, devi farlo x < y && y < z".

La maggior parte delle lingue che ho incontrato non sembra supportare questa sintassi, il che è strano dato quanto sia comune in matematica. Python è un'eccezione notevole. JavaScript sembra un'eccezione, ma in realtà è solo uno sfortunato sottoprodotto della precedenza dell'operatore e delle conversioni implicite; in node.js, 1 < 3 < 2valuta true, perché è davvero (1 < 3) < 2 === true < 2 === 1 < 2.

Quindi, la mia domanda è questa: perché x < y < znon è comunemente disponibile nei linguaggi di programmazione, con la semantica prevista?

Si tratta di operatori binari che, se concatenati, producono normalmente e naturalmente un albero di sintassi astratto come:

Quando valutato (cosa che si fa dalle foglie), questo produce un risultato booleano da x < y, quindi si ottiene un errore di tipo nel tentativo di fare boolean < z. Per x < y < zfunzionare come hai discusso, devi creare un caso speciale nel compilatore per produrre un albero di sintassi come:

Non che non sia possibile farlo. Lo è ovviamente, ma aggiunge una certa complessità al parser per un caso che non si presenta così spesso. Stai fondamentalmente creando un simbolo che a volte si comporta come un operatore binario e talvolta si comporta efficacemente come un operatore ternario, con tutte le implicazioni della gestione degli errori e tale che comporta. Ciò aggiunge molto spazio perché le cose vadano male che i progettisti linguistici preferirebbero evitare, se possibile.

Perché x < y < znon è comunemente disponibile nei linguaggi di programmazione?

In questa risposta lo concludo

• sebbene questo costrutto sia banale da implementare nella grammatica di una lingua e crei valore per gli utenti della lingua,
• i motivi principali per cui ciò non esiste nella maggior parte delle lingue è dovuto alla sua importanza rispetto ad altre caratteristiche e alla riluttanza degli organi di governo delle lingue a
  • sconvolgere gli utenti con modifiche potenzialmente violenti
  • per passare all'attuazione della funzione (es. pigrizia).

introduzione

Posso parlare dal punto di vista di un pitonista su questa domanda. Sono un utente di una lingua con questa funzione e mi piace studiare i dettagli di implementazione della lingua. Oltre a ciò, ho una certa familiarità con il processo di modifica di linguaggi come C e C ++ (lo standard ISO è governato da un comitato e aggiornato per anno) e ho visto sia Ruby che Python implementare le ultime modifiche.

Documentazione e implementazione di Python

Dalla documentazione / grammatica, vediamo che possiamo unire qualsiasi numero di espressioni con operatori di confronto:

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

e la documentazione afferma inoltre:

I confronti possono essere concatenati in modo arbitrario, ad es. X <y <= z è equivalente a x <y e y <= z, tranne per il fatto che y viene valutato solo una volta (ma in entrambi i casi z non viene valutato affatto quando viene trovato x <y essere falso).

Equivalenza logica

Così

result = (x < y <= z)

è logicamente equivalente in termini di valutazione di x, ye z, con l'eccezione che yviene valutata per due volte:

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

Ancora una volta, la differenza è che y viene valutato solo una volta con (x < y <= z).

(Nota, le parentesi sono completamente inutili e ridondanti, ma le ho usate per il beneficio di quelle provenienti da altre lingue e il codice sopra è Python abbastanza legale.)

Ispezione dell'albero di sintassi astratto analizzato

Possiamo esaminare come Python analizza gli operatori di confronto concatenati:

>>> 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')]))])"

Quindi possiamo vedere che questo non è davvero difficile da analizzare per Python o qualsiasi altra lingua.

>>> 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')]))])"

E contrariamente alla risposta attualmente accettata, l'operazione ternaria è un'operazione di confronto generica, che accetta la prima espressione, un iterabile di confronti specifici e un iterabile di nodi di espressione da valutare se necessario. Semplice.

Conclusione su Python

Personalmente trovo che la semantica della gamma sia piuttosto elegante e la maggior parte dei professionisti di Python che conosco incoraggerebbero l'uso della funzione, invece di considerarla dannosa: la semantica è chiaramente indicata nella documentazione ben nota (come notato sopra).

Si noti che il codice viene letto molto più di quanto sia scritto. I cambiamenti che migliorano la leggibilità del codice dovrebbero essere abbracciati, non scontati sollevando spettri generici di Paura, Incertezza e Dubbio .

Quindi perché x <y <z non è comunemente disponibile nei linguaggi di programmazione?

Penso che ci sia una confluenza di ragioni incentrate sull'importanza relativa della caratteristica e sul relativo momento / inerzia del cambiamento consentito dai governatori delle lingue.

Domande simili possono essere poste su altre funzionalità linguistiche più importanti

Perché l'ereditarietà multipla non è disponibile in Java o C #? Non c'è una buona risposta qui a nessuna delle due domande . Forse gli sviluppatori erano troppo pigri, come sostiene Bob Martin, e le ragioni fornite sono semplicemente delle scuse. E l'ereditarietà multipla è un argomento piuttosto importante nell'informatica. È certamente più importante del concatenamento dell'operatore.

Esistono soluzioni semplici

Il concatenamento dell'operatore di confronto è elegante, ma non altrettanto importante dell'eredità multipla. E proprio come Java e C # hanno interfacce come soluzione alternativa, così fa ogni linguaggio per confronti multipli: è sufficiente concatenare i confronti con "e" s booleani, che funzionano abbastanza facilmente.

La maggior parte delle lingue sono governate dal comitato

La maggior parte delle lingue si sta evolvendo per comitato (piuttosto che avere un sensibile dittatore benevolo per la vita come ha fatto Python). E suppongo che questo problema non abbia visto abbastanza supporto per farcela dai suoi rispettivi comitati.

Le lingue che non offrono questa funzione possono cambiare?

Se una lingua lo consente x < y < zsenza la semantica matematica prevista, questo cambierebbe radicalmente. Se non lo consentisse in primo luogo, sarebbe quasi banale aggiungere.

Rottura dei cambiamenti

Per quanto riguarda le lingue con i cambiamenti di rotta: aggiorniamo le lingue con i cambiamenti del comportamento di rottura - ma gli utenti tendono a non apprezzare questo, in particolare gli utenti di funzionalità che potrebbero essere interrotte. Se un utente fa affidamento sul precedente comportamento di x < y < z, probabilmente protesterebbe ad alta voce. E poiché la maggior parte delle lingue sono governate da una commissione, dubito che otterremmo molta volontà politica per sostenere un simile cambiamento.

I linguaggi dei computer tentano di definire le unità più piccole possibili e consentono di combinarle. L'unità più piccola possibile sarebbe qualcosa come "x <y" che dà un risultato booleano.

Puoi chiedere un operatore ternario. Un esempio potrebbe essere x <y <z. Ora quali combinazioni di operatori consentiamo? Ovviamente dovrebbe essere consentito x> y> z o x> = y> = z oppure x> y> = z o forse x == y == z. Che dire di x <y> z? x! = y! = z? Cosa significa l'ultimo, x! = Y e y! = Z o che tutti e tre sono diversi?

Ora promozioni di argomenti: in C o C ++, gli argomenti verrebbero promossi in un tipo comune. Quindi cosa significa x <y <z significa di x è doppio ma y e z sono long long int? Tutti e tre promossi per raddoppiare? O y è preso come doppio una volta e tanto più a lungo nell'altra volta? Cosa succede se in C ++ uno o entrambi gli operatori sono sovraccarichi?

E infine, permetti un numero qualsiasi di operandi? Come un <b> c <d> e <f> g?

Bene, tutto diventa molto complicato. Ora ciò che non mi dispiacerebbe è che x <y <z produca un errore di sintassi. Perché l'utilità di esso è piccola rispetto al danno arrecato ai principianti che non riescono a capire cosa faccia effettivamente x <y <z.

In molti linguaggi di programmazione, x < yè un'espressione binaria che accetta due operandi e restituisce un singolo risultato booleano. Pertanto, se concatenare più espressioni true < ze false < znon ha senso e se tali espressioni vengono valutate correttamente, è probabile che producano risultati errati.

È molto più facile pensare x < ya una chiamata di funzione che accetta due parametri e produce un singolo risultato booleano. In effetti, ecco quante lingue lo implementano sotto il cofano. È compostabile, facilmente compilabile e funziona.

Lo x < y < zscenario è molto più complicato. Ora il compilatore, in effetti, deve la moda di tre funzioni: x < y, y < z, e il risultato di questi due valori-a-bit insieme, il tutto nel contesto di un dubbio grammaticale linguaggio ambiguo .

Perché l'hanno fatto nell'altro modo? Perché è una grammatica non ambigua, molto più facile da implementare e molto più facile da correggere.

La maggior parte dei linguaggi tradizionali sono (almeno in parte) orientati agli oggetti. Fondamentalmente, il principio alla base di OO è che gli oggetti inviano messaggi ad altri oggetti (o loro stessi), e il destinatario di quel messaggio ha il controllo completo su come rispondere a quel messaggio.

Ora vediamo come implementeremo qualcosa del genere

a < b < c

Potremmo valutarlo rigorosamente da sinistra a destra (associazione associativa):

a.__lt__(b).__lt__(c)

Ma ora chiediamo __lt__il risultato di a.__lt__(b), che è a Boolean. Non ha senso.

Proviamo associativo:

a.__lt__(b.__lt__(c))

No, neanche questo ha senso. Ora abbiamo a < (something that's a Boolean).

Va bene, che ne dici di trattarlo come zucchero sintattico. Facciamo in modo che una catena di n <confronti invii un messaggio n-1-ary. Questo potrebbe significare, inviamo il messaggio __lt__a a, passando be ccome argomenti:

a.__lt__(b, c)

Va bene, funziona, ma qui c'è una strana asimmetria: aarriva a decidere se è inferiore a b. Ma bnon arrivare a decidere se è inferiore c, invece, che la decisione è anche fatta da a.

Che ne dite di interpretarlo come un messaggio n-ary inviato a this?

this.__lt__(a, b, c)

Finalmente! Questo può funzionare. Significa, tuttavia, che l'ordinamento degli oggetti non è più una proprietà dell'oggetto (ad es. Se aè inferiore a quello che bnon è né una proprietà ané di b) ma piuttosto una proprietà del contesto (cioè this).

Da un punto di vista mainstream che sembra strano. Tuttavia, ad esempio in Haskell, è normale. Possono esserci più implementazioni diverse della Ordtypeclass, ad esempio, e se aè inferiore o meno b, dipende dall'istanza di typeclass che rientra nell'ambito.

Ma in realtà, non è che strano a tutti! Sia Java ( Comparator) che .NET ( IComparer) dispongono di interfacce che consentono di iniettare la propria relazione di ordinamento, ad esempio in algoritmi di ordinamento. Pertanto, riconoscono pienamente che un ordinamento non è qualcosa che è fissato a un tipo, ma dipende dal contesto.

Per quanto ne so, al momento non ci sono lingue che eseguono tale traduzione. Esiste tuttavia una precedenza: sia Ioke che Seph hanno quelli che i loro progettisti chiamano "operatori trinari" - operatori sintatticamente binari, ma semanticamente ternari. In particolare,

a = b

non viene interpretato come l'invio del messaggio =al apassaggio bcome argomento, ma piuttosto come l'invio del messaggio =al passaggio "Terra corrente" (un concetto simile ma non identico this) ae bcome argomenti. Quindi, a = bviene interpretato come

=(a, b)

e non

a =(b)

Questo potrebbe essere facilmente generalizzato agli operatori n-ary.

Nota che questo è davvero peculiare delle lingue OO. In OO, abbiamo sempre un singolo oggetto che è in definitiva responsabile dell'interpretazione di un messaggio inviato e, come abbiamo visto, non è immediatamente ovvio per qualcosa come l' a < b < coggetto che dovrebbe essere.

Ciò non si applica ai linguaggi procedurali o funzionali. Ad esempio, in Scheme , Common Lisp e Clojure , la <funzione è n-ary e può essere chiamata con un numero arbitrario di argomenti.

In particolare, <fa non medio "inferiore", piuttosto queste funzioni vengono interpretati in modo leggermente diverso:

(<  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

È semplicemente perché i progettisti del linguaggio non ci hanno pensato o non hanno pensato che fosse una buona idea. Python lo fa come descritto con una semplice (quasi) LL (1) grammatica.

Il seguente programma C ++ compila nary a peep da clang, anche con avvertenze impostate al livello più alto possibile ( -Weverything):

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

La suite di compilatori gnu, d'altra parte, mi avverte bene che comparisons like 'X<=Y<=Z' do not have their mathematical meaning [-Wparentheses].

Quindi, la mia domanda è questa: perché x <y <z non è comunemente disponibile nei linguaggi di programmazione, con la semantica prevista?

La risposta è semplice: compatibilità all'indietro. Esiste una grande quantità di codice in natura che usa l'equivalente di 1<3<2e si aspetta che il risultato sia vero.

Un designer linguistico ha solo una possibilità per ottenere questo "giusto", ed è questo il momento in cui il linguaggio viene progettato per la prima volta. Inizialmente "sbagliato" significa che gli altri programmatori trarranno piuttosto rapidamente vantaggio da quel comportamento "sbagliato". Farlo "bene" la seconda volta interromperà quella base di codice esistente.