Domanda

Nella mia lettura sulla tipizzazione dinamica e statica, io continuo a contro l'ipotesi che i linguaggi staticamente tipizzati sono compilati, mentre le lingue dinamicamente tipizzati sono interpretati. So che, in generale, questo è vero, ma io sono interessato alle eccezioni.

Mi piacerebbe davvero che qualcuno di dare non solo alcuni esempi di queste eccezioni, ma cercare di spiegare il motivo per cui si è deciso che queste lingue dovrebbero lavorare in questo modo.

È stato utile?

Soluzione

Ecco un elenco di alcuni sistemi interessanti. Si tratta di non esaustivo!

dinamicamente tipizzati e compilati

  1. Il compilatore Gambit Scheme, Chez Scheme , Larceny Scheme compilatore di Will Clinger, il Bigloo compilatore Scheme, e probabilmente molti altri.

      

    Perché?

    Un sacco di gente piace molto Scheme. Programmi come dati, buon sistema di macro, 35 anni di sviluppo, grandi comunità. Ma vogliono prestazioni. Quindi, una serie di buone compilatori-Chez codice nativo Scheme è anche un prodotto di successo commerciale (bytecode interpretati sono liberi, codici nativi si paga).

  2. Il LuaJIT just-in-time compilatore per Lua .

      

    Perché?

    Per vederlo potrebbe essere fatto. E poi, la gente ha iniziato a come di ottenere aumento di velocità 3x sui loro programmi Lua. Lua è in un sacco di giochi, dove la performance è, in più è strisciante in altri prodotti troppo. Il 70% del codice in Adobe Lightroom è Lua.

  3. Il iconc Icona compilatore-to-C.

      

    Perché?

    Le cinquanta persone che lo utilizzavano amato icona. Totalmente insolito modello di valutazione, il più innovativo (e, a mio parere, meglio) sistema di stringhe di elaborazione mai progettato. Ma questo modello di valutazione è stato molto costoso, specialmente su computer fine degli anni 1980. Con la compilazione di Icon a C, il progetto Icona ha reso possibile per i grandi programmi di icone per l'esecuzione in un minor numero di ore.

Conclusione : le persone prima di sviluppare un allegato a un linguaggio tipizzato in modo dinamico, e probabilmente una base di codice significativo. Alla fine, la comunità sputa fuori un compilatore di codice nativo in modo da poter ottenere prestazioni migliori e risolvere i problemi più grandi.

tipi statici e interpretato

Questa categoria è meno comune, ma ...

  1. Obiettivo Caml . Dialetto di ML, veicolo per un sacco di esperimenti innovativi nel design lingua.

      

    Perché?

    Sistema molto portabile e tempi di compilazione molto veloci. Persone come entrambe le proprietà, in modo che le nuove idee lingua-design sono ampiamente desseminated.

  2. Mosca ML. Standard ml con alcune caratteristiche extra del sistema di moduli.

      

    Perché?

    portatili, i tempi di compilazione veloce, facile fare una lettura / eval / ciclo di stampa interattivo. È diventato un compilatore insegnamento popolare.

  3. C-Terp. Un vecchio prodotto, penso che forse da Gimpel Software. Sabre C-un prodotto non credo è possibile acquistare qualsiasi altro ancora.

      

    Perché?

    Debug. In particolare, il debug sul 1980 hardware sotto MS-DOS. Per poche risorse, si potrebbe ottenere davvero un buon codice di aiuto di debug C su hardware molto limitato (si pensi: processore 4.77MHz con un bus a 8 bit, 640K di RAM a pieno carico). Quasi impossibile ottenere un buon debugger visuale per il codice nativo compilato, ma con l'interprete, abbastanza facile.

  4. UCSD Pascal-sistema che rende la "P-code" una parola familiare.

      

    Perché?

    Gli insegnanti è piaciuto il design il linguaggio di Niklaus Wirth, e il compilatore potrebbe funzionare su molto macchine di piccole dimensioni. design pulito di Wirth e il P-sistema di UCSD fatto una combinazione imbattibile, e Pascal era il insegnamento delle lingue standard degli anni 1970. I giovani possono trovare difficile apprezzare che nel 1970 ci fu non dibattito su quale lingua per insegnare al primo corso. Oggi so di programmi utilizzando C, C ++, Haskell, Java, ML, e Scheme. Nel 1970 è stato sempre Pascal, e l'UCSD P-system è stato un modo grande motivo.

    Nel caso in cui vi state chiedendo, P stava per portatile .

Riepilogo : Interpretare un linguaggio a tipizzazione statica è un ottimo modo per ottenere un'implementazione nelle mani di tutti rapidamente. (Aveva anche vantaggi per il debug su hardware età del bronzo).

Altri suggerimenti

Objective-C viene compilato e supporta la tipizzazione dinamica (certamente quando si chiama metodi tramite la sintassi [target doSomething]). Cioè, è possibile inviare qualsiasi messaggio a un target (utilizzando la sintassi del linguaggio ordinario, senza programmazione contro un API di riflessione), ricevono solo un avvertimento al momento della compilazione che potrebbe non essere maneggiato, e ricevere un'eccezione solo in fase di esecuzione se l'obiettivo doesn 't rispondere a tale selettore (che è come una firma metodo); e si può chiedere a qualsiasi oggetto (che può essere tutti di tipo id statico se il codice non conosce di meglio o non si cura) se si respondsToSelector: per sondare le sue capacità.

Java (un linguaggio a tipizzazione statica) viene compilato in bytecode JVM, che è stato interpretato su versioni precedenti di JVM, mentre ora utilizza la compilazione Just In Time (JIT), che significa codice macchina viene generato in fase di esecuzione. Credo anche ML e dei suoi dialetti possono essere interpretati, e ML è sicuramente tipizzazione statica.

Actionscript ha tipizzazione dinamica e compila a bytecode.

E compila anche fino al codice macchina nativo se si desidera rilasciare un'applicazione Flash su iPhone.

Python è un linguaggio dinamico che ha compilatori.

questa domanda SO -. Python - why compile?, per esempio

In generale, compilazione rende il programma molto più veloce.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top