eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingparsowanieparsowanie
  • Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
    From: Zbigniew Malec <a...@i...invalid>
    Newsgroups: pl.comp.programming
    Subject: parsowanie
    Date: Mon, 7 Feb 2011 21:23:26 +0100
    Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
    Lines: 57
    Message-ID: <z5amhr1xofpk$.14z5sesbluqtt$.dlg@40tude.net>
    NNTP-Posting-Host: 89-75-75-45.dynamic.chello.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset="iso-8859-2"
    Content-Transfer-Encoding: 8bit
    X-Trace: inews.gazeta.pl 1297110207 23100 89.75.75.45 (7 Feb 2011 20:23:27 GMT)
    X-Complaints-To: u...@a...pl
    NNTP-Posting-Date: Mon, 7 Feb 2011 20:23:27 +0000 (UTC)
    X-User: zbyszanna
    User-Agent: 40tude_Dialog/2.0.15.1
    Xref: news-archive.icm.edu.pl pl.comp.programming:188678
    [ ukryj nagłówki ]

    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?

    Ps. Chciałbym zaznaczyć, że wiem, że istnieją setki gotowych bibliotek i
    tak dalej, jednak ja się pytam dla wiedzy, a nie dla praktycznego
    rozwiązania.

    Ps. Na internecie jest sporo na ten temat, jednakże poruszane są tylko
    przykłady łatwe, w których takie dylematy nie występują :] Ale jakby gdzieś
    ktoś miał linka, to też się nie obrażę.


    --
    Pozdrawiam
    Zbyszek Malec

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: