[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