<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-24 17:57 GMT+01:00 Alessandro Re <span dir="ltr"><<a href="mailto:ale@ale-re.net" target="_blank">ale@ale-re.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2015-06-21 20:12 GMT+01:00 enrico franchi <<a href="mailto:enrico.franchi@gmail.com">enrico.franchi@gmail.com</a>>:<br>
<br>
Porca vacca, non mi ero accorto di questa risposta interessante!<br>
<span class=""><br>
> C'e' una leggera sottigliezza che pero' e' chiave.<br>
<br>
> Intanto i linguaggi di programmazione per la maggior parte *non* sono<br>
> context-free. Punto e fine della fiera.<br>
<br>
</span>Questa mi ha un po' sorpreso, ma nel senso che sono ignorante in<br>
materia e quindi non avrei mai saputo dare una statistica. Ma la<br>
domanda che mi scatta immediatamente è: parli in generale (includendo<br>
anche DSL e tutti i linguaggetti del mondo che i vari programmatori<br>
inventano un giorno sì e l'altro anche per qualsivoglia motivo) o ti<br>
riferisci ai linguaggi general purpose (o ad un loro subset)?<br></blockquote><div><br></div><div>Ok, scusa, non intenderla in senso statistico. Diciamo cosi', la maggior parte dei linguaggi general purpose di una certa diffusione *non* sono context-free.</div><div><br></div><div>In generale, quando hai typing statico non puoi essere context free. Per esempio in C una chiamata a funzione e' valida solo se quella funzione e' stata definita: quindi *dipende dal contesto*. Ma piu' semplicemente 'a * b;' e' una moltiplicazione fra due variabili oppure e' la dichiarazione di una variabile b di tipo puntatore ad a?</div><div><br></div><div>C++ non e' manco context-sensitive (se cerchi su Google un tizio ha fatto un programma che compila se e solo se un certo numero e' primo). </div><div><br></div><div>Poi ci sono linguaggi come Ruby dove addirittura si ricorre a delle euristiche per capire chi e' cosa [ non ho dimostrato matematicamente che questo implica non essere ctx free, ma mi pare andare in questa direzione. Poi puoi fare delle porcate con gli here docs che non mi paiono context free. </div><div><br></div><div>Java e' relativamente context free. E' definito tramite 3 grammatiche che vengono dette context free, anche se ci sono un po' di ambiguita' che sono risolte implicitamente. In generale e' veramente complicato da dimostrare. Il problema e' che e' possibile che la logica "aggiunta" per risolvere le ambiguita' in effetti non sia context-free.</div><div><br></div><div>Go mi risulta essere ctx-free. </div><div><br></div><div>Ma veniamo a Python... Python e' chiaramente non context free. Come? Ma... Gia'.</div><div><br></div><div>Allora... cosa e' un linguaggio di programmazione? Per dire, su quale alfabeto e' definito? Se lo definisci sull'alfabeto dei token di output del lexer, allora Python e' context-free. Pero', effettivamente, il *linguaggio* Python e' definito sopra un alfabeto che per semplicita' consideriamo ASCII.</div><div><br></div><div>Nota, non mi e' chiaro l'impatto del fatto che puoi scrivere Python l'encoding del file (e che a seconda dell'encoding puoi, potenzialmente, avere qualcosa che parsa o non parsa). </div><div><br></div><div>Il punto chiave, una volta che decidiamo che ci limitiamo ad ASCII, e' che il lexer di Python e' troppo potente. Sai che lui converte i vari spazi e tabs in <INDENT> e <DEDENT>. Il punto e' che di fatto se non lo facessi dovresti essere in grado di matchare il livello di indentazione per capire l'albero di sintassi astratta. Oltretutto il comportamento del whitespace cambia a seconda che tu sia o meno all'interno di parentesi tonde. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tra l'altro, per non essere troppo OT, sbaglio o Python ha come scelta<br>
di design quella di essere context free? Oppure anche il nostro amato<br>
linguaggio ricade nella categoria dei "CFG + epsilon"?<br></blockquote><div><br></div><div>E' una sottigliezza.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> In altre parole, Alessandro, hai spiegato bene perche' e' complicato parsare<br>
> Tex, pero' di per se quella e' solo una parte del problema: l'assenza di<br>
> modularita' nel compilatore ufficiale e' quello che chiude il cerchio del<br>
> macello.<br>
<br>
</span>Non sapevo questa cosa, ma non so perché non mi sorprende :D<br>
<span class=""><br>
> Detto questo, credo che ad oggi molti documenti siano puro latex che non<br>
> chiamano direttamente tex. E, sempre che io sappia (ma non sono certo)<br>
> latex, fintanto che non usa direttamente tex, e' sensibilmente piu'<br>
> semplice. Quindi e' vero che una libreria che deve gestire tex arbitrario e'<br>
> un incubo, ma forse una libreria che gestisce latex e un subset ristretto di<br>
> tex potrebbe coprire il 95% degli utilizzi con uno sforzo che e' il 5% di<br>
> quello per re-implementare completamente un front-end per tex.<br>
<br>
</span>Ecco un'altra cosa che mi sorprende, per ignoranza: io conoscevo LaTeX<br>
come "un insieme di macro costruite su TeX" e quindi pensavo che<br>
passare per TeX fosse necessario, ma ammetto che la mia conoscenza<br>
dell'argomento TeX/LaTeX è *veramente* limitata.<br></blockquote><div><br></div><div>No, aspetta. Latex e' un set di macro costruite su tex, che in piu' "consente" di avere tex sparso in giro.</div><div><br></div><div> parsare tex o latex e' diverso che "valutarlo". se tu non avessi la possibilita' di embeddare tex, credo che anche valutare un qualunque documento latex sarebbe piu' facile. Io ricordo aggeggi che addirittura valutano latex e generano cose senza passare per il vero e proprio aggeggio. Il fatto e' che di fatto non sono capace di capire veramente latex come dovrebbe essere, ci sono parti di latex che non sanno gestire e tantomeno sanno gestire tex. Di fatto quindi per documenti "semplici" qualcosa combinano, per quelli complessi non combinano nulla.</div><div><br></div><div>Ora anche solo parsare tex e' un dito al culo (per il motivo che accennavi). Di fatto non puoi parsare tex senza "capire" tex. A me non risulta che la stessa proprieta' valga per latex se escludi la possibilita' di ficcare tex arbitrario qua e la. La mia idea e' che per parsare del latex *senza* tex embeddato tecniche relativmaente convenzionali dovrebbero bastare. Poi non mi e' chiaro cosa fai con l'AST... probabilmente per certe trasformazioni puoi cavartela, per altre no.</div><div><br></div><div>Nota, sto parlando a braccio. </div><div><br></div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>