Il DLR, Boo, e la JVM

Question

Sto solo cominciando a cercare di saperne di più sulle basi .Net VM, e sono subito buttato fuori da qualcosa. So che c'è questa nuova cosa chiamata DLR che permette di tutte le cose dinamiche in C # e l'esecuzione delle lingue IronX. Ma ora sto leggendo di questo linguaggio chiamato Boo, ea quanto pare ha avuto capacità dinamiche da molto tempo prima della DLR esistesse. Così,

1) Come è possibile?

2) Che cosa significa il DLR metti in l'equazione?

3) sarebbe un linguaggio come Boo da guadagnare nulla da solo ri-attuazione in termini di DLR?

Da quello che ho tipo di raccolte qua e là, sembra che la DLR è venuto fuori IronPython, quando presi fuori tutto ciò che era necessario per il supporto DL in .Net, e lo mise in forma riutilizzabile. Quindi quello che sto indovinando è che DLR è niente di speciale, solo alcune librerie che aiuto con oggetti dinamici in Microsoft.Scripting.dll, ma niente che non si poteva solo uscire e il codice da soli se si ha il tempo, che Credo che è quello che è successo per Boo? E poi per 2 e 3, credo che la comunanza e la riusabilità del DLR permetterebbe eventuali miglioramenti futuri DLR da grandfathering automaticamente, ma che non c'è "bisogno" urgente di re-implementare utilizzando il DLR se hai già fatto la vostra proprio runtime personalizzato? Oppure la DLR ha qualche salsa MS segreto che rende meglio di qualsiasi cosa potremmo fare in cima a .Net?

4) è il DLR davvero un runtime o solo un set di librerie? (Che cosa è esattamente un runtime comunque? Probabilmente ho bisogno di imparare di più la teoria compilatore prima posso anche capire una risposta a questa domanda, o se è anche una domanda che significa qualcosa. Ignora questa domanda. O no.)

5) Come funziona IronPython lavoro di compilazione? Ha compilare fino ad una nuova versione dinamica del CIL, o ha semplicemente anteporre un comando "ironpython.exe" per una stringa con il testo del programma in esso? Hmm, bene se dinamico è una parola chiave in C #, quindi ci deve essere una versione dinamica del CIL, giusto? Così come fa Net sa se utilizzare il CLR o DLR sul CIL?

6) Il progetto DaVinci per le diverse JVM? Sembra come se fosse un vero e proprio re-implementazione della JVM stessa. Quali sono le implicazioni di questo approccio? Sto indovinando c'è enormi guadagni di prestazioni, ma qualsiasi altra cosa? Qual è il motivo MS non ha preso questa strada?

7) Se il DLR make Boo un po 'obsoleto per fare DSL?

Answer 1

Il DLR porta essenzialmente 3 cose al partito:

• Un esteso insieme di alberi di espressione (prima introdotte w / LINQ) che consentono la compilazione di programmi completi. Questi forniscono un modo molto più facile da generare il codice che generare direttamente IL - si libera di molti casi di essere in grado di generare non valida IL e si trasforma in molti altri casi le eccezioni di runtime facilmente debuggable
.
• Un costruito nel meccanismo di caching del sito chiamata in modo non è necessario per creare il proprio (molto utile per le buone prestazioni in linguaggi dinamici). Questo include cose come una cache multilivello e invecchiamento fuori gli oggetti inutilizzati.
• Un protocollo oggetto di meta che permette linguaggi dinamici di parlare gli uni agli altri in fase di esecuzione e negoziare il risultato corretto per la lingua chiamando il numero (ad esempio restituisce undefined in JavaScript quando un membro non esiste o gettare un'AttributeError in Python, indipendentemente dalla lingua l'oggetto dinamico è stato scritto in).

Il protocollo oggetto meta è l'unico pezzo che deve assolutamente essere condiviso - tutto il resto è possibile creare da soli.

IronPython si basa completamente sulla parte superiore del DLR - quindi è modello di compilazione è in realtà per la compilazione di alberi di espressione. Lo strato interno DLR che hanno spedito w / .NET 4.0 viene utilizzato per compilare quegli alberi di espressione e usiamo l'interprete che è un pezzo dello strato esterno di interpretare quegli alberi di espressione. Possiamo quindi pigramente compilare gli alberi di espressione, dopo le versioni interpretati sono diventati caldo. Che compilation comprende la produzione di siti di chiamata che usiamo per la dinamica invio di varie operazioni (ottenendo, impostando i membri, chiamando gli oggetti, ecc ...) e ancora una volta abbiamo utilizzare il DLR - in questo caso del meccanismo sito di chiamata. IronPython utilizza una combinazione di entrambi i leganti DLR standard per queste operazioni insieme con leganti personalizzati che fanno azioni specifiche IronPython (fluiscono attraverso il contesto del codice, sostenendo * args e ** args chiamate, ecc ...), che poi ripiegare a leganti DLR standard per Interop.

Il progetto Davinci aggiungerà "Metodo maniglie" per la JVM che il CLR ha già avuto in forma di delegati. Sarà anche aggiungere un nuovo codice operativo "invokedynamic" che il CLR non ha e non ha ottenuto w / il lavoro DLR. Invece DLR utilizza solo le primitive esistenti (delegati, generici reificati) più librerie per definire il protocollo di interoperabilità. Sia aggiungere il concetto di siti di chiamata e questi possono essere abbastanza simile tra i due.

Answer 2

Un sacco di domande qui! Io non sono sicuro di poter rispondere a tutti di loro, ma farò quanto posso:

1. Boo non è dinamica nello stesso senso che (ferro) Python è. E 'soprattutto un linguaggio a tipizzazione statica di tipo forte l'inferenza e la sintassi divinatorio. Questo, unito con la sua tipizzazione anatra opzionale, dare una sensazione molto dinamico, ma non è certamente la stessa di Python. Boo è più simile (tranne che per la sintassi) per C # 4 di Python.

2. DLR aggiunge il supporto dinamico per implementatori lingua in cima il CLR, che è più orientata verso lingue staticamente tipizzati (come VB.NET, C #, F #)

3. Non proprio IMHO. Sarebbe diventato troppo simile a IronPython. Proprio una delle caratteristiche di Boo è che è staticamente tipizzato.

4. Runtime sono le librerie che supportano alcuni costrutti di base del linguaggio. VB.NET, C #, F #, Boo, tutti hanno librerie di runtime. Di solito si vede mai VB.NET o C # runtime perché provengono con il framework .NET. C'era una grande risposta su SO su questo da Eric Lippert ma non riesco a trovarlo.

5. Non può commentare su questo, non ho molta esperienza hands-on con IronPython.

6. Non so circa il progetto DaVinci, non posso commentare su questo.

7. No. Per quanto ne so macro di Boo e compilatore estensibile sono abbastanza unica per un linguaggio .NET ( Nemerle ha capacità macro simili). Non posso davvero dire se Boo DSL può essere più o meno potente di IronPython DSL. Quello che posso dire per certo è che l'attuazione di Boo DSL è molto diversi dal implentation di Python DSL.