[ri4pp:2005] - Poletece, Poletece / Re: Jucerasnja rasprava na temu u kom redosledu se redukuju smene by "Jovan Popovic" <jovan@etf.bg.ac.yu>

Po preporuci iz domaceg:
Parameter_list -> Parameter_list Parameter | Parameter

U mojoj gramtici odgovara:

Designator ::=	Designator:o  DOT IDENTIFIKATOR:id;
Designator ::=	IDENTIFIKATOR:id;

ili

Designator ::=	Designator:o  DOT IDENTIFIKATOR:id | IDENTIFIKATOR:id

Gde je
Designator        <=> Parameter_list
DOT IDENTIFIKATOR <=> Parameter

Tako da je gramatika koju sam dao u skladu sa preporukom.
Inace onaj izlaz koji sam vam dao je copy-paste izlaza cup generisanog
parsera tako da to radi!

Ako se setis sta se desilo u nastavku crtanog filma, odmah posle
Sofronijevog iskaza avion je poleteo :)

Pregledaj jos jednom tvoju gramatiku jer ako postoji ogromna mogucnost da
si negde pogresio pri definiciji gramatike i tako ukomplikovao parser.

>
> 	Pa, pocenu da ispadem glup citiracu Sofronija: "OVO NIKADA NECE
> POLETETI!!!". Problem je u gramatici koja nikako nece moci da svari ovako
> nesto. U preporukama uz DZ2 kao spakovati probleme tipa designatora koji
> treba
> rekurzivno da poziva sam sebe stavili ste sledece:
>
> 1. U slučaju da je potrebno napisati smenu u kojoj se neki pojam ponavlja
> jednom
> ili više puta, odgovarajuća smena se može uraditi na sledeći način:
>
> Parameter_list ? Parameter_list Parameter | Parameter
>
> Gde je Parameter_list neterminal koji opisuje jedno ili više pojavljivanja
> objekta Parameter, dok je Parameter objekat koji treba da se ponavlja
> jednom ili
> više puta.
>
> Po meni to znaci da bi ovaj parametar list trebao da nam proguta onaj
> visak
> A.b.c. itd. ili ako se nekome vise svidja da ostavi prvi parametar onda bi
> taj
> parametar list trebalo da proguta b.c.d. itd. Upravo ovde se javlja
> problem jer
> sada kada se napise smena tipa:
>
> Designator ::= des_list;
> des_list ::= IDENT DOT des_list | IDENT;
>
> Kada se u drugoj smeni prodje kroz prvu opciju ident zadrzava ime npr.
> klase A,
> a ostatak se spusta u des_list koji se rekurzivno razvija. To znaci da
> kada
> budem trebao da proverim da li je ono B u nasem slucaju FLD klase A ja
> necu
> videti klasu A jer je ona ostala u IDENT-u, a B se spustilo pri rekurziji
> tako
> da ne vidi A. Ovo jedino moze da se izbegne uvodjenjem globalne
> promenljive u
> koju ce se na pocetku smestiti A. Kada uvrdimo sta nam treba za B onda
> njega
> smestamo u tu promenljivu i kao se spustamo kroz rekurziju.
>
> Sem toga mislim da ovakva smena nije potpuno u skladu sa LALR parserima
> posto
> ima desnu rekurziju. Ovakva smena ce medjutim u CUP-u proci bez problema
> za DZ2
> i apsolutno pravilno ce isparsirati ulazni file.
>
> Pozdrav
> ZNase Co.
>
> 5/26/05 9:33:25 AM, "Jovan Popovic" <jovan@etf.bg.ac.yu> wrote:
>
>>Juce je na veybama bilo rasprave u kom redosledu se redukuju smene za
>>a.b.c.d i sl.
>>
>>Ovo je primer koji treba da simulira te smene:
>>
>>Ubacite ovaj kod/klase u vas cup skript (one simuliraju tabelu simbola,
>>klasu Item i codegenerator):
>>class Item{
>>
>>String name, kind, type, adr;
>>public void load(){
>>		if(kind.equals("STATIC"))
>>		System.out.println("getstatic "+" adr(" + name + ")");
>>			if(kind.equals("FLD"))
>>		System.out.println("getfield "+" adr(" + name + ")");
>>	}
>>public String toString(){
>>return "Item{\n name="+name+";\n kind="+kind+";\n type="+type + ";\n}\n";
>>	}
>>}
>>
>>
>>/**
>>	Nalazi klasu za ime promenljive fiksno za promenljivu f je klasa F, demo
>>verzija
>>*/
>>public static String GetClass(String name)
>>{	return name.toUpperCase();
>>}
>>
>>Ubacite smene da analizu polja:
>>
>>Designator ::=	Designator:o  DOT IDENTIFIKATOR:id
>>			{:	Item r = new Item();
>>									r.name = id;
> 								r.kind = "FLD";
>>									//Ovo bi se punilo
> iz tabele
>>simbola						System.out.println("Pronalazim
> klasu " +o.type + " u
>>tabeli simbola i uzimam njen scope
>>");									System.out.println
> ("Proveravam da li u opsegu klase "
>>+o.type + " postoji polje " +
>>id);									System.out.println
> ("Nalazim u klasi " +o.type + "
>>polje " + id +" (nalazim njegov type i adress)");
>>									r.type = GetClass
> (id);
>>									System.out.println
> ("\nProsledjujem gornjoj smeni " +r.toString());
>>									o.load();
>>									RESULT=r; :};
>>
>>Designator ::=  IDENTIFIKATOR:id {: Item o = new Item();
>>									o.name = id;
>>									o.kind = "STATIC";
>>									//Ovo bi se punilo
> iz tabele simbola
>>									System.out.println
> ("Pronalazim simbol " + id + " u tabeli simbola
>>i uzimam njegov type i address ");
>>									o.type = GetClass
> (id);
>>									System.out.println
> ("\nProsledjujem gornjoj smeni " +o.toString());
>>									RESULT=o; :};
>>
>>Kada pokrenete ovakvu smenu za ulaz:
>>
>>a.b.c.d.i
>>
>>Dobijate izlaz:
>>
>>
>>
>>
>>Pronalazim simbol a u tabeli simbola i uzimam njegov type i address
>>
>>Prosledjujem gornjoj smeni Item{
>> name=a;
>> kind=STATIC;
>> type=A;
>>}
>>
>>Pronalazim klasu A u tabeli simbola i uzimam njen scope
>>Proveravam da li u opsegu klase A postoji polje b
>>Nalazim u klasi A polje b (nalazim njegov type i adress)
>>
>>Prosledjujem gornjoj smeni Item{
>> name=b;
>> kind=FLD;
>> type=B;
>>}
>>
>>getstatic  adr(a)
>>Pronalazim klasu B u tabeli simbola i uzimam njen scope
>>Proveravam da li u opsegu klase B postoji polje c
>>Nalazim u klasi B polje c (nalazim njegov type i adress)
>>
>>Prosledjujem gornjoj smeni Item{
>> name=c;
>> kind=FLD;
>> type=C;
>>}
>>
>>getfield  adr(b)
>>Pronalazim klasu C u tabeli simbola i uzimam njen scope
>>Proveravam da li u opsegu klase C postoji polje d
>>Nalazim u klasi C polje d (nalazim njegov type i adress)
>>
>>Prosledjujem gornjoj smeni Item{
>> name=d;
>> kind=FLD;
>> type=D;
>>}
>>
>>getfield  adr(c)
>>Pronalazim klasu D u tabeli simbola i uzimam njen scope
>>Proveravam da li u opsegu klase D postoji polje i
>>Nalazim u klasi D polje i (nalazim njegov type i adress)
>>
>>Prosledjujem gornjoj smeni Item{
>> name=i;
>> kind=FLD;
>> type=I;
>>}
>>
>>getfield  adr(d)
>>
>>
>>
>>
>>
>>
>>
>>
>>Kao sto vidite:
>>1. PRVO se obradjuju levi simboli prvo a pa b pa c itd.
>>2. Item se ispravno prosledjuju gornjoj smeni
>>3. kod koji se generise je
>>
>>getstatic  adr(a)
>>getfield  adr(b)
>>getfield  adr(c)
>>getfield  adr(d)
>>
>>koji ispravno ubacuje na stek izraza referencu na a.b.c.d i prosledjuje
>>gornjoj smeni
>>Item tipa FLD sa adresom polja i. Ona ce odluciti sta se radi sa
>> trenutnom
>>adresom na
>>steku izraza i Item-om i koji je prosledjen.
>>
>>Nadam sa da ste sad uvereni u kom redosledu se redukuju smene(a narocito
>>ZNase Co)
>>
>>Pozdrav,
>>Jovan
>>
>>-----------------------------------------------------------------
>>unsubscribe:
>>   minimalist@titan.etf.bg.ac.yu?subject=unsubscribe%20ri4pp
>>-----------------------------------------------------------------
>>
>>
>>
>
> -----------------------------------------------------------------
> unsubscribe:
>    minimalist@titan.etf.bg.ac.yu?subject=unsubscribe%20ri4pp
> -----------------------------------------------------------------
>
>