[Python] \b e \r in file di testo

[enrico franchi]

2015-06-24 17:57 GMT+01:00 Alessandro Re <ale a ale-re.net>:

> 2015-06-21 20:12 GMT+01:00 enrico franchi <enrico.franchi a gmail.com>:
>
> Porca vacca, non mi ero accorto di questa risposta interessante!
>
> > C'e' una leggera sottigliezza che pero' e' chiave.
>
> > Intanto i linguaggi di programmazione per la maggior parte *non* sono
> > context-free. Punto e fine della fiera.
>
> Questa mi ha un po' sorpreso, ma nel senso che sono ignorante in
> materia e quindi non avrei mai saputo dare una statistica. Ma la
> domanda che mi scatta immediatamente è: parli in generale (includendo
> anche DSL e tutti i linguaggetti del mondo che i vari programmatori
> inventano un giorno sì e l'altro anche per qualsivoglia motivo) o ti
> riferisci ai linguaggi general purpose (o ad un loro subset)?
>

Ok, scusa, non intenderla in senso statistico. Diciamo cosi', la maggior
parte dei linguaggi general purpose di una certa diffusione *non* sono
context-free.

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?

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).

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.

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.

Go mi risulta essere ctx-free.

Ma veniamo a Python... Python e' chiaramente non context free. Come? Ma...
Gia'.

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.

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).

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.


Tra l'altro, per non essere troppo OT, sbaglio o Python ha come scelta
> di design quella di essere context free? Oppure anche il nostro amato
> linguaggio ricade nella categoria dei "CFG + epsilon"?
>

E' una sottigliezza.


>
> > In altre parole, Alessandro, hai spiegato bene perche' e' complicato
> parsare
> > Tex, pero' di per se quella e' solo una parte del problema: l'assenza di
> > modularita' nel compilatore ufficiale e' quello che chiude il cerchio del
> > macello.
>
> Non sapevo questa cosa, ma non so perché non mi sorprende :D
>
> > Detto questo, credo che ad oggi molti documenti siano puro latex che non
> > chiamano direttamente tex. E, sempre che io sappia (ma non sono certo)
> > latex, fintanto che non usa direttamente tex, e' sensibilmente piu'
> > semplice. Quindi e' vero che una libreria che deve gestire tex
> arbitrario e'
> > un incubo, ma forse una libreria che gestisce latex e un subset
> ristretto di
> > tex potrebbe coprire il 95% degli utilizzi con uno sforzo che e' il 5% di
> > quello per re-implementare completamente un front-end per tex.
>
> Ecco un'altra cosa che mi sorprende, per ignoranza: io conoscevo LaTeX
> come "un insieme di macro costruite su TeX" e quindi pensavo che
> passare per TeX fosse necessario, ma ammetto che la mia conoscenza
> dell'argomento TeX/LaTeX è *veramente* limitata.
>

No, aspetta. Latex e' un set di macro costruite su tex, che in piu'
"consente" di avere tex sparso in giro.

 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.

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.

Nota, sto parlando a braccio.

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150625/d2adc601/attachment.html>