Perché gli operatori definiti dall'utente non sono più comuni?

Una caratteristica che mi manca nei linguaggi funzionali è l'idea che gli operatori siano solo funzioni, quindi aggiungere un operatore personalizzato è spesso semplice come aggiungere una funzione. Molti linguaggi procedurali consentono sovraccarichi degli operatori, quindi in un certo senso gli operatori sono ancora funzioni (questo è molto vero in D dove l'operatore viene passato come stringa in un parametro modello).

Sembra che laddove sia consentito il sovraccarico degli operatori, spesso sia banale aggiungere altri operatori personalizzati. Ho trovato questo post sul blog , in cui si afferma che gli operatori personalizzati non funzionano bene con la notazione infissa a causa delle regole di precedenza, ma l'autore offre diverse soluzioni a questo problema.

Mi sono guardato intorno e non sono riuscito a trovare linguaggi procedurali che supportino operatori personalizzati nella lingua. Ci sono hack (come le macro in C ++), ma non è lo stesso del supporto del linguaggio.

Poiché questa funzionalità è piuttosto banale da implementare, perché non è più comune?

Capisco che può portare a qualche brutto codice, ma che in passato non ha impedito ai progettisti di linguaggi di aggiungere funzioni utili che possono essere facilmente abusate (macro, operatore ternario, puntatori non sicuri).

Casi d'uso reali:

• Implementa operatori mancanti (ad es. Lua non ha operatori bit a bit)
• Mimic D's ~(concatenazione di array)
• DSL
• Utilizzare |come zucchero di sintassi tipo pipe Unix (usando coroutine / generatori)

Sono anche interessato a lingue che fanno consentire agli operatori personalizzati, ma io sono più interessato a perché essa è stata esclusa. Ho pensato di creare un linguaggio di scripting per aggiungere operatori definiti dall'utente, ma mi sono fermato quando mi sono reso conto di non averlo visto da nessuna parte, quindi probabilmente c'è una buona ragione per cui i progettisti di lingue più intelligenti di me non l'hanno permesso.

Esistono due scuole di pensiero diametralmente opposte nella progettazione del linguaggio di programmazione. Uno è che i programmatori scrivono un codice migliore con meno restrizioni e l'altro è che scrivono un codice migliore con più restrizioni. A mio avviso, la realtà è che i programmatori di buona esperienza prosperano con meno restrizioni, ma tali restrizioni possono avvantaggiare la qualità del codice dei principianti.

Gli operatori definiti dall'utente possono creare codice molto elegante in mani esperte e un codice assolutamente terribile da parte di un principiante. Quindi, se la tua lingua li include o meno dipende dalla scuola di pensiero del tuo progettista di lingue.

Con una scelta tra array concatenati con ~ o con "myArray.Concat (secondArray)", probabilmente preferirei quest'ultimo. Perché? Perché ~ è un personaggio completamente insignificante che ha solo il suo significato - quello della concatenazione di array - dato nello specifico progetto in cui è stato scritto.

Fondamentalmente, come hai detto, gli operatori non sono diversi dai metodi. Ma mentre ai metodi possono essere dati nomi leggibili e comprensibili che si aggiungono alla comprensione del flusso di codice, gli operatori sono opachi e situazionali.

Questo è il motivo per cui non mi piace nemmeno l' .operatore di PHP (concatenazione di stringhe) o la maggior parte degli operatori in Haskell o OCaml, anche se in questo caso stanno emergendo alcuni standard universalmente accettati per i linguaggi funzionali.

Poiché questa funzionalità è piuttosto banale da implementare, perché non è più comune?

La tua premessa è sbagliata. E ' non è “abbastanza banale da attuare”. In realtà, porta un sacco di problemi.

Diamo un'occhiata alle "soluzioni" suggerite nel post:

