Specifica intuitiva per i nomi dei file

[lucat1]

Le regexp sono poco potenti (a volte), stringenti, o non chiare (sempre):
Si potrebbe migliorare la vita delle persone usando qualcosa di più espressivo e chiaro:
Se per le specifiche usassimo una sintassi a-la bnf tipo questa: (la BNF viene spiegata a programmazione il primo anno, quindi è più o meno chiara a tutti):

data := \d{4}-\d{2}-\d{2}
tipo := scritto|orale
fila := a|b
formato := testo|soluzione
extra := [a-Z]*
ext := pdf|doc(x)|..

nome = $data-$tipo-?fila-$formato-?extra.$ext

Questo approccio, rispetto alle regexp in line attuali, avrebbe una serie di vantaggi:

1. Possiamo continuare ad usare regexp dove sono pratiche, per dire "voglio 4 digit" sono molto concise e abbastanza chiare. In ogni caso, doeterei questo piccolo DLS di commenti o specifiche extra, che sarebbero utili per il punto 5.
2. Dare un nome alle varie parti della regexp aiuta molto però (un po' come fa gorrieri con le definizioni regolari).
3. Ci risparmiano errori e consentono il riuso: possiamo avere un file con una lista di definizioni base e poi mettere un sistema di inclusione in modo che non dobbiamo ridefinire ogni volta cosa è una data, ma possiamo usare la definizione già scritta e condividerla su tutte le regole.
4. Ci consente anche di gestire casi che non sono copribili con le regexp. Possiamo inventarci un modo per specificare una regola "counter" che, in base al numero di file nella cartella, richiede che quel segmento inizi con n zeri, per motivi di sorting (i.e., se la cartella ha 100 file, bisogna chiamare il file n1: 001 e il file n50 050). Questo particolare esempio va considerato con cautela (valutare la validità sapendo sempre il numero di file in una cartella è una assunzione forte), ma non c'è dubbio che ci lascerebbe più libertà.
5. (quello che ha scaturito questa ide) Ci consente di spiegare chiaramente come sono composti i nomi dei file (le regexp non sono comprensibili, siamo onesti). Quello che mi immaginavo è: io posso analizzare questa specifica e creare un prompt interattivo per l'utente dove gli chiedo prima la data, poi il tipo di prova (e uso un select perchè ci sono solo due opzioni) ecc ecc. Così si rimuove tutto il guesswork che serve attualmente per trovare un nome che sia giusto. In più possiamo aggiungere commenti alle regole per spiegare meglio cosa inserire e fornire esempi.
6. miglioramenti futuri: i visualizzatori web (dynamik in questo caso) possono usare queste informazioni per fare sorting e filtri avanzati. È molto importante poter estrapolare queste informazioni dal nome del file per motivi di organizzazione e filtraggio.

Uno downside che vedo:
Non sono generali e supportate ovunque come le regexp. Dovremo scrivere un piccolo parser per gli strumenti dove voglaimo usarle. Soluzione: scriviamo questo piccolo DLS in un linguaggio di specifica di linguaggi (i.e., flex e yacc, ma realisticamente usiamo roba più moderna) che sia in grado di produrre parser per una serie di linguaggi comuni (i.e., almeno js e qualcosa di basso livello tipo go/c/rust/etc). Possiamo guardare su wikipedia cosa è disponibile:
https://en.wikipedia.org/wiki/Comparison_of_parser_generators

[LiberaLongo]

modificherei la riga di nome in

nome = $tipo-$data-?fila-$formato-?extra.$ext

e aggiungerei note nella forma:

Nota regexp:
\d --> digit --> cifra
$ --> obbligatorio
? --> opzionale
spiegazione - e tipi opzionali

[lucat1]

Si, sicuramente dovremo documentare tutto e sistemare l'esempio. Il codice che c'è per ora è solo per rendere l'idea.

[foxyseta]

Va detto che le regexp sono supportate dalle librerie standard dei linguaggi in genere, mentre altre formalismi no.

Siccome abbiamo pochissime regexp, potremmo anche documentarle in stile BNF e lasciarle così.
Se invece proprio le regexp vanno abbandonate, sarebbe carino almeno cercare qualcosa che abbia un parser già fatto nei linguaggi che usiamo.

[lucat1]

Si è l'ultimo punto che ho scritto ed è quello che preme anche me.

• Per il lavoro che dovrei fare sul frontend è comodo avere questa sintassi (punto 5).
• La mia paura con i commenti è che potrebbero essere non aggiornati rispetto alla regexp (un DSL ti forza).
• In più, dovrei comunque fare il parsing dei commenti che dovrebbero essere scritti in un certo formato macchinoso. Dovrei sempre avere un parser.

Quello a cui ho pensato ora è che in realtà ci basta una implementazione del parser: neanche deve essere in un linguaggio particolare. L'importante è che questo parser/compilatore generi una regexp e una struttura json. La struttura JSON rappresenta più o meno l'AST e comunque descrive l'espressione regolare (e questa la posso usare dal web per fare i prompt per i nomi dei file) e invece l'espressione regolare la si può dare in pasto a tutti gli strumenti che usiamo ora.
Certo, secondo me se ce ne fosse una implementazione usabile dagli strumenti CI sarebbe più carino, perchè gli errori di cosa non va potrebbero essere molto più chiari direi, però non è un must have.

[lucat1]

Il DSL è stato definito in csunibo/synta. La stessa repo contiene anche degli strumenti command line per farne formatting e conversione a regexp (di go, compatibili con js) o conversione a una nostra struttura json.
Ora che abbiamo questo linguaggio possiamo usarlo in csunibo/config per specificare i nomi dei file. Lavoriamo adesso a una riscrittura della action che controlla i nomi dei file, anche per avere un migliore supporto a cartelle che contengono file con nomi su cui non possiamo forzare la nostra nomenclautra: l'idea, spiegata meglio qua è che se una cartella ha il nome valido per un file (meno l'estensione), non ci entriamo ricorsivamente dentro a controllare i file