Cosa impedisce un'efficiente macchina virtuale Haskell (come JVM)?

Question

Mi sono chiesto, cosa impedisce lo sviluppo di una macchina virtuale efficiente come JVM o PyPy per Haskell (tranne forse lo sforzo di sviluppo)? È la struttura del linguaggio? Penso che i linguaggi, che sono più difficili da interpretare in modo efficiente (come Python, essendo molto dinamico), abbiano già macchine virtuali decenti.

Inoltre, se nulla ostacola una tale implementazione, STG sarebbe un buon target "bytecode", dal momento che tutte le ottimizzazioni vengono eseguite su Core?

Ci sono articoli o post di blog che trattano questo argomento?

modifiche:

• Sono consapevole del HaLVM, ma non credo che è quello che voglio dire.
• Sono anche a conoscenza di runhaskell, ma non è affatto efficiente.

Answer 1

Cosa impedisce un'efficiente macchina virtuale Haskell?

Nulla - ce n'era già uno, l'LVM di Daan Leijen. È stato abbastanza efficiente da essere utilizzato per il sistema di runtime di elio (la "lingua di insegnamento" Haskell dell'Università di Utrecht).

Detto questo non so se viene utilizzato in questi giorni, quindi la domanda "Cosa impedisce un'efficiente macchina virtuale Haskell?" potrebbe rispondere come manodopera, investimento continuo, ecc. Quando Haskell ha già un buon compilatore, una buona VM è un lusso come già notato da Paulo Pinto.

Answer 2

Non ho un modo per inviare un commento, e questo è forse ancora più di un anti-VM di un compilatore di codice nativo è, ma l'OP potrebbe essere interessato al Reduceron.

Answer 3

UHC dispone di un back-end Javascript che viene eseguito sul motore JavaScript di un browser. Voglio dire, non vedo nulla che impedisca a Haskell di puntare a diversi backend. In effetti, penso che UHC sia stato progettato per facilitare il targeting di backend diversi.

Answer 4

Non sono a conoscenza di alcuna restrizione tecnica applicabile qui. Esiste un linguaggio chiamato Frege, semanticamente vicino a Haskell, che si rivolge a JVM. Quindi è solo che nessuno ha considerato finora che un compilatore Haskell-to-JVM valeva la pena. In effetti, da scettico JVM, mi chiedo cosa potrebbe comportare. Se si tratta solo della portabilità linguistica intermedia, preferirei lavorare su LLVM o su una farm binaria precostruita.

Answer 5

Niente. Vedi lambdachine. Ecco alcuni short notes.

Answer 6

Niente impedisce a Haskell di avere una VM. Haskell funziona magnificamente sulla JVM e può essere persino più veloce di GHC dopo il riscaldamento JIT nei casi in cui il codice generato colpisce il punto debole del compilatore JIT. Vedere Eta, un progetto che porta GHC 7.10.3 Haskell completo sulla JVM con interoperabilità Java sicura dal tipo. Richiede solo molta pazienza e tempo per lavorare.