Perché un'espressione booleana (con effetti collaterali) non è sufficiente come istruzione?

Question

function A: Boolean; 
function B: Boolean; 

I (accidentalmente) scritto questo:

A or B; 

Invece di che:

if not A then 
    B; 

Il compilatore respinge la prima forma, io sono curioso di sapere perchè?

Con la valutazione del cortocircuito entrambi farebbero la stessa cosa, vero?

Chiarimento: Mi chiedevo perché il linguaggio non è stato progettato per consentire la mia espressione come una dichiarazione.

Answer 1

Semplicemente, perché il compilatore si aspetta un statement e l'espressione che hai fornito non è una dichiarazione.

Consultare lo documentation e troverete un elenco di dichiarazioni valide. La tua espressione non può essere trovata in quella lista.

Hai chiesto nei commenti (ora cancellati) perché i progettisti linguistici hanno scelto di non fare una tale espressione come una dichiarazione. Ma quella domanda implica uno scopo in cui potrebbe non esserci stato nessuno. È perfettamente plausibile che i progettisti non abbiano deciso di non farlo. Piuttosto non hanno mai pensato di farlo in primo luogo. Le lingue sono generalmente progettate per risolvere problemi specifici. È perfettamente plausibile che i progettisti non abbiano semplicemente considerato di trattare espressioni del genere come dichiarazioni.

Answer 2

Il primo modulo è un'espressione che valuta un valore booleano, non un'istruzione.

Answer 3

Il primo è un'espressione. Le espressioni sono valutate Le espressioni non hanno effetti collaterali visibili (come leggere o scrivere una variabile). Entrambi gli operandi dell'espressione sono funzioni e quelli possono avere effetti collaterali, ma per avere effetti collaterali, deve essere eseguita una dichiarazione.

Il secondo è una dichiarazione. Confronta il risultato di un'espressione e in base alla valutazione chiama un'altra funzione.

La parte confusa, è che in questo caso, Delphi ci consente di ignorare il risultato di una funzione ed eseguirlo come una funzione. Quindi ti aspetti lo stesso per A or B. Ma non è permesso. Che è fantastico perché il comportamento è ambiguo. Ad esempio, se hai abilitato la valutazione lazy. E A è vero, B è chiamato sì o no.

Answer 4

Al suo centro, Delfi è Pascal. Il linguaggio Pascal è stato progettato da Nicklaus Wirth e pubblicato nel 1968. La mia copia del Manuale dell'utente e del Rapporto è del 1978. È stata progettata con due obiettivi in ​​mente, come linguaggio di insegnamento e come facile da implementare su qualsiasi macchina specifica. . In questo ha avuto un successo spettacolare.

Wirth era intimamente familiare con altre lingue del tempo (tra cui Fortran, Cobol e in particolare Algol) e ha fatto una serie di scelte accurate con particolari obiettivi in ​​mente. In particolare, ha accuratamente separato il concetto di "azioni" da "valori". Le "azioni" in Pascal sono le istruzioni nella lingua, inclusa la chiamata di procedura. I "valori" includono le chiamate di funzione. In questo e in altri aspetti la lingua è abbastanza simile a quella di Algol.

La sintassi per la dichiarazione e l'utilizzo di azioni e valori viene mantenuta con cura in modo separato.La lingua e le librerie fornite non hanno in generale "effetti collaterali" in quanto tali. Le procedure fanno le cose e le espressioni calcolano i valori. Ad esempio, 'read' è una procedura, non una funzione, perché recupera un valore e avanza attraverso il file, ma 'eof' è una funzione.

La versione del mercato di massa di Pascal è stata creata da Borland a metà degli anni '80 e successivamente è diventata Turbo Pascal per Windows e successivamente Delphi. Il linguaggio è cambiato molto e non tutto è puro come progettato da Wirth. Questa è una caratteristica che è sopravvissuta.

Per inciso, Pascal non ha avuto una valutazione di cortocircuito. Aveva memoria heap e set, ma nessun oggetto. Sono venuti dopo.