I linguaggi interpretati - sfruttando il linguaggio compilato dietro l'interprete

Question

Se ci sono qualsiasi lingua designer (o persone semplicemente sapere), mi incuriosisce la metodologia dietro la creazione di librerie standard per i linguaggi interpretati.In particolare, quello che sembra essere l'approccio migliore?La definizione di standard di funzioni/metodi nel linguaggio interpretato, o si effettua il trattamento di queste chiamate nel linguaggio compilato, in cui l'interprete è scritto?

Ciò che mi ha fatto pensare a questa fu la domanda su un stripslashes () come funzione in Python.Il mio primo pensiero è stato: "perché non definire la propria e basta chiamare in caso di necessità", ma ha sollevato la questione:è preferibile, per tale funzione, per lasciare che il linguaggio interpretato maniglia che overhead, o sarebbe meglio scrivere un'estensione e sfruttare il linguaggio compilato dietro l'interprete?

Answer 1

La linea tra "interpretato" e "compilato" lingue è davvero fuzzy in questi giorni.Per esempio, la prima cosa Python fa quando vede il codice sorgente è compilarlo in una rappresentazione bytecode, essenzialmente la stessa cosa che Java non durante la compilazione dei file di classe.Questo è ciò che *.pyc file contengono.Quindi, il python runtime esegue il bytecode, senza riferimento alla fonte originale.Tradizionalmente, un puro linguaggio interpretato farebbe riferimento al codice sorgente di continuo quando è in esecuzione il programma.

Quando la costruzione di una lingua, è un buon approccio per costruire una solida base su cui è possibile implementare il livello più elevato di funzioni.Se hai un solido, veloce stringa di gestione del sistema, quindi la lingua designer può (e dovrebbe) implementare qualcosa di simile stripslashes() al di fuori del runtime di base.Questo viene fatto per almeno un paio di motivi:

• Il linguaggio di design in grado di dimostrare che la lingua è sufficientemente flessibile per gestire questo tipo di attività.
• La lingua designer scrive, codice vero e proprio linguaggio, che ha le prove e, quindi, mostra che la fondazione è solido.
• Altre persone può più di leggere facilmente, prendere in prestito, e anche di cambiare il più alto livello di funzione, senza dover essere in grado di costruire, o anche capire la lingua core.

Solo perché un linguaggio come Python compilato in bytecode e esegue questo non significa che non è lento.Non c'è alcuna ragione per cui qualcuno non riusciva a scrivere un Just-In-Time (JIT) compilatore Python, lungo le linee di quello che Java e .NET già fare, per aumentare ulteriormente le prestazioni.Infatti, IronPython compila Python direttamente .NET bytecode, che viene quindi eseguito utilizzando il .NET system tra cui il JIT.

Per rispondere alla tua domanda direttamente, l'unica volta che un linguaggio di design vorrei implementare una funzione in linguaggio alla base del runtime (es.C, nel caso di Python) sarebbe quello di massimizzare le prestazioni della funzione.Questo è il motivo per cui i moduli come l'espressione regolare parser sono scritti in C e non native Python.D'altra parte, un modulo come getopt.py è implementato in puro Python, perché tutto può essere fatto c'è e non c'è alcun beneficio per l'utilizzo del corrispondente C library.

Answer 2

C'è anche una tendenza all'aumento di reimplementando lingue che sono tradizionalmente considerati "interpretato" su una piattaforma come la JVM o CLR -- e quindi consentendo un facile accesso ai "nativi" codice per l'interoperabilità.In modo da Jython e JRuby, è possibile accedere facilmente a codice Java, e da IronPython e IronRuby, è possibile accedere facilmente .NET code.

In casi come questi, la possibilità di "sfruttare il linguaggio compilato dietro l'interprete" potrebbe essere descritto come la principale motivazione per la nuova implementazione.

Answer 3

Vedere le 'Carte' sezione a www.lua.org.

In particolare L'Attuazione di Lua 5.0

Lua definisce tutte le funzioni standard del sottostante (ANSI C) del codice.Credo che questo è in gran parte per motivi di prestazioni.Di recente, vale a direla 'stringa.*' funzioni ottenuto un'implementazione alternativa in puro Lua, che possono rivelarsi di vitale importanza per i sottoprogetti in cui Lua è eseguito .NET o Java runtime (dove C codice non può essere utilizzato).

Answer 4

Fintanto che si sta utilizzando un portatile API per il codice compilato base, come le ANSI C standard library o STL in C++, quindi approfittando di queste funzioni non si reinventare la ruota e probabile che fornire un più piccolo, più veloce di un interprete. Lua prende questo approccio, ed è sicuramente piccolo e veloce rispetto a molti altri.