Keresés

Azon is elgondolkoztam, hogy hogyan legyen a rekurzió, bal- vagy jobboldalasan:

#1
program: utasítás | utasítás program

#2

program: utasítás | program utasítás

Először naivan azt hittem, hogy az első a jobb módszer, de most a második felé hajlok.

Olyasmi tesztet végeztem, ahol az input 'változó=érték' utasításokból áll; ha különböző változókról van szó, akkor az értékadások sorrendje nem számít, de ha ugyanannak a változónak adok értéket kétszer (többször), akkor azt várnám, hogy az utolsó hajtódjon végre utolsónak (vagyis az jusson érvényre, ne az első).

A teszt szerint #1 esetén az első értékadás 'nyer', vagyis a végrehajtási sorrend fordított.

#2 esetén az utolsó értékadás jut érvényre, vagyis a végrehajtás sorrendje megegyezik az utasítás sorrendjével.

Kieg: Ezt találtam a témában olvasnivalónak

http://dinosaur.compilertools.net/yacc/index.html

Left Recursion

The algorithm used by the Yacc parser encourages so called ``left recursive'' grammar rules: rules of the form

name: name rest_of_rule ;

További érdekesség ezügyben, hogy a fejlődés során az YYPARSE_PARAM megszűnt létezni... valahogy azért sikerült egy kompatibilis állapotot létrehozni 3.0.2 és 2.5 között

#define YYLEX_PARAM pc

%pure-parser
%parse-param {parser_control *pc}
%lex-param {parser_control *pc}

Ebből a legelső sor azért kell, hogy a yylex hívásakor átmenjen a 'pc' paraméter a 2.5-ben, a 3.0.2-ben már nincs ez a rész:

#ifdef YYLEX_PARAM
# define YYLEX yylex (&yylval, YYLEX_PARAM)
#else
# define YYLEX yylex (&yylval, pc)
#endif

Túlreagáltam, minden mükszik, a pure-parser átszervezése volt az egész mögött, de nem kell nagy kavarás hozzá.

Mondjuk ezt szívesen kihagytam volna:

$ bison -o mobipars.c -v mobipars.y
mobipars.y:64.1-12: warning: deprecated directive, use '%pure-parser' [-Wdeprecated]
 %pure_parser
 ^^^^^^^^^^^^

$ bison -V
bison (GNU Bison) 3.0.2

Nyilván ha átírom s/%pure-parser/%pure_parser/ akkor szépen minden más gépen is bison-verziót kell növelnem, mert azok meg az opció új formáját nem ismerik még.

Ez talán érdekes lehet, egy másik fórumból: http://www.linuxquestions.org/questions/showthread.php?p=5228567

A lényeg: a $$ a szabály végén lévő kód esetén a szabály kimenetét jelenti, a szabály belsejében lévő kód esetén egy lokális értéket a vermen. Maga a bison doksi is hoz egy példát, épp most leltem:

stmt:

LET

'('

var

')'
{ $<context>$ = push_context (); declare_variable ($3); }
stmt

{ $$ = $6; pop_context ($<context>5); }

Itt az ötös elem (vagyis a $5) az a beágyazott kódrészlet, ami értékőrzőül szolgál (saját magán belül $$ az érték, a továbbiakban meg $5 -- szerintem nem egészen intuitív, talán jobb lenne, ha önmagában is menne a $5 (de nem megy)).

És mivel nincs neve, nem lehet %type-ot se mondani rá, ezért ezzel a furcsa szintaxissal kell típuskényszeríteni (ha egyáltalán használunk %type-ot, az én előző példámban épp nem használtunk))

Nem mondhatnám, hogy különösebben értem, de itt egy példa-féle: egy if-számláló, amit a beágyazott if-ek miatt mentünk és visszaállítunk

if:     IF                { $$.ifcounter= ++ifcounter;
                            ++ifnest;
                            fprintf (stderr, "line %ld: before if, set ifcounter to %d, be
st=%dn",
                                lineno, ifcounter, ifnest);
                            fflush (stderr); }
        '(' expr ')' stmt
        opt_else          { $$.obj = NIF3($4, $6, $7);
                            ifcounter= $2.ifcounter;
                            --ifnest;
                            fprintf (stderr, "line %ld: after if, reset ifcounter to %d, ifnest=%dn",
                                lineno, ifcounter, ifnest);
                            fflush (stderr); };

opt_else:                 { $$.obj = NULL; }
        | ELSE stmt       { $$.obj = $2.obj; };