• No la precedenza . L'autore stesso dice "Non usare le regole di precedenza semplicemente non è un'opzione".
• Analisi semantica consapevole . Come dice l'articolo, questo richiederebbe al compilatore di avere molte conoscenze semantiche. L'articolo in realtà non offre una soluzione per questo e lascia che te lo dica, questo semplicemente non è banale. I compilatori sono progettati come un compromesso tra potenza e complessità. In particolare, l'autore menziona una fase di pre-analisi per raccogliere le informazioni pertinenti, ma la pre-analisi è inefficiente e i compilatori si impegnano molto per ridurre al minimo i passaggi di analisi.
• Nessun operatore infix personalizzato . Bene, questa non è una soluzione.
• Soluzione ibrida . Questa soluzione comporta molti (ma non tutti) gli svantaggi dell'analisi consapevole semantica. In particolare, poiché il compilatore deve trattare i token sconosciuti come potenzialmente rappresentanti operatori personalizzati, spesso non può produrre messaggi di errore significativi. Potrebbe anche essere necessario che la definizione di detto operatore proceda all'analisi (per raccogliere informazioni sul tipo, ecc.), Richiedendo ancora una volta un ulteriore passaggio di analisi.

Tutto sommato, questa è una funzione costosa da implementare, sia in termini di complessità del parser che in termini di prestazioni, e non è chiaro che porterebbe molti vantaggi. Certo, ci sono alcuni vantaggi nella capacità di definire nuovi operatori ma anche quelli sono controversi (basta guardare le altre risposte sostenendo che avere nuovi operatori non è una buona cosa).

Ignoriamo per ora l'intero argomento "Gli operatori vengono abusati di danneggiare la leggibilità" e concentriamoci sulle implicazioni del design del linguaggio.

Gli operatori di Infix hanno più problemi delle semplici regole di precedenza (sebbene sia schietto, il collegamento a cui fai riferimento banalizza l'impatto di quella decisione di progettazione). Uno è la risoluzione dei conflitti: cosa succede quando si definisce a.operator+(b)e b.operator+(a)? Preferire l'uno rispetto all'altro porta a infrangere la proprietà commutativa attesa di quell'operatore. Lanciare un errore può portare alla rottura di moduli che altrimenti funzionerebbero una volta insieme. Cosa succede quando inizi a lanciare tipi derivati ​​nel mix?

Il fatto è che gli operatori non sono solo funzioni. Le funzioni sono indipendenti o appartengono alla loro classe, che fornisce una chiara preferenza su quale parametro (se presente) possiede l'invio polimorfico.

E questo ignora i vari problemi di imballaggio e risoluzione che sorgono dagli operatori. Il motivo per cui i progettisti delle lingue (in linea di massima) limitano la definizione dell'operatore infix è perché crea un mucchio di problemi per la lingua fornendo al contempo vantaggi discutibili.

E, francamente, perché sono non banale da implementare.

Penso che rimarrai sorpreso dalla frequenza con cui i sovraccarichi dell'operatore vengono implementati in qualche modo. Ma non sono comunemente usati in molte comunità.

Perché usare ~ per concatenare un array? Perché non usare << come fa Ruby ? Perché i programmatori con cui lavori non sono probabilmente programmatori Ruby. O programmatori D. Quindi cosa fanno quando trovano il tuo codice? Devono cercare il significato del simbolo.

Lavoravo con un ottimo sviluppatore C # che aveva anche un gusto per i linguaggi funzionali. All'improvviso, ha iniziato a introdurre monadi in C # mediante metodi di estensione e usando la terminologia standard delle monadi. Nessuno poteva contestare che parte del suo codice fosse più teso e ancora più leggibile una volta che sapessi cosa significasse, ma ciò significava che tutti dovevano imparare la terminologia della monade prima che il codice avesse senso .

Abbastanza giusto, pensi? Era solo una piccola squadra. Personalmente, non sono d'accordo. Ogni nuovo sviluppatore era destinato a essere confuso da questa terminologia. Non abbiamo abbastanza problemi nell'apprendimento di un nuovo dominio?

D'altra parte, userò felicemente l' ??operatore in C # perché mi aspetto che altri sviluppatori C # sappiano di cosa si tratta, ma non lo sovraccaricherei in un linguaggio che non lo supportava per impostazione predefinita.

Mi vengono in mente alcuni motivi:

• Non sono banali da implementare : consentire a operatori personalizzati arbitrari di rendere il compilatore molto più complesso, soprattutto se si consentono regole di precedenza, fissità e arity definite dall'utente. Se la semplicità è una virtù, il sovraccarico dell'operatore ti sta allontanando da un buon design del linguaggio.
• Vengono abusati , soprattutto dai programmatori che pensano che sia "bello" ridefinire gli operatori e iniziare a ridefinirli per ogni tipo di classe personalizzata. In poco tempo, il tuo codice è disseminato di un carico di simboli personalizzati che nessun altro può leggere o comprendere perché gli operatori non seguono le regole convenzionali ben comprese. Non compro l'argomento "DSL", a meno che il tuo DSL non sia un sottoinsieme della matematica :-)
• Essi fanno male leggibilità e la manutenibilità - se gli operatori vengono sovrascritte con regolarità, può diventare difficile da individuare quando si utilizza questo strumento, e programmatori sono costretti a chiedere continuamente se stessi ciò che un operatore sta facendo. È molto meglio dare nomi di funzioni significative. Digitare qualche carattere in più è economico, i problemi di manutenzione a lungo termine sono costosi.
• Possono infrangere le aspettative di prestazioni implicite . Ad esempio, normalmente mi aspetto la ricerca di un elemento in un array O(1). Ma con il sovraccarico dell'operatore, someobject[i]potrebbe facilmente essere O(n)un'operazione a seconda dell'implementazione dell'operatore di indicizzazione.

In realtà, ci sono pochissimi casi in cui il sovraccarico dell'operatore ha usi giustificati rispetto al semplice utilizzo di funzioni regolari. Un esempio legittimo potrebbe essere la progettazione di una classe numerica complessa per l'uso da parte di matematici, che comprendono i modi ben compresi in cui gli operatori matematici sono definiti per numeri complessi. Ma questo non è davvero un caso molto comune.

Alcuni casi interessanti da considerare:

• Lisps : in generale non distingue affatto tra operatori e funzioni - +è solo una funzione regolare. Puoi definire le funzioni come preferisci (in genere esiste un modo per definirle in spazi dei nomi separati per evitare conflitti con il built-in +), inclusi gli operatori. Ma c'è una tendenza culturale a usare nomi di funzioni significative, quindi questo non viene abusato molto. Inoltre, nel prefisso Lisp la notazione tende ad essere utilizzata esclusivamente, quindi c'è meno valore nello "zucchero sintattico" che i sovraccarichi dell'operatore forniscono.
• Java : non consente il sovraccarico dell'operatore. Questo a volte è fastidioso (per cose come il caso del numero complesso) ma in media è probabilmente la giusta decisione di progettazione per Java che è intesa come una lingua OOP semplice e generica. Il codice Java è in realtà abbastanza facile da mantenere per gli sviluppatori con competenze medio-basse grazie a questa semplicità.
• Il C ++ ha un sovraccarico dell'operatore molto sofisticato. A volte questo viene abusato ( cout << "Hello World!"chiunque?) Ma l'approccio ha senso dato il posizionamento di C ++ come linguaggio complesso che consente una programmazione di alto livello pur consentendo di avvicinarsi molto al metal per le prestazioni, quindi è possibile ad esempio scrivere una classe numerica complessa che si comporta esattamente come vuoi senza compromettere le prestazioni. Resta inteso che è tua responsabilità se ti spari a un piede.

Poiché questa funzionalità è piuttosto banale da implementare, perché non è più comune?

Non è banale da implementare (se non banalmente implementato). Inoltre, non ti ottiene molto, anche se implementato idealmente: i guadagni di leggibilità dalla terseness sono compensati dalle perdite di leggibilità dovute a familiarità e opacità. In breve, non è comune perché di solito non vale il tempo degli sviluppatori o degli utenti.

Detto questo, posso pensare a tre lingue che lo fanno e lo fanno in diversi modi:

• Racket, uno schema, quando non è tutto S-expression-y consente e si aspetta che tu scriva ciò che equivale al parser per qualsiasi sintassi che desideri estendere (e fornisce hook utili per rendere trattabile).
• Haskell, un linguaggio di programmazione puramente funzionale, consente di definire qualsiasi operatore costituito esclusivamente da punteggiatura e consente di fornire un livello di fissità (10 disponibili) e un'associatività. Gli operatori ternari ecc. Possono essere creati da operatori binari e funzioni di ordine superiore.
• Agda, un linguaggio di programmazione tipizzato in modo dipendente, è estremamente flessibile con gli operatori ( qui la carta ) che consente a if-then e if-then-else di essere definiti come operatori nello stesso programma, ma il suo lexer, parser e valutatore sono tutti fortemente accoppiati di conseguenza.

Uno dei motivi principali per cui gli operatori personalizzati sono scoraggiati è perché ogni operatore può significare / fare qualsiasi cosa.

Ad esempio il cstreamsovraccarico di spostamento a sinistra molto criticato.

Quando una lingua consente sovraccarichi dell'operatore, generalmente si incoraggia a mantenere il comportamento dell'operatore simile al comportamento di base per evitare confusione.

Anche gli operatori definiti dall'utente rendono l'analisi molto più difficile, specialmente quando ci sono anche regole di preferenza personalizzate.

Non utilizziamo operatori definiti dall'utente per lo stesso motivo per cui non usiamo parole definite dall'utente. Nessuno chiamerebbe la loro funzione "sworp". L'unico modo per trasmettere il tuo pensiero ad altre persone è usare un linguaggio condiviso. Ciò significa che sia le parole che i segni (operatori) devono essere conosciuti dalla società per la quale stai scrivendo il tuo codice.

Pertanto gli operatori che vedi in uso nei linguaggi di programmazione sono quelli che ci hanno insegnato a scuola (aritmetica) o quelli che sono stati stabiliti nella comunità di programmazione, come dicono gli operatori booleani.

Per quanto riguarda le lingue che supportano tale sovraccarico: Scala lo fa, in realtà in modo molto più pulito e migliore può C ++. La maggior parte dei caratteri può essere utilizzata nei nomi delle funzioni, quindi è possibile definire operatori come! + * = ++, se lo si desidera. Esiste un supporto integrato per infix (per tutte le funzioni che accettano un argomento). Penso che anche tu possa definire l'associatività di tali funzioni. Non puoi tuttavia definire la precedenza (solo con brutti trucchi, vedi qui ).

Una cosa che non è stata ancora menzionata è il caso di Smalltalk, in cui tutto (inclusi gli operatori) è un messaggio inviato. "Operatori" come +, |e così via, sono in realtà metodi unari.

Tutti i metodi possono essere sovrascritti, quindi a + bsignifica aggiunta di numeri interi se ae bsono entrambi numeri interi e significa aggiunta di vettore se sono entrambi OrderedCollections.

Non ci sono regole di precedenza, poiché si tratta solo di chiamate al metodo. Ciò ha un'importante implicazione per la notazione matematica standard: 3 + 4 * 5significa (3 + 4) * 5, no 3 + (4 * 5).

(Questo è un grosso ostacolo per i neofiti di Smalltalk. La violazione delle regole matematiche rimuove un caso speciale, in modo che tutta la valutazione del codice proceda uniformemente da sinistra a destra, rendendo il linguaggio molto più semplice.)

Stai combattendo contro due cose qui:

1. Perché gli operatori esistono in primo luogo nelle lingue?
2. Qual è la virtù degli operatori rispetto a funzioni / metodi?

Nella maggior parte delle lingue, gli operatori non sono realmente implementati come semplici funzioni. Potrebbero avere alcune impalcature di funzioni, ma il compilatore / runtime è esplicitamente consapevole del loro significato semantico e di come tradurli in modo efficiente nel codice macchina. Questo è molto più vero anche rispetto alle funzioni integrate (motivo per cui la maggior parte delle implementazioni non include anche tutte le spese generali di chiamata delle funzioni nella loro implementazione). La maggior parte degli operatori sono astrazioni di livello superiore su istruzioni primitive presenti nelle CPU (motivo per cui la maggior parte degli operatori è aritmetica, booleana o bit a bit). Potresti modellarle come funzioni "speciali" (chiamale "primitive" o "builtin" o "native" o altro), ma per fare ciò richiede genericamente una serie molto solida di semantiche per definire tali funzioni speciali. L'alternativa è avere operatori integrati che sembrano semanticamente degli operatori definiti dall'utente, ma che altrimenti invocano percorsi speciali nel compilatore. Ciò è in contrasto con la risposta alla seconda domanda ...

A parte il problema della traduzione automatica che ho menzionato sopra, a livello sintattico gli operatori non sono molto diversi dalle funzioni. Stanno distinguendo le caratteristiche che tendono ad essere concise e simboliche, il che suggerisce una significativa caratteristica aggiuntiva che devono essere utili: devono avere ampiamente compreso significato / semantica per gli sviluppatori. I simboli brevi non trasmettono molto significato a meno che non sia abbreviazione di una serie di semantiche che sono già state comprese. Ciò rende gli operatori definiti dall'utente intrinsecamente inutili, poiché per loro stessa natura non sono così ampiamente compresi. Hanno senso tanto quanto i nomi di una o due lettere.

I sovraccarichi dell'operatore di C ++ forniscono terreno fertile per esaminarlo. La maggior parte degli "abusi" del sovraccarico dell'operatore si presenta sotto forma di sovraccarichi che rompono parte del contratto semantico che è ampiamente compreso (un esempio classico è un sovraccarico dell'operatore + tale che a + b! = B + a, o dove + modifica uno dei suoi operandi).

Se guardi Smalltalk, che consente il sovraccarico degli operatori e gli operatori definiti dall'utente, puoi vedere come una lingua potrebbe usarlo e quanto sarebbe utile. In Smalltalk, gli operatori sono semplicemente metodi con proprietà sintattiche diverse (vale a dire, sono codificati come binari infix). Il linguaggio utilizza "metodi primitivi" per operatori e metodi speciali accelerati. Si scopre che pochi se vengono creati operatori definiti dall'utente, e quando lo sono, tendono a non abituarsi tanto quanto probabilmente l'autore ha previsto che fossero utilizzati. Anche l'equivalente di un sovraccarico dell'operatore è raro, poiché è soprattutto una perdita netta definire una nuova funzione come operatore anziché come metodo, poiché quest'ultima consente un'espressione della semantica della funzione.

Ho sempre trovato che i sovraccarichi dell'operatore in C ++ sono una scorciatoia conveniente per un team di sviluppatori singoli, ma che causa confusione a lungo termine semplicemente perché le chiamate al metodo vengono "nascoste" in un modo non facile per strumenti come doxygen da separare e le persone devono comprendere i modi di dire per usarli correttamente.

A volte è molto più difficile dare un senso a quello che ti aspetteresti, anche. Una volta, in un grande progetto C ++ multipiattaforma, ho deciso che sarebbe stata una buona idea normalizzare il modo in cui i percorsi sono stati creati creando un FilePathoggetto (simile Fileall'oggetto Java ), che avrebbe avuto l'operatore / usato per concatenare un altro parte del percorso (in modo da poter fare qualcosa di simile File::getHomeDir()/"foo"/"bar"e farebbe la cosa giusta su tutte le nostre piattaforme supportate). Tutti quelli che l'hanno visto direbbero essenzialmente: "Che diavolo? Divisione delle corde? ... Oh, è carino, ma non mi fido che faccia la cosa giusta."

Allo stesso modo, ci sono molti casi nella programmazione grafica o in altre aree in cui la matematica vettoriale / matrice si verifica molto in cui è allettante fare cose come Matrix * Matrix, Vector * Vector (punto), Vector% Vector (croce), Matrix * Vector ( matrice di trasformazione), Matrix ^ Vector (trasformazione di matrice in casi speciali ignorando la coordinata omogenea - utile per le normali di superficie) e così via, ma mentre fa risparmiare un po 'di tempo di analisi per la persona che ha scritto la libreria matematica vettoriale, finisce solo confondere la questione più per gli altri. Non ne vale la pena.

I sovraccarichi dell'operatore sono una cattiva idea per lo stesso motivo per cui i sovraccarichi del metodo sono una cattiva idea: lo stesso simbolo sullo schermo avrebbe significati diversi a seconda di ciò che lo circonda. Questo rende più difficile la lettura casuale.

Poiché la leggibilità è un aspetto critico della manutenibilità, è necessario evitare sempre il sovraccarico (tranne in alcuni casi molto speciali). È molto meglio che ogni simbolo (operatore o identificatore alfanumerico) abbia un significato unico che si distingue da solo.

Per illustrare: quando si legge un codice sconosciuto, se si incontra un nuovo identificatore alfanumerico che non si conosce, almeno si ha il vantaggio di sapere che non lo si conosce. Puoi quindi andare a cercarlo. Se, tuttavia, vedi un identificatore o un operatore comune di cui conosci il significato, avrai molte meno probabilità di notare che in realtà è stato sovraccaricato per avere un significato completamente diverso. Per sapere quali operatori sono stati sovraccaricati (in una base di codice che ha fatto ampio uso del sovraccarico), è necessario avere una conoscenza pratica del codice completo, anche se si desidera leggere solo una piccola parte di esso. Ciò renderebbe difficile portare nuovi sviluppatori alla velocità su quel codice e impossibile coinvolgere le persone per un piccolo lavoro. Questo può essere utile per la sicurezza del lavoro del programmatore, ma se sei responsabile del successo della base di codice, dovresti evitare questa pratica a tutti i costi.

Poiché gli operatori sono di piccole dimensioni, sovraccaricare gli operatori consentirebbe un codice più denso, ma rendere il codice denso non è un vero vantaggio. Una riga con il doppio della logica richiede il doppio del tempo di lettura. Al compilatore non importa. L'unico problema è la leggibilità umana. Poiché la compattazione del codice non migliora la leggibilità, la compattezza non offre alcun vantaggio. Vai avanti e occupati dello spazio e assegna alle operazioni uniche un identificatore univoco e il tuo codice avrà più successo a lungo termine.

Difficoltà tecniche per gestire la precedenza e analisi complesse messe da parte, penso che ci siano alcuni aspetti di ciò che un linguaggio di programmazione deve essere considerato.

Gli operatori sono in genere costrutti logici brevi che sono ben definiti e documentati nel linguaggio principale (confronta, assegna ...). In genere sono anche difficili da capire senza documentazione (confronta a^bcon xor(a,b)per esempio). Esiste un numero piuttosto limitato di operatori che potrebbero effettivamente avere senso nella normale programmazione (>, <, =, + ecc.).

La mia idea è che è meglio attenersi a una serie di operatori ben definiti in una lingua, quindi consentire il sovraccarico degli operatori di tali operatori (data una leggera raccomandazione che gli operatori dovrebbero fare la stessa cosa, ma con un tipo di dati personalizzato).

I tuoi casi d'uso di ~e |sarebbero effettivamente possibili con un semplice sovraccarico dell'operatore (C #, C ++, ecc.). DSL è un'area di utilizzo valida, ma probabilmente una delle uniche aree valide (dal mio punto di vista). Tuttavia, penso che ci siano strumenti migliori per creare nuove lingue all'interno. L'esecuzione di un vero linguaggio DSL in un'altra lingua non è così difficile utilizzando uno di questi strumenti di compilatore-compilatore. Lo stesso vale per "Estendi argomento LUA". Molto probabilmente una lingua viene definita principalmente per risolvere i problemi in un modo specifico, non per costituire una base per le lingue secondarie (esistono eccezioni).

Un altro fattore è che non è sempre semplice definire un'operazione con gli operatori disponibili. Voglio dire, sì, per qualsiasi tipo di numero, l'operatore '*' può avere un senso e di solito sono implementati nella lingua o nei moduli esistenti. Ma nel caso delle classi complesse tipiche che è necessario definire (cose come ShipingAddress, WindowManager, ObjectDimensions, PlayerCharacter, ecc.) Quel comportamento non è chiaro ... Cosa significa aggiungere o sottrarre un numero a un indirizzo? Moltiplicare due indirizzi?

Certo, puoi definire che l'aggiunta di una stringa a una classe ShippingAddress significa un'operazione personalizzata come "Sostituisci la riga 1 nell'indirizzo" (invece della funzione "setLine1") e l'aggiunta di un numero è "Sostituisci codice postale" (invece di "setZipCode") , ma il codice non è molto leggibile e confuso. Generalmente pensiamo che gli operatori vengano utilizzati in tipi / classi di base, poiché il loro comportamento è intuitivo, chiaro e coerente (almeno una volta che hai familiarità con la lingua). Pensa in tipi come Integer, String, ComplexNumbers, ecc.

Quindi, anche se la definizione di operatori può essere molto utile in alcuni casi specifici, la loro implementazione nel mondo reale è piuttosto limitata, poiché il 99% dei casi in cui ciò rappresenterà una chiara vittoria è già implementato nel pacchetto linguistico di base.