1) Qual è l'eventuale relazione tra la tipizzazione statica e le grammatiche formali?
2) In particolare, sarebbe possibile per un automa a limite lineare verificare se, per esempio, un programma C ++ o SML fosse ben tipizzato? Un automa pila nidificato?
3) Esiste un modo naturale per esprimere regole di battitura statiche in termini grammaticali formali?
Risposte:
Non è possibile per gli automi limitati lineari verificare se i programmi C ++, e è improbabile che sia possibile per LBA e verificare se i programmi SML sono ben tipizzati. C ++ ha un sistema di tipi completo di Turing, poiché puoi codificare programmi arbitrari come metaprogrammi di template.
SML è più interessante. Ha un controllo del tipo decidibile, ma il problema è EXPTIME-complete. Quindi è improbabile che un LBA possa verificarlo, a meno che non ci sia un crollo molto sorprendente nella gerarchia della complessità. La ragione di ciò è che SML richiede l'inferenza del tipo e ci sono famiglie di programmi la cui dimensione cresce molto più velocemente della dimensione del programma. Ad esempio, considera il seguente programma:
fun delta x = (x, x) (* this has type 'a -> ('a * 'a), so its return value
has a type double the size of its argument *)
fun f1 x = delta (delta x) (* Now we use functions to iterate this process *)
fun f2 x = f1 (f1 x)
fun f3 x = f2 (f2 x) (* This function has a HUGE type *)
Per sistemi di tipo più semplice, come C o Pascal, credo che sia possibile per un LBA controllarlo.
All'inizio della ricerca sui linguaggi di programmazione, a volte le persone usavano le grammatiche di van Wingaarden (alias grammatiche a due livelli) per specificare i sistemi di tipi per i linguaggi di programmazione. Credo che Algol 68 sia stato specificato in questo modo. Tuttavia, mi è stato detto che questa tecnica è stata abbandonata per ragioni essenzialmente pragmatiche: si è rivelato piuttosto difficile per le persone scrivere grammatiche che specificavano ciò che pensavano di specificare! (In genere, le grammatiche che le persone hanno scritto hanno generato lingue più grandi di quanto intendessero.)
In questi giorni le persone usano regole di inferenza schematiche per specificare i sistemi di tipi, che è essenzialmente un modo per specificare i predicati come il punto meno fisso di una raccolta di clausole di Horn. La soddisfazione per le teorie di Horn del primo ordine è indecidibile in generale, quindi se vuoi catturare tutto ciò che fanno i teorici, qualunque sia il formalismo grammaticale che sceglierai sarà più forte di quanto sia realmente conveniente.
So che c'è stato del lavoro sull'uso delle grammatiche degli attributi per implementare i sistemi di tipi. Sostengono che ci sono alcuni vantaggi di ingegneria del software per questa scelta: vale a dire, le grammatiche degli attributi controllano il flusso di informazioni in modo molto rigoroso, e mi è stato detto che ciò semplifica la comprensione del programma.
Per quanto ne so, la correttezza dei tipi tende ad essere indecidibile per casi interessanti, quindi chiaramente le grammatiche formali non possono catturare tutti i sistemi di tipo a cui riesci a pensare.
So che i principali generatori di compilatori consentono predicati arbitrari per regole che impediscono l'esecuzione di una regola se il predicato non valuta true, ad es
{ type(e1) == type(e2) } (expression e1) '+' (expression e2). Questo concetto può essere facilmente formalizzato; restrizioni appropriate sui predicati consentiti possono quindi determinare la decidibilità da parte degli LBA.
Decidere tali predicati è almeno difficile rispetto al tempo di esecuzione, quindi immagino che le persone tendano a eseguire un'analisi iterativa, raccogliendo informazioni nella fase per verificare la fattibilità nella fase . Ad esempio, è possibile creare una tabella dei nomi in un passaggio e quindi verificare che tutte le variabili utilizzate siano (visibilmente) dichiarate in una seconda esecuzione.k + 1