Newsgroup: it.comp.programmare
Titolo: Compilatori, linguaggi e keywords

Supponiamo di avere due linguaggi diversi, il linguaggio A con 100 token 
(keyword, operatori, ecc.) e il linguaggio B con 200 token.
Quale sarà, in linea di principio, la differenza di velocità dei 
rispettivi compilatori? Quanto impatta sulle prestazioni velocistiche di 
un compilatore (o solo del parser?) la quantità di token diversi che 
deve riconoscere? E sulla memoria che deve usare?
qualcuno sa dove trovare materiale a riguardo? Una prima ricerca su 
google non mi dà niente di significativo.

 google non mi dà niente di significativo.
Passo. E' passato troppo tempo da quando mi dedicavo a queste cose.

 deve riconoscere? E sulla memoria che deve usare?
minima, "quasi zero". La cosa ha effetto solo sul parser e
mi è bastato vedere i sorgenti generati da yacc per capire
che razza di mostruose ottimizzazioni si possano fare. Con
l'hardware di oggi penso che una differenza si possa
iniziare ad apprezzare su almeno tre ordini di grandezza
di quantità di tokens (ma questa è solo una mia sensazione).
-- 
Un corpo immerso in un liquido si bagna.
Un corpo immerso nel cemento sapeva troppo.
Un corpo immerso in un altro corpo si diverte.
Un corpo immerso in due corpi è un'orgia.

 di quantità di tokens (ma questa è solo una mia sensazione).
Ti dirò che anch'io avevo questa sensazione... ma vorrei fondarla su 
qualcosa di più solido.
"con l'hardware di oggi": è quello che penso anche io.
I linguaggi storici (C, pascal, java ecc.) sono tutti composti da poche 
decine di keyword, ma credo appunto che sia una cosa "ereditata" da 
quando memoria e CPU erano preziosi, costrizioni imposte dalle macchine 
di allora e mai più messe in discussione, forse perché nessuno ha mai 
seriamente pensato che un numero maggiore potesse essere più utile.
Se non c'è (oggi) un problema di prestazioni a fare un linguaggio con 
tante keyword, allora perché non è mai stato fatto?
Io credo che sarebbe un tentativo molto, molto interessante.

 molto interessante.
Avrebbe una grande serie di problemi collaterali tra cui
una forte restrizione sui nomi degli identificatori per
evitare confusioni e il fatto che se si vuole partire dal
dover per forza avere tantissime keyword, l'unica strada
mi pare invadere lo spazio delle librerie, con la
terrificante confusione che ne seguirebbe.
Piuttosto mi chiedo: c'è qualche ragione del perché
sarebbe necessario un linguaggio con tantissime parole
chiave? Fin dall'inizio dei tempi dei PC sarebbe stato
possibile.
ciao!
Apx.


 possibile.
All'inizio dei tempi magari era pure possibile in teoria, ma a parte i 
problemi di memoria e di potenza di calcolo, era già tanto riuscire a 
scrivere un compilatore per un linguaggio piccolo, figuriamoci per uno 
come lo immagino io :-)
Alla fin fine tutti i linguaggi esistenti al mondo (vabbè, quelli che 
conosco io) sono rimasti concettualmente alla subroutine: una keyword 
definita dall'utente che "sta al posto di" un gruppo più o meno grande 
di altre keyword.
Di base il mio ragionamento è: se con un linguaggio che ha un 
vocabolario di 50 parole un programma viene lungo 10.000 righe, 
prendendo un linguaggio con 1000 parole di vocabolario dovrei poter 
scrivere lo stesso programma con un numero di righe molto minore.
Come dici tu, questo oggi si fa già, però usando funzioni di libreria 
che estendono un linguaggio base da 50 parole di vocabolario. io mi 
chiedo: è possibile farlo SENZA usare librerie, ma con un linguaggio che 
usi tante keyword MA in modo diverso da come si usano oggi?
Io credo di sì... ma come lo dimostro? :-|

 usi tante keyword MA in modo diverso da come si usano oggi?
Con amore dal 1958. ;)
-- 
-riko
http://www.enrico-franchi.org/
http://rik0-techtemple.blogspot.com/

 qualcosa di più solido.
Non e' difficile. Prendi un libro sui compilatori: guardati gli
algoritmi sul parsing. Individua i punti in cui la cosa e' rilevante.
Vedi che sono pochi, specie rispetto ad altre cose. Per esempio sul
parsing e' molto piu' un problema dover fare backtracking perche' la
grammatica risolve le ambiguita' molto tardi, o peggio ancora non poter
stabilire cosa sia un certo simbolo fino alla fine del processo di
parsing e poi tornare indietro (come in C++).
Il tutto, poi, e' essenzialmente irrilevante rispetto a quello che va
fatto per ottimizzare il codice. 
