Come si classificherà il mio linguaggio personalizzato?

1

Sto sviluppando il mio linguaggio di scripting per risolvere alcune sfide uniche per un progetto.

La lingua prende il codice sorgente e converte il contenuto in token, quindi viene utilizzato un comando factory per convertire quei token in qualcosa che può essere eseguito.

Un esempio di uno script potrebbe assomigliare a questo.

accept: always;
reject: title has "something" or body has "something else";
reject: title length < 10;

Ogni riga nello script termina con un terminatore ; e ogni riga inizia con una regola denominata che termina con : . Ogni regola usa un comando seguito da argomenti. I comandi possono essere uniti usando operatori logici. Il numero di argomenti che può avere un comando è fisso. Quindi quando trovo un comando posso aspettarmi che il numero X di token aggiuntivi per la sintassi sia corretto. L'obiettivo è un codice leggibile dall'uomo perché i non programmatori lo useranno.

Un modo alternativo di scrivere lo stesso codice sopra usando una struttura in stile C. sarebbe

accept(true);
reject(has(title,"something") || has(body,"something else"));
reject(length(title) < 10);

Qual è il termine usato per un parser che gestisce una lingua in cui () per gli argomenti di strutturazione è omesso e non ci sono limiti definiti per gli argomenti.

Vorrei leggere come vengono implementati questi tipi di parser. Per assicurarmi di non reinventare eccessivamente la ruota o di incappare in problemi comuni.

    
posta cgTag 16.08.2013 - 11:46
fonte

2 risposte

1

LISP obbligatorio:

(accept t)
(reject-if (or (has title "something) (has body "something else")))
(reject-if (< (length title) 10)

FORTH obbligatorio:

1 accept
"something" title has "something else" body has or reject-if
title length 10 < reject-if

La chiave è che non devi scrivere e eseguire il debug di un parser personalizzato per nessuno di questi approcci.

    
risposta data 16.08.2013 - 14:45
fonte
0

Vedi regola off-side .

Generalmente i token sono token, e le parentesi sono token (operatori in realtà) proprio come le parole chiave. Non avere parentesi significa che stai cercando di stare lontano dal paradigma della chiamata di funzioni, ma la semantica è ancora lì nei tuoi esempi per quanto posso dire. Quindi non sono sicuro se dovresti cercare la differenziazione dal parser piuttosto che dal livello dello scanner.

Un'altra strada da esplorare è l'implementazione di linguaggi dichiarativi / non procedurali come SQL.

    
risposta data 11.09.2013 - 18:10
fonte

Leggi altre domande sui tag