[nem-pl] Rozszerzenia składniowe

"Paweł W. Olszta" pawel.olszta at adv.pl
Tue Jun 22 21:10:17 CEST 2004


Michal Moskal wrote:

>>Je?li by doda? gwiazdk?, to mo?na zrobi? makro tworz?ce listy, tablice 
>>etc. (tzn. private x : list <int> = array [1, 2, 3]; i typ podobne)
> 
> To ju? jest zrobione :-)

Nope. Jest tak:

       | Tok_keyword ("array") =>
         match (get_token ()) {
           | Tok_operator ("[", _) =>
             def exprs = parse_list ();
             expect_operator ("]");
             E_mkarray (loc, exprs)

           | Tok_operator ("(", _) =>
             def exprs = operator_separated_list (",", parse_expr);
             expect_operator (")");
             E_empty_array (loc, exprs)

           | _ => fatal_error ("expected [ ... ] after `array'")
         }

To w pewnym sensie robi dokładnie to samo, co by robiły nowe 
rozszerzenia składniowe; powiedzmy że piszemy tak:

syntax "array" {
   | "[" (expr ",")+ "]" => ...
   | "(" (expr ",")+ ")" => ...
   | _ => fatal_error ...
}

Ja przez chwilę myślałem, że może dałoby się wywalić ten fragment kodu z 
parsera *i* na dodatek E_mkarray też -- zrobić makro, które generuje 
wywołanie do System.Array.CreateInstance, serię przypisań i w ogóle 
wszystko to, co robi E_mkarray. Tylko, że chyba zapomniałem o typowaniu.

Ale mimo wszystko możnaby uprościć parser ;]

P.S.: takie rozszerzenia składniowe naprawdę mogłyby udawać, że są 
wyrażeniami regularnymi -- nawet jeśli "expr" byłby bardziej 
skomplikowanym językiem, to wystarczyłoby w odpowiednim momencie 
zapuszczać rekurencyjnie parser i traktować jego wyjście jako token. 
Chyba ;]

-- 
"Any sufficiently complicated C or Fortran program contains
an ad hoc informally-specified bug-ridden slow implementation
of half of Common Lisp." -- Philip Greenspun




More information about the devel-pl mailing list