Utilizzando lettori di macro , è possibile interpretare JavaScript e averlo compilato come il normale codice Common Lisp. Quindi ottenere i benefici delle implementazioni Lisp, in particolare le loro prestazioni. Il che significherebbe avere prestazioni native nel browser, senza imbrogli .
Sarebbe tecnicamente possibile creare questo per il browser? Sono principalmente preoccupato per le associazioni DOM.
Ci dispiace, ma la tua ipotesi è sbagliata. Lisp è bello e tutto, ma non è magia pixie performance dinamica.
Compilare / eseguire qualcosa che somiglia ad un JavaScript di base è una cosa. Ma non è ciò che è necessario.
Aggiungi ciò che è necessario per dire che JavaScript ha variabili che si autoconvertono tra numero intero, virgola mobile e rappresentazioni di stringa in base alle specifiche. Aggiungi il metodo di ricerca delle variabili utilizzato da JavaScript. (Le variabili vengono esaminate in una serie di ambiti, a partire dalla chiamata della funzione corrente). Aggiungere il modello a oggetti utilizzato da JavaScript. Continua con le specifiche e continuerai a rallentare e rallentare le cose.
Una volta che hai finito, anche se hai iniziato con Lisp, hai semplicemente ottenuto un'altra implementazione di un runtime JavaScript che è lenta per tutte le ragioni che sono altre. Potrebbe essere più veloce o più lento delle implementazioni esistenti. Dato lo sforzo di ottimizzazione che è stato applicato a tali implementazioni, è probabile che sarà più lento di un ampio margine.
A quel punto, decidere se completare la scrittura di un browser in Lisp, o se caricare Lisp in un browser e applicare i giusti JavaScript giusti dipende da te. Ma le tue ipotesi sulle prestazioni sono sbagliate.
A questo punto, potresti essere tentato di dire che sarebbe bello creare un nuovo linguaggio che possa essere dinamico e performante. Sarebbe, ma c'è un problema di pollo e uova. A meno che tutti i browser non lo abbiano, nessuno lo userà. A meno che le persone non lo usino, i browser non lo scriveranno. Questo è risolvibile, ad esempio guarda HTML5 Canvas. Ma sembra più facile da risolvere se è mirato a un noto punto dolente, vedi Canvas HTML5. Estrarre tutto il codice JavaScript per qualcos'altro non sembra essere una cosa facile da fare. (Microsoft ci ha provato agli albori dell'era del Web. Quando è stata l'ultima volta che hai visto VBScript in the wild?)
Common Lisp non è il più veloce in termini di velocità di esecuzione quando si tratta di implementare altri linguaggi di programmazione compilandolo su Common Lisp o addirittura interpretandolo in Common Lisp.
Anche Common Lisp ha fondamentalmente tre diversi intervalli di velocità:
la normale lingua Lisp. Può essere compilato in modo efficiente, ma ci sono cose inerenti che lo rendono meno veloce di C e di altri linguaggi di basso livello. Ad esempio ha bisogno di molti controlli di runtime e decisioni di runtime.
un linguaggio Lisp di basso livello. Questo può essere compilato per codice molto efficiente. Ma qui abbiamo bisogno e sfruttiamo i suggerimenti sulle prestazioni, le dichiarazioni di tipo, l'inferenza di tipo, l'inlining del codice e altro ancora.
un sistema di oggetti di alto livello (CLOS), che è difficile da compilare con codice efficiente
Ma Common Lisp è ancora usato per implementare le lingue. A volte per ricerca ed esplorazione.
Ad esempio, c'era un'implementazione di Javascript in Common Lisp. È stato scritto da Netscape per esplorare la semantica di Javascript:
Ma come puoi vedere che l'implementazione non è semplice e no, i "lettori di macro" non sono di grande aiuto.
Leggi altre domande sui tag lisp javascript