eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingparsowanie › Re: parsowanie
  • Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.PO
    STED!cat.tac!not-for-mail
    From: Wojciech Muła <w...@p...null.onet.pl.invalid>
    Newsgroups: pl.comp.programming
    Subject: Re: parsowanie
    Date: Mon, 7 Feb 2011 21:50:25 +0100
    Organization: http://0x80.pl
    Lines: 71
    Message-ID: <2...@c...tac>
    References: <z5amhr1xofpk$.14z5sesbluqtt$.dlg@40tude.net>
    NNTP-Posting-Host: public93711.xdsl.centertel.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    X-Trace: news.onet.pl 1297111833 9867 188.47.238.15 (7 Feb 2011 20:50:33 GMT)
    X-Complaints-To: n...@o...pl
    NNTP-Posting-Date: Mon, 7 Feb 2011 20:50:33 +0000 (UTC)
    X-Newsreader: Claws Mail 3.7.8 (GTK+ 2.20.1; i486-pc-linux-gnu)
    Xref: news-archive.icm.edu.pl pl.comp.programming:188679
    [ ukryj nagłówki ]

    On Mon, 7 Feb 2011 21:23:26 +0100 Zbigniew Malec
    <a...@i...invalid> wrote:

    > Witam,
    > mam takie pytanie ze swiata parserów.
    > Piszę sobie taki mały parser i dla wygody podzieliłem go na dwie
    > części: Tokenizer i Parser.
    > W mojej składni występuje znaczek nawiasu klamrowego { i teraz,
    > jeżeli jest on po dolarze $, to znaczy, że jest to początek nazwy
    > zmiennej, natomiast jeżeli nie jest po dolarze, to jest po prostu
    > elementem tekstu, przykładowo:
    >
    > abra { cos ${zmienna}
    >
    > Pierwszy nawias to tekst, a kolejne, to już elementy zmiennej.
    >
    > I teraz tak się zastanawiam (czysto koncepcyjnie), czy w tym przypadku
    > tokenami powinny być:
    >
    > LITERAŁ: abra { coś
    > ZNACZNIK ZMIENNEJ
    > POCZĄTEK ZMIENNEJ
    > LITERAŁ: zmienna
    > KONIEC ZMIENNEJ
    >
    > czy raczej
    > LITERAŁ: abra
    > NAWIAS
    > LITERAŁ: coś
    > ZNACZNIK ZMIENNEJ
    > NAWIAS OTWIERAJĄCY
    > LITERAŁ: zmienna
    > NAWIAS ZAMYKAJĄCY
    >
    > i dopiero w parserze to sklejać dalej.
    >
    > Rozwiązanie 1 ma taką zaletę, że od razu otrzymujemy sensowne tokeny
    > (i jak tak patrzę na dokumentację różnych parserów do C++ np. to
    > wygląda, że tak właśnie jest to robione), jednak trzeba pamiętać
    > jeszcze kontekst, np. że do tej pory nie było dolara $, więc to jest
    > nawias, a nie początek zmiennej, a to się może szybko przekształcić w
    > bałagan nie do utrzymania. Rorwiązanie 2 ma natomiast taką wadę, że
    > na parserze spoczywa obowiązek łączenia tokenów w większe tokeny (np.
    > LITERAŁ: abra, NAWIAS, LITERAŁ: coś w LITERAŁ: abra { coś), jednakże
    > łatwiej jest tutaj zarządzać stanem poprzez odpowiednie zchodzenie w
    > dół drzewa z accept i expect.
    >
    > Więc jakbyście wy to zrobili?

    Parser przecież i tak tworzy jakieś drzewo rozbioru gramatycznego.
    Więc czy masz do sprawdzania wariant ZMIENNA/NAWIAS/LITERAŁ/NAWIAS,
    czy POCZĄTEK ZM./LITERAŁ/KONIEC ZM. to raczej mała różnica, bo
    ostatecznie interesuje Cię nazwa zmiennej. Bardziej kwestia, jak
    bardzo ułatwi (lub skomplikuje) to inne działania.

    Ale jeślibyś zdecydował się na pierwszy wariant, tzn. trochę więcej
    pracy w tokenizerze, to zastanów się, czy wtedy w ogóle warto wypisywać
    aż cztery tokeny dla zmiennej. Wiesz, gdzie jest początek i koniec
    zmiennej, znasz jej nazwę - może wyprowadź jeden token ZMIENNA i już
    nie kłopocz parser duperelami. ;-)

    w.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: