Il progetto

Come verificare che il compilatore compili se stesso, come si valutano le modifiche al linguaggio e quali sono i venti principi stampati da heroes this.

Come verificare che compili se stesso

Il compilatore di Heroes è scritto in Heroes. Compilarlo richiede dati annidati, tabelle di nomi, ricorsione, gestione degli errori e programmi distribuiti su più file. È una prova concreta di come il linguaggio gestisce un programma complesso.

Il repository, l’archivio del progetto, contiene il compilatore anche in un unico file C generato. Puoi compilarlo su un computer dove Heroes non è installato. Poi usi il compilatore ottenuto per tradurre i propri sorgenti in C e confronti i due file. Fallo su una release, la versione che il progetto ha pubblicato:

$ git checkout v0.5.0
$ clang -I runtime seed/heroes.c runtime/runtime.c -o heroes
$ ./heroes build selfhost/main.hero --emit-c -o out.c
$ cmp out.c seed/heroes.c
                    (cmp non stampa niente: non un byte di differenza)

  seed/heroes.c   il C che il repository contiene: la via d’ingresso
  out.c           quello che il compilatore scrive compilando se stesso

  oltre venti megabyte di C, e più di 250.000 righe

Se i file sono identici, cmp non stampa nulla. Il confronto verifica che il compilatore ricostruisca lo stesso C da cui è stato compilato. Il terzo comando richiede meno di due minuti su un MacBook Air. La prova può ripeterla chiunque: il repository è aperto e i quattro comandi sono tutto quello che serve.

Tra una release e l’altra il file C generato è il compilatore di un giorno precedente. Costruisce quello di oggi dai sorgenti in Heroes, e quello si riproduce identico un passo dopo, cosa che il progetto controlla a ogni modifica. heroes --version dice quale dei due hai: la sua seconda riga è un’impronta dei sorgenti da cui è stato costruito.

• 680+moduli di Heroes
• 179krighe, e crescono
• 0TODO, FIXME o HACK nel compilatore
• 220+sedute di design nei record

Heroes implementa tutte le parti del compilatore: l’analisi delle parole e della struttura del codice, l’associazione dei nomi alle dichiarazioni, il controllo dei tipi, la rappresentazione intermedia del programma e i suoi controlli, la gestione della memoria, la traduzione in C, le verifiche sulle librerie esterne, i messaggi d’errore, il formattatore e i comandi.

Gli errori trovati compilando i propri sorgenti

Il nuovo compilatore ha inizialmente rifiutato i propri sorgenti: segnalava, per errore, una struttura che conteneva se stessa. L’indagine ha individuato difetti sia nel compilatore nuovo sia in quello precedente. Uno riguardava la sottolineatura dei messaggi d’errore, che copriva l’annotazione usata dal test per verificarla.

Compilare i sorgenti del compilatore mette alla prova molte forme del linguaggio nello stesso programma. Diversi difetti avevano la stessa causa: un salto di ciclo dentro un ramo di match saltava l’istruzione che aggiornava un indice gestito a mano.

L’ultima differenza tra i due file riguardava l’ordine delle righe. Nel compilatore precedente alcune liste erano già ordinate; nel nuovo serviva un ordinamento esplicito, come indicavano le note lasciate nei sorgenti. Le mappe non garantiscono un ordine: aggiungendo gli ordinamenti mancanti, i file sono diventati identici.

Come si valutano le modifiche al linguaggio · five years

Le modifiche alla sintassi, alle regole del linguaggio, ai messaggi d’errore o alla struttura del compilatore vengono esaminate da un panel di cinque seggi. Ogni seggio riceve materiale diverso e quattro possono porre un veto. Le modifiche interne al compilatore o al runtime, il codice di supporto all’esecuzione, passano da due dei cinque se non cambiano sintassi, messaggi d’errore o specifica.

• Il lettoreRiceve la specifica e programmi d’esempio, senza il documento di design né i sorgenti del compilatore. Verifica con prove concrete se il linguaggio si capisce. veto
• L’ingegnere del compilatoreEsamina i sorgenti e valuta quanto codice bisogna scrivere e mantenere per introdurre la modifica. veto
• Il pragmatico del CCompila il codice C necessario per usare una libreria da Heroes, oppure documenta perché la compilazione fallisce. veto
• Il guardiano della specificaConfronta il numero di token prima e dopo la modifica e verifica che la specifica rispetti il limite previsto. I token sono i frammenti di testo letti da un modello. veto
• Lo storicoDeve cercare sul web e citare date e fonti: un precedente senza fonte è inammissibile. Ha letto anche la storia dei linguaggi scritta dall’autore, e la usa per sapere dove guardare, non come fonte: un libro dell’autore di questo progetto non può fargli da prova. Dà consigli e non ha potere di veto.

Il panel sceglie la soluzione che ritiene più solida e completa e la sottopone all’autore per l’approvazione. Il lavoro prosegue in attesa della conferma. Se esiste un’alternativa più prudente, viene registrata perché l’autore possa valutarla. Dopo i cinque verdetti un sesto lettore, il critico di completezza, chiede che cosa nessuno ha elencato, e più di una volta la soluzione adottata è stata una via che nessun seggio aveva proposto.

Ogni seduta è registrata in un file nel repository, con i materiali esaminati, i verdetti e gli eventuali veti. Le sedute sono più di centocinquanta. Ogni modifica al linguaggio richiede questa revisione. Quello che il panel ha rifiutato, e chi ha detto no, ha una pagina sua: i no di Heroes →

Venti righe

heroes this stampa questi principi, inclusi nel compilatore. Qui sono riportati in inglese per rispettare il testo originale, comprese le citazioni di una canzone.

The Zen of Heroes

 1. This language begins with a tribute to David Bowie.
 2. It is made for language models; people can read it too.
 3. A model may have read everything; each page must still explain itself.
 4. What the eye can see is all there is: sound and vision.
 5. There is one way to say each thing; every program sings in the same voice.
 6. That way may not be obvious at first; the Starman already knows it.
 7. The semantics are familiar; the syntax is new.
 8. Turn and face the strange: every strange choice here is deliberate.
 9. Nothing changes behind your back; every change signs its name.
10. Every plausible mistake must become a compile error before the program runs.
11. Unless you mark the gap with ???: an honest hole beats a confident guess.
12. A compile-time error is an answer; a runtime error is an ambush.
13. An error should tell you how to fix the program. Anything less is a complaint.
14. Repeating a word is cheap; forgetting one can cost the whole program.
15. The specification stays small under pressure; every word must earn its place.
16. Crashes and leaks are bugs. Ashes to ashes: what Heroes takes, it returns.
17. When pretty code and safe code disagree, safe code wins.
18. There is no standard library; C is the man who sold the world.
19. Never crashing in the same car: what C might keep, Heroes assumes it keeps.
20. We can be heroes, just for one day.

La riga 10 esprime la tesi, la 18 il vincolo iniziale, la 19 quel che quel vincolo costa al confine con il C, e la 17 stabilisce la priorità quando due principi sono in conflitto. Perché il linguaggio è fatto così →

Cosa è costruito, e cosa viene dopo

La catena è una tabella nel repository, una riga per traguardo, chiusi prima e programmati dopo. Questa pagina la legge quando il sito viene generato: 71 traguardi chiusi di 92, e quello aperto è M-panic-location.

Quello che viene

Poi: quattro comandi e lo compili, oppure prenditi tutto il linguaggio in un file solo.