Perché le lingue non includono l'implicazione come operatore logico?

Potrebbe essere una domanda strana, ma perché non ci sono implicazioni come operatore logico in molti linguaggi (Java, C, C ++, Python Haskell - anche se come ultimo hanno operatori definiti dall'utente è banale aggiungerlo)? Trovo che le implicazioni logiche siano molto più chiare da scrivere (in particolare in affermazioni o espressioni assertive), quindi negazione con o:

encrypt(buf, key, mode, iv = null) {
    assert (mode != ECB --> iv != null);
    assert (mode == ECB || iv != null);
    assert (implies(mode != ECB, iv != null)); // User-defined function
}

Potrebbe essere utile a volte, senza dubbio. Diversi punti discutono contro un tale operatore:

• I personaggi -e >sono preziosi, sia in isolamento che combinati. Molte lingue li usano già per indicare altre cose. (E molti non possono usare i set di caratteri unicode per la loro sintassi.)
• L'implicazione è molto controintuitiva, anche per le persone logiche come i programmatori. Il fatto che tre delle quattro voci della tabella della verità siano truesorprese per molte persone.
• Tutti gli altri operatori logici sono simmetrici, il che farebbe ->un'eccezione all'ortogonalità.
• Allo stesso tempo, c'è una soluzione semplice: usare operatori !e ||.
• L'implicazione è ampiamente usata meno spesso di logica and/ or.

Questo è probabilmente il motivo per cui l'operatore è raro oggi. Certamente potrebbe diventare più comune, poiché i nuovi linguaggi dinamici usano Unicode per tutto e il sovraccarico dell'operatore diventa di nuovo più alla moda.

Credo che la risposta risieda nelle basi matematiche . L'implicazione è generalmente considerata e definita come un'operazione derivata, non elementare, di algebre booleane. I linguaggi di programmazione seguono questa convenzione.

Questa è la proposizione I del capitolo II di An Investigation of the Laws of Thought (1854) di George Boole :

Tutte le operazioni del linguaggio, come strumento di ragionamento, possono essere condotte da un sistema di segni composto dai seguenti elementi, vale a dire:

1 °. Simboli letterali, come x, y, ecc., Che rappresentano le cose come soggetti delle nostre concezioni.

2 °. Segni di operazione, come +, -, ×, rappresentano le operazioni della mente mediante le quali le concezioni delle cose vengono combinate o risolte in modo da formare nuove concezioni che coinvolgono gli stessi elementi.

3 °. Il segno di identità, =.

E questi simboli della Logica sono nel loro uso soggetti a leggi definite, in parte in accordo e in parte diverse dalle leggi dei simboli corrispondenti nella scienza dell'Algebra.

Il segno + di Boole rappresenta la stessa "operazione della mente" che oggi riconosciamo sia come "booleano" che come unione di insiemi. Allo stesso modo i segni - e × corrispondono alla nostra negazione booleana, complemento di un insieme, "booleano" e "intersezione di insiemi.

AGGIORNAMENTO: Questa domanda è stata l'oggetto del mio blog a novembre 2015 . Grazie per l'interessante domanda!

Visual Basic 6 (e VBScript) aveva Impe Eqvoperatori. Nessuno li ha usati. Entrambi sono stati rimossi in VB.NET; per quanto ne so, nessuno si è lamentato.

Ho lavorato nel team di compilatore di Visual Basic (come stagista) per un anno intero e non ho mai notato che VB avesse anche quegli operatori. Se non fossi stato il tipo a scrivere il compilatore VBScript e quindi avessi dovuto testare le loro implementazioni, probabilmente non me ne sarei accorto. Se il ragazzo del team del compilatore non è a conoscenza della funzione e non la utilizza, questo ti dice qualcosa sulla popolarità e l'utilità della funzione.

Hai citato lingue simili a C. Non posso parlare con C o C ++ o Java ma posso parlare con C #. C'è un elenco di funzionalità suggerite dall'utente per C # letteralmente più lunghe del braccio. Per quanto ne sappia, nessun utente ha mai proposto un simile operatore al team C # e ho esaminato l'elenco molte, molte volte.

Funzionalità esistenti e non utilizzate in una lingua e mai richieste in un'altra sono candidati improbabili a trasformarlo in moderni linguaggi di programmazione. Soprattutto quando non c'è abbastanza tempo e fatica e denaro a disposizione nel bilancio per rendere le caratteristiche che le persone non vogliono.

Posso solo immaginare, ma una ragione potrebbe essere che ci sono soluzioni alternative che sono abbastanza semplici e leggibili. Consideriamo il tuo esempio:

if (mode != ECB) assert (iv != null);

assert (mode != ECB --> iv != null);  // <-- that's only one character shorter

Se è necessaria un'espressione, è possibile utilizzare l'operatore inline-if disponibile nella maggior parte delle lingue (spesso chiamato operatore ternario). Certo, questo non è così elegante come A --> B, ma il numero di casi d'uso potrebbe non giustificare l'aggiunta (e la manutenzione!) Di un altro operatore:

assert (mode != ECB ? iv != null : true);

Eiffel ha implicazioni

In realtà ha ancora di più. Ha un numero di operatori semi-severi oltre che severi.

Il motivo per cui i programmatori non usano queste cose è perché non sono mai addestrati a sapere esattamente cosa sono, come usarli e quando usarli, oltre a come progettare con loro. Poiché non sono mai addestrati, non lo chiedono mai agli autori del compilatore, motivo per cui le persone del compilatore non si preoccupano di inserire tali meccanismi nel compilatore. Quando gli studenti di informatica e i programmatori di Shade Tree iniziano a ricevere un'istruzione più completa, i compilatori inizieranno a recuperare.

Si scopre che una volta che hai una lingua con tali operatori booleani e sai come progettare con loro e usarli, allora li usi.

In Eiffel l'uso della parola chiave "implica" è piuttosto importante a causa della progettazione per contratto a causa della natura booleana delle asserzioni contrattuali. Esistono alcuni contratti che possono essere scritti in modo corretto ed efficiente solo con l'operatore "implica". Ciò fa quindi supporre che le lingue senza contratto siano ulteriormente prive di motivo per esaminare, formare e implementare l'uso dell'implicazione.

Aggiungete a ciò che la maggior parte dei programmatori sono "deboli in matematica e logica" e ci racconta il resto della storia. Anche se sei matematico e logico nella tua educazione, quando si sceglie una lingua che non implementa costrutti come implicazioni, si tende a pensare che tali cose siano inutili o non utili. Raramente si mette in discussione il linguaggio e si entra in una camera di eco di: "Beh, i ragazzi del compilatore non vedono il bisogno" e "Beh, i programmatori non vedono il bisogno" - cerchio infinito e vizioso.

Invece, le persone del compilatore devono fare il backup della teoria, scrivere una notazione linguistica che è suggerita o implicita dalla teoria (ad esempio teoria orientata agli oggetti) indipendentemente da ciò che le masse non programmate di programmatori pensano o chiedono. Da lì, professori, insegnanti e altri professionisti hanno bisogno di addestrare sapientemente giovani menti pazze basate sulla teoria grezza e NON sulla "teoria attraverso la lente del linguaggio". Quando ciò accade, le persone si sveglieranno improvvisamente e realizzeranno ciò che si sono persi e ciò che è stato soffocato su di loro.

In questo momento - c'è così tanta teoria là fuori che si maschera da Object Oriented, ma è solo OO-through-a-glass-darkly-of- [scegli il tuo linguaggio]. Non si può leggere la maggior parte dei libri di "teoria" su OO perché vogliono interpretare ciò che la teoria è attraverso l'obiettivo di un certo linguaggio. Totalmente falso e errato. Sarebbe come insegnare la matematica sulla mia calcolatrice o la mia regola di scorrimento. NO - uno permette alla realtà di insegnare a se stesso e quindi usa una notazione per descrivere ciò che si osserva - che si chiama "scienza". Quest'altro mash chiamato OO-based-on-language-X è così distorto da rappresentare a malapena la realtà.

Quindi, allontanati dalla lingua, dai un'occhiata alla teoria grezza e ricomincia. Non lasciare che limitazioni, vincoli e lavori di pittura di una lingua ti dicano qual è la teoria. Lascia semplicemente che la realtà della teoria imponga la propria notazione e poi passa da lì alla formulazione di una lingua.

Da lì, inizierai a capire come l'implicazione e "implica" non sia solo utile, ma elegante e molto interessante!

Buona giornata!

Python ha un operatore di implicazioni in una sorta di modo nascosto.

L'operatore inferiore o uguale a è sovraccarico per accettare valori booleani. Di conseguenza, è possibile utilizzarlo come operatore di implicazione.

Prova di esempio (codice Python):

print (False <= False) # This will print True.
print (False <= True)  # This will print True.
print (True <= False)  # This will print False.
print (True <= True)   # This will print True.

Ricordare che la tabella di verità dell'operatore di implicazione è:

LEFT RIGHT RESULT
F    F     T
F    T     T
T    F     F
T    T     T

Eiffel ha un operatore "implicito" ed è molto bello per scrivere pre e post-condizioni. Rende il codice più leggibile, sfortunatamente non è mai stata un'intenzione fondamentale per il linguaggio C e troppe persone hanno usato eiffel, quindi la bellezza di "implica" come operatore non è ben nota.

Per me, il grosso problema con implica implica che la condizione iniziale è falsa; per esempio: "Se il sole è verde, allora sono un pipistrello della frutta". Vero!

Nella logica formale funziona semplicemente per assegnare "True" al valore quando la condizione dell'implicazione non è soddisfatta. Ma nella programmazione, ciò potrebbe portare a risultati contro-intuitivi e sorprendenti.

In realtà penso che l'esempio @Heinzi fornisca sopra:

if (sun.color() == "green") then assert(me.species() == "fruitbat")

È molto più facile da capire e meno soggetto a errori dovuti a malintesi sulla logica.

Nel contesto del test, fermerei il momento in cui le mie assunzioni sono diventate false:

assert(sun.color() == "green")
assert(me.species() == "fruitbat")

Quindi, al punto di @Eric Lippert, come programmatore non so quando userei un operatore implicito. Il comportamento "False is True" sembra utile nel contesto della logica matematica e formale, ma potrebbe portare a risultati inaspettati nella logica del programma.

...

Nessuno ha menzionato il "?" Comune operatore, dove "A? B: true" è uguale a "implica". Ma mentre la logica formale assegna true alla condizione "else", "?" consente allo sviluppatore di assegnarlo esplicitamente.

Nella logica formale, l'utilizzo di "true" funziona, ma in programmazione, se la condizione è falsa, la risposta migliore è più simile a "null" o "void" o "skip", o forse falso.

Penso che qualcuno dovrebbe spiegare il motivo per cui "implica" è un operatore più utile delle istruzioni "?", O "if", o semplicemente un normale flusso di programma.

La racchetta ha implies. Si espande macro in ifun'espressione.