ISO 7185:1990 dice questo circa commenti in § 6.1.8:
Se un commento è qualsiasi sequenza di caratteri e le separazioni di linee, contenente né} nè *), il costrutto
('{' | '(*') commento ('*)' | '}')
sarà un commento se né il {né il (* avviene all'interno di un personaggio-s tring o all'interno di un commento.
NOTE
- Un commento può quindi iniziare con
{ e terminano con *), o cominciare con (* e terminano con }.
- La sequenza
(*) non può verificarsi in un commento anche se la sequenza {) può.
In base a ciò, c'è essenzialmente un solo tipo di commento. Sebbene sia possibile iniziare un commento con { o (*, non è possibile utilizzare set di caratteri diversi per "avvolgere" altri commenti. Turbo Pascal, d'altra parte, ha due tipi di commenti, quelli che usano le parentesi e quelli che usano le parentesi.
Se si dispone di un commento doppietta in stile e racchiuso in un commento tra parentesi stile per creare (*{}*), ISO dice il commento è (*{} con *) sinistra sopra, che sarà un errore di sintassi nel codice, mentre Turbo Pascal dice il commento è (*{}*) senza testo.
Nessuno stile consente di racchiudere un commento già inserito in un altro insieme di delimitatori di commenti. Questo perché una volta che si avvolge un commento, il commento "interiore" cessa di essere trattato come un commento più. È solo un testo normale. Se si dispone di {(**)} e si desidera avvolgere in un commento in stile parentesi per rendere (*{(**)}*), ISO e Turbo Pascal entrambi dicono che il commento è (*{(**) con }*) rimasto.
Nelle modalità fpc e objfpc, Free Pascal supporta i commenti di nidificazione, quindi il mio esempio più recente sarebbe accettato come commento valido senza testo rimanente. The FPC documentation on the matter in realtà non lo dimostra. Esso fornisce sei esempi di commenti presumibilmente annidati:
{ Comment 1 (* comment 2 *) }
(* Comment 1 { comment 2 } *)
{ comment 1 // Comment 2 }
(* comment 1 // Comment 2 *)
// comment 1 (* comment 2 *)
// comment 1 { comment 2 }
Ma Turbo Pascal (o Delphi, per le ultime due righe), che abbiamo già stabilito non supporto di nidificazione, avrebbe accettato tutto di quelli come commenti perfettamente validi! FPC supporta davvero i commenti annidati, ma quegli esempi non lo illustrano. Ecco alcuni esempi di commenti nidificati:
{ Comment 1 { comment 2 } }
(* Comment 1 (* comment 2 *) *)
{ Comment 1 (* comment 2 { comment 3 } *) }
mi piacerebbe anche sostengo che terzo e quarto esempi di FPC sono in realtà controesempi per l'affermazione che FPC supporta i commenti annidati. Queste due linee non dovrebbero essere affatto commenti completi. Lo // nel mezzo della riga introduce un commento che non termina fino alla fine della riga (EOL). L'EOL viene dopo il il } e *), quindi il commento interno di tipo barra non può essere terminato quando raggiungiamo il delimitatore di parentesi graffa o parentesi. Proprio come lo <a> <b> </a> </b> è un XML annidato in modo errato, abbiamo commenti nidificati erroneamente: { // } EOL.
Dopo ulteriori sperimentazioni, concludo che in FPC, solo i commenti dello stesso tipo nidificano. Ad esempio, una volta aperto un commento con {, i caratteri (* cessano di essere speciali. FPC non aprirà un commento in stile parentesi all'interno del commento in stile controvento.Se così fosse, allora {(*} sarebbe un errore di sintassi dovuto al commento di parentesi non terminata. Potremmo spiegare questo dicendo che la terminazione dei commenti interni è facoltativa quando i commenti sono eterogenei, ma è una spiegazione più semplice per dire che il commento interno non viene rilevato come un commento. Una volta aperto un commento in stile controvento, solo le parentesi hanno un significato. Inoltre, // non avvia effettivamente un commento in stile barra quando è all'interno di parentesi graffe. Questa è una spiegazione più semplice per dire che FPC consente ai commenti in stile slash di essere annidati in modo errato. Si può dire che i commenti in stile barra non nidificano affatto, o che i commenti in stile barra nidificati all'interno di altri commenti in stile barra condividono un singolo terminatore EOL.
Il tuo compito probabilmente significava che tu usassi lo stile Turbo Pascal, dove i delimitatori di commento devono corrispondere. Sicuramente non ti aspettavi che tu usassi lo stile Free Pascal poiché avrebbe reso impossibile completare il compito - un DFA non può accettare costrutti arbitrariamente annidati.
Questo mi sembra una domanda si dovrebbe chiedere il vostro istruttore. Controlla anche il tuo libro di testo. –
@Rob Kennedy il mio istruttore e ne ho parlato prima di pubblicare la domanda, e ho già risolto il problema a suo piacimento. Il libro non ci stava cercando di approfondire la questione, ma mi piace essere completo. Inoltre, come ho affermato nella domanda, il libro non è specifico su quale versione di Pascal dovrebbe essere considerata, e poiché il libro è un libro di compilazione e non un libro di Pascal, le convenzioni di commento della lingua non sono definite esplicitamente, e questo è quello che sto cercando nella mia domanda e definizione esplicita. – ubiquibacon