La domanda è priva di senso.
L'interpretazione e la compilazione sono proprietà dell'implementazione , non della lingua. In altre parole, sono proprietà dell'interprete o del compilatore (duh!). Ogni lingua può essere implementata con un compilatore e ogni lingua può essere implementata con un interprete. Parlare di "linguaggio compilato" o "linguaggio interpretato" non è nemmeno sbagliato, è privo di senso. Se l'inglese fosse una lingua tipizzata, il "linguaggio interpretato" sarebbe un errore di tipo.
Inoltre, impacchettare il programma insieme all'interprete in un singolo file eseguibile non è distinguibile dalla compilazione, e la compilazione e l'esecuzione immediata sono indistinguibili dall'interpretazione.
es. l'interprete di Scala è in realtà solo il compilatore che esegue immediatamente il codice. Allo stesso modo, il tcc (piccolo compilatore C) ha una modalità di scripting, che semplicemente compila il file e lo esegue.
One point I thought of was to create a compiled version of a Read-eval-print to test mini functions faster than compiling a whole program for ease of testing.
Questo non ha nulla a che fare con il design della lingua. Questo è un problema di implementazione. La tua domanda riguardava la progettazione di un linguaggio, non l'implementazione di uno. Queste sono cose molto diverse. Per uno, la progettazione di una lingua avviene in inglese, l'implementazione di una lingua avviene in un linguaggio di programmazione.
What else could I add?
Bene, cosa significa "scripting"? Fondamentalmente significa interagire dinamicamente con oggetti che non controlli. Questo è il succo dello scripting: interagisci con "qualcos'altro". Quel "qualcos'altro" fornisce i tipi di dati, gli oggetti e anche la maggior parte delle operazioni. Un linguaggio di scripting della shell interagisce con il sistema operativo; il sistema operativo fornisce gli oggetti (file, processi, prese, fili, dispositivi, ...) e le operazioni (lettura, scrittura, copia, ...). Un linguaggio di scripting web interagisce con il documento e il browser; il browser fornisce gli oggetti (nodi DOM, ...) e le operazioni (DOM API, ...). AutoLisp interagisce con AutoCAD, Photoshop ha un linguaggio di scripting (credo?), Ecc., Quelle lingue interagiscono con modelli o foto 3D, e le operazioni sono fornite dall '"host".
Quindi, uno script interagisce con oggetti il cui tipo non controlla e le cui vite sono indipendenti dallo script attraverso le operazioni fornite dall'host. Questo è ciò che significa "scripting".
Che cosa significa "linguaggio di scripting"? Beh, nessuno lo sa, esattamente. È un linguaggio con cui puoi fare scripting? Puoi farlo con qualsiasi linguaggio, non è una definizione utile. (Proprio come si può fare programmazione funzionale o programmazione orientata agli oggetti con qualsiasi linguaggio.) Personalmente, io lo definirei come un linguaggio che facilita lo scripting e lo semplifica.
Secondo quanto scritto sopra, un linguaggio di scripting richiede flessibilità. Un sistema di tipo dinamico o un sistema di tipo statico espressivo consentono al linguaggio di trattare con garbo il fatto che la maggior parte dei tipi e degli oggetti provengono dall'esterno. Una forma di gestione automatica delle risorse è altamente auspicabile, dal momento che il linguaggio interagisce principalmente con oggetti le cui vite non controllano, e il tentativo di farlo con la gestione manuale delle risorse può diventare disordinato. (Sia che tu scelga regioni monadiche, garbage collection o qualsiasi altra cosa dipende interamente da te.)
E una piccola cosa: per essere utile in Unix come linguaggio di scripting, ha bisogno di essere in grado di affrontare il fatto che quella prima riga dello script sarà qualcosa di simile
#!/usr/bin/env mycoollanguagecompilerimmediate
Vedi Scala per un esempio: in Scala, che sarebbe un errore di sintassi (a differenza di molti linguaggi di scripting, Scala non usa # per i commenti). Tuttavia, in modalità di scripting, Scala ignora tutto fino a includere una riga composta da !# , che ti consente di scrivere qualcosa del tipo:
#!/usr/bin/env ruby
ENV['SCALA_HOME'] ||= '/opt/scala'
# some code to locate the most recent JDK version
# some code to locate the most recent Scala version
# …
exec("#{scala} #{ARGV[0]}")
# Ruby code ends here
!#
// Scala code starts here
Questo è tutto ciò che posso pensare: un sistema di tipo flessibile e potente (vedi PowerShell o Mondrian per esempi) e il supporto per le linee shebang. Entrambi non hanno nulla a che fare con la compilazione.