Come mai la maggior parte dei Lisps e Schemi sono digitati dinamicamente? La tipizzazione statica non si combina con alcune delle loro caratteristiche comuni?Perché la maggior parte dei linguaggi S-Expression è stata digitata in modo dinamico?
Typing e s-espressioni possono essere fatti per lavorare insieme, vedere typed scheme.
In parte si tratta di una coincidenza storica che s-espressione lingue vengono digitati in modo dinamico. Queste lingue tendono a fare maggiore affidamento sui macro e la facilità di analisi e di corrispondenza del modello sulle espressioni s rende l'elaborazione delle macro molto più semplice. La maggior parte delle ricerche su macro sofisticate avviene nei linguaggi di s-expression.
Typed Hygienic Macros sono difficili.
Quando Lisp è stato inventato negli anni dal 1958 al 1960, ha introdotto molte funzionalità sia come linguaggio che come implementazione (garbage collection, un compilatore self-hosting, ...). Alcune funzionalità sono state ereditate (con alcuni miglioramenti) da altre lingue (elaborazione dell'elenco, ...). Il linguaggio ha implementato il calcolo con le funzioni. Le espressioni S erano più un dettaglio di implementazione (in quel momento) che una funzione di linguaggio. Un sistema di tipo non faceva parte della lingua. Anche l'utilizzo della lingua in modo interattivo era una delle prime funzioni di implementazione.
Gli utili sistemi di tipo per linguaggi funzionali non erano ancora stati inventati in quel momento. Ancora fino a oggi è anche relativamente difficile utilizzare le lingue tipizzate in modo statico in modo interattivo. Esistono molte implementazioni di linguaggi tipizzati staticamente che forniscono anche un'interfaccia interattiva, ma per lo più non offrono lo stesso livello di supporto per l'uso interattivo di un tipico sistema Lisp. Programmare in un sistema Lisp interattivo significa che molte cose possono essere modificate al volo e potrebbe essere problematico se le modifiche del tipo dovessero essere propagate attraverso interi programmi e dati in un sistema Lisp interattivo. nota che alcuni Schemers hanno una visione diversa su queste cose. R6RS è principalmente un linguaggio batch in genere non tanto nello spirito di Lisp ...
I linguaggi funzionali che sono stati inventati in seguito con sistemi di tipo statico hanno ottenuto anche una sintassi non di espressione S: non offrivano supporto per macro o funzionalità correlate. in seguito alcuni di questi linguaggi/implementazioni hanno utilizzato un preprocessore per estensioni sintattiche.
Interessante, perché dici che R6RS è principalmente un linguaggio batch? –
Non esiste una semantica descritta in R6RS per l'uso interattivo della lingua. ad esempio EVAL è una funzione di libreria e completamente sottodimensionata. Le implementazioni potrebbero cercare di aggirare il problema, ma sembra anche che gli autori di R6RS non fossero interessati all'utilizzo interattivo. Quindi non c'è nulla che parla di librerie e REPL per esempio. Generalmente sono del tutto sottovalutato dalla qualità dello standard R6RS, oltre ai limiti tecnici del linguaggio descritto. Spero che R7RS migliori. –
La tipizzazione statica è lessicale, significa che tutte le informazioni sui tipi possono essere dedotte dalla lettura del codice sorgente senza valutare espressioni o calcolare qualsiasi cosa, i condizionali sono più importanti qui. Un linguaggio tipizzato in modo statico è progettato in modo che ciò possa accadere, un termine migliore sarebbe "tipicamente lessicale", in quanto un compilatore può provare dalla sola lettura della fonte che non si verificheranno errori di tipo.
Nel caso di Lisp, questo è goffamente diverso perché il codice sorgente di Lisp per sé non è statica, Lisp è homo-iconica, utilizza dati come il codice e può in certa misura modificare dinamicamente la propria fonte di esecuzione.
Lisp è stato il primo linguaggio tipizzato in modo dinamico, e probabilmente per questo motivo, il codice del programma in sé non è più lessicale in Lisp.
Edit: una molto più potente ragione, nel caso di tipizzazione statica che ci si deve digitare liste. Puoi avere tipi estremamente complessi per ogni elenco che tiene conto di tutti gli elementi, della richiesta che ogni elemento abbia lo stesso tipo e che lo digiti come un elenco. La prima opzione produrrà inferno con liste di liste. Quest'ultima opzione richiede che il codice sorgente contenga solo lo stesso tipo per ogni dato, questo significa che non puoi nemmeno costruire espressioni in quanto un elenco è comunque un tipo diverso da un intero.
Quindi oserei dire che è completamente e assolutamente impossibile da realizzare.
È semplicemente difficile, non impossibile. Vedi MetaML e MetaOCaml per contro-esempi. E le lingue con dattilografia possono farlo anche tu - vedi gli esperimenti con una valutazione parziale in Idris. –
Uno deve rimuovere così tanto che non si può più parlare di "espressione S-based". Un'idea centrale delle espressioni S è la funzione apply, che rende il codice stesso dinamico, sicuramente è quindi impossibile dimostrare staticamente l'assenza di errori di tipo. Guardando MetaML e MetaOCaml, non vedo alcuna indicazione che siano basati sull'espressione S o homo-iconic. – Zorf
Lo schema tipizzato non è tipizzato staticamente, fornisce tipi come controllo degli errori. La tipizzazione statica si rifiuta di compilare a meno che il compilatore non possa provare che il programma è interamente digitato sicuro. Lo schema tipizzato produce ancora errori di tipo runtime, nella tipizzazione statica non è possibile. – Zorf
@Lajla, sì, anche se non ho detto che lo schema digitato è stato tipizzato staticamente. –
Racket tipizzato ** è ** staticamente digitato: il typechecking avviene al momento della compilazione. Se non si supera il typechecker Typed Racket, si rifiuta di continuare. In normali operazioni, una volta che il controllo della digitazione è passato, Typed Racket applicherà le ottimizzazioni (http://docs.racket-lang.org/ts-reference/Optimization_in_Typed_Racket.html) che non sarebbero sicure senza le garanzie di tipo note da typechecking. – dyoo