Newsgroup: it.comp.programmare
Titolo: Linguaggio dinamico tradotto in C

E' possibile creare un traduttore che converta un sorgente scritto in
un linguaggio a tipizzazione dinamica, in un sorgente C/C++ tale che
possa essere direttamente compilabile da GCC ad esempio?
Se si, quale contro ci potrebbero essere nell'uso di un tool simile?
Immagino che i sorgenti generati non sarebbero molto ottimizzati.

Noixe ha scritto:

Si', e' possibile, e in fatti ce ne sono. Cerca con un motore di 
ricerca: "xxx to c translator", virgolette incluse, dove xxx è il 
linguaggio che ti interessa, e troverai parecchie occorrenze. Molte meno 
se cerchi "xxx to c++ translator".
Il codice risultante certamente non e' meno efficiente di quello 
ottenibile da un interprete. Purtroppo spesso non e' neanche molto piu' 
efficiente, e quindi non ne vale la pena.
Tuttavia, con un po' di sforzo, e' possibile ottenere del codice 
notevolmente piu' efficiente del codice interpretato. Questo si puo' 
ottenere grazie alla tecnologia della "type interence".
In sostanza, dato che il linguaggio e' dinamico, normalmente una 
variabile del linguaggio viene tradotta in C da un puntatore non 
tipizzato e l'oggetto puntato da tale variabile deve essere allocato 
sullo heap. Tuttavia, quando dal contesto si deduce che una variabile e' 
usata esclusivamente per maneggiare oggetti di un solo tipo, si puo' 
sostituire tale variabile con un oggetto di quel tipo, con un grande 
vantaggio prestazionale, se tale tipo e' uno di quelli primitivi del 
linguaggio C.
Gli svantaggi che mi vengono in mente nell'uso di tali traduttori sono:
* la traduzione in C richiede piu' tempo della traduzione in bytecode;
* la traduzione da C a linguaggio macchina richiede piu' tempo della 
traduzione da bytecode a linguaggio macchina;
* il codice C potrebbe essere meno portabile del codice originale;
* il programma risultante occupa piu' spazio su disco del programma in 
bytecode.
-- 
Carlo Milanesi
http://digilander.libero.it/carlmila

Ho trovato Shed Skin che converte da Python a C++, ma ho letto sul blog 
dell'autore che ci ha lavorato circa 5 anni e che supporta solo un 
sottoinsieme di Python. Insomma, deve trattarsi di un lavoro piuttosto 
complicato :-P 

Noixe ha scritto:

Avevi scritto: "quale contro ci potrebbero essere nell'uso di un tool 
simile?"
Non: "quale contro ci potrebbero essere nel creare un tool simile?"
Quando si valuta se adottare un linguaggio di programmazione, 
solitamente non ci si chiede quando tempo c'e' voluto per scriverne il 
compilatore.
Sicuramente non e' economicamente giustificabile lo sforzo di creare un 
traduttore di questo tipo per solo uso interno, a meno di essere 
un'azienda con centinaia di programmatori.


 un'azienda con centinaia di programmatori.
A parte gli aspetti economici, c'� anche la soddisfazione personale ;-) 

 * il codice C potrebbe essere meno portabile del codice originale;
Potrebbe. Ovviamente facendo le cose per bene non e' cosi'. Non a caso
molti linguaggi funzionali hanno un backend to C come emergenza per le
architetture per cui non e' stato implementato un backend nativo. Quindi
direi proprio per motivi di portabilita'.
-- 
-riko

 che sia un grosso problema (ne un grosso vantaggio).
Quanto ai vantaggi, mi chiedevo se, proprio in virtù del fatto che uno dei 
linguaggi intermedi possa essere il C, si potesse avere una maggiore 
possibilità di usare librerie scritte in C, ma non caricando funzioni da 
moduli esterni dinamicamente, bensì sfruttando direttamente i sorgenti. In 
tal caso, dato che C è un linguaggio stradiffuso, mi sembra un vantaggio non 
indifferente.
Inoltre, prendendo ad esempio la gestione delle classi, secondo te sarebbe 
più performante un sorgente generato in C++, o l'equivalente in C, nel quale 
la OOP dovrebbe poi essere simulata tramite struct, puntatori ai membri, 
etc...
Insomma ho idea che il codice C generato forse risulterebbe troppo sporco, e 
che un codice C++ sarebbe meglio.
Ma forse (anzi sicuramente) ciò che appare poco performante agli occhi del 
programmatore, non lo è agli occhi del compilatore. 

 programmatore, non lo è agli occhi del compilatore. 
Questo puo' essere o meno un problema. Puoi generare C pulito a piacere
e C++ sporco a piacere. Il punto e' quanto investi perche' il tuo
compilatore generi codice human-readable (anche a discapito delle
performance). 
Comunque studiati un po' di implementazioni di linguaggi funzionali.
Gambit genera codice C (e non dei piu' leggibili, ma molto veloce),
altri compilatori scheme hanno backend piu' attenti alla leggibilita;
anche Haskell ha compilatori-to-C, IIRC. 
Poi continui a parlare di oggetti, ma non tutti i linguaggi dinamici
sono ad oggetti. ;)
Se la questione e' "compilare linguaggi dinamici ad oggetti" guarda
Pypy. Direi che si fa presto a dire che e' lo stato dell'arte.
-- 
-riko

 Pypy. Direi che si fa presto a dire che e' lo stato dell'arte.
In effetti, se ricordo bene, PyPy oltre ad essere un inteprete python 
scritto in python, consente di generare una macchina virtuale Python in vari 
linguaggi, tra cui anche C e Java, tramite i tool chain. 

 linguaggi, tra cui anche C e Java, tramite i tool chain. 
Perche' non vieni al Pycon a sentire tutto quello che vale la pena di
sapere di Pypy, visto che ci sono alcuni sviluppatori principali a fare
un keynote?
-- 
-riko

 un keynote?
Ho letto in rete di questa manifestazione, l'anno scorso fu a Firenze, verso 
maggio se non erro.
Ma io abito piuttosto lontano da quelle zone, in ogni caso valuter� :) 

 Ma io abito piuttosto lontano da quelle zone, in ogni caso valuterò :)
La maggior parte dei partecipanti abitano lontano da Firenze. Fa parte
del concetto di "conferenza nazionale"... ;)
-- 
-riko

 del concetto di "conferenza nazionale"... ;)
Purtroppo c'è anche il concetto di "possibilità dello spostamento" da 
considerare, in base al periodo :-) 

 considerare, in base al periodo :-) 
Mi spiace, chiaro. :)
-- 
-riko