2009-10-10 13 views
6

Sto costruendo un'applicazione simile a un foglio di calcolo, dove è necessario ricamare molti piccoli calcoli in una struttura ad albero. Questi calcoli sono definiti dall'utente e ho bisogno di un modo per l'utente di inserirli in fase di runtime.Basare una piccola espressione DSL sul DLR o tenerlo arrotolato a mano in F #?

Il mio approccio attuale è scrivere una piccola "espressione DSL" in F #, dove analizzo l'input con FParsec, costruisco un albero di sintassi basato su un'unione discriminata e quindi posso valutare l'espressione. Funziona piuttosto bene.

Tuttavia, sto pensando di cercare di basare la lingua sul DLR. Ci sono dei lati positivi per percorrere questa strada (analizzare l'input, generare l'AST usando il materiale Scripting.AST invece del mio e lasciare che il DLR gestisca l'esecuzione del calcolo)?

Ogni calcolo sarà probabilmente piuttosto piccolo. La dipendenza tra i calcoli sarà gestita ad un livello superiore.

Posso aspettarmi prestazioni migliori dal momento che il DLR genererà il codice CIL per l'espressione o il sovraccarico lo mangerà?

(come per l'utilizzo di una lingua esistente come IronPython, probabilmente sarà difficile da quando ho intenzione di aggiungere un sacco di operatori slice-and-dice e roba dimensionalità di gestione per la sintassi del linguaggio)

risposta

7

E ' difficile rispondere a una domanda in termini così ampi, ma ecco alcuni dei miei pensieri.

Utilizzando F # per generare il parser suona bene.

FSParsec è una grande libreria. Sono piuttosto parziale nei confronti di FSLex e FSYacc. Ad ogni modo, in F # ci sono librerie progettate appositamente per l'analisi che ti fanno risparmiare tempo.

La generazione del codice con il DLR suona OK.

Il DLR è una grande piattaforma per la generazione di codice dinamico. Tuttavia, la tua applicazione è molto più specifica. Se ti limiti a calcolare solo i valori, dovresti utilizzare le API di Expression Trees da .NET 3.5. Questa API è progettata per rappresentare espressioni di codice arbitrarie. Il DLR d'altra parte è progettato come un linguaggio runtime o dinamico. Non sto dicendo che sia impossibile, solo che non è lo strumento giusto per il lavoro.

Non compilare il codice generato.

Se si utilizza il DLR per rappresentare il proprio AST, il costo di compilazione ed esecuzione sarà probabilmente molto più grande della semplice interpretazione dell'albero. Compilare il codice se: A.) si sta eseguendo la stessa funzione/metodo molte volte o B.) la funzione/metodo è molto complicato.

C# + DLR, IronPython, F # o una combinazione delle tre sono tutte scelte audio. In definitiva, la scelta "corretta" è quella che fa il lavoro nel più breve tempo possibile.

+1

Grazie per i vostri approfondimenti. Ho completamente trascurato gli alberi di espressione linq. Proverò a modificare il mio parser per generare alberi usando questa API e fare alcuni test delle prestazioni sulla loro valutazione per confrontare con l'interpretazione/valutazione naive che sto facendo ora in F #. – Rickard

+1

Si noti che è possibile utilizzare le citazioni F # e nella libreria FSharp.PowerPack.Linq è possibile convertire l'espressione Quotazione F # in un albero di espressioni LINQ.Non c'è una tonnellata di documentazione su questo, tuttavia, ma potresti essere interessato. –