Nie można obliczyć minimalną długość parsera - uu-parsinglib w Haskell

Question

Pozwala zobaczyć fragment kodu:

pSegmentBegin p i = pIndentExact i *> ((:) <$> p i <*> ((pEOL *> pSegment p i) <|> pure [])) 

jeśli zmienię ten kod w moim parsera do:

pSegmentBegin p i = do 
    pIndentExact i 
    ((:) <$> p i <*> ((pEOL *> pSegment p i) <|> pure [])) 

mam błąd:

canot compute minmal length of a parser due to occurrence of a moadic bind, use addLength to override 

Pomyślałem, że powyższy parser powinien zachowywać się w ten sam sposób. Dlaczego ten błąd może wystąpić?

EDIT

Powyższy przykład jest bardzo proste (uproszczenie pytanie) i jak wskazano poniżej niej nie jest konieczne stosowanie zrobić notacji tutaj, ale prawdziwy przypadek chciałem go użyć jest następująco:

pSegmentBegin p i = do 
    j <- pIndentAtLast i 
    (:) <$> p j <*> ((pEOL *> pSegments p j) <|> pure []) 

zauważyłem, że dodanie „addLength 1” przed zrobić oświadczenie rozwiązuje problem, ale jestem pewien, jeśli jego poprawne rozwiązanie:

pSegmentBegin p i = addLength 2 $ do 
    j <- pIndentAtLast i 
    (:) <$> p j <*> ((pEOL *> pSegments p j) <|> pure []) 

Answer 1

Jak już wspomniałem wiele razy, monadyczny interfejs powinien być unikany, kiedy tylko jest to możliwe. pozwól mi spróbować wyjaśnić, dlaczego preferowany jest interfejs aplikacyjny.

Jedną z wyróżniających cech mojej biblioteki jest to, że wykonuje korekcję błędów, wstawiając lub usuwając problemy. Oczywiście możemy przyjąć tutaj nieograniczone spojrzenie, ale dzięki temu proces BARDZO drogi. Tak więc ograniczamy się tylko do trzech kroków.

Załóżmy teraz musimy wstawić ekspresję i jedną z alternatyw jest wyrażenie:

wyrażenie: = „if” wyrażenie „a następnie” wyrażenie „else” wyrażenie

następnie chcemy wykluczyć tę alternatywę ponieważ wybór tej alternatywy wymagałby wstawienia innego wyrażenia itp. Przeprowadzamy zatem abstrakcyjną interpretację alternatyw i upewniamy się, że w przypadku remisu (tj. równe koszty ograniczonego wyprzedzenia) bierzemy jedną z nierekurencyjnych alternatyw.

Niestety ten schemat ulega awarii, gdy pisze się monadyczne analizatory składni, ponieważ długość prawej strony wiązania może zależeć od wyniku po lewej stronie.Wydajemy więc komunikat o błędzie i prosimy programistę o pomoc w wskazaniu liczby tokenów, które ta alternatywa może zużyć. Rzeczywista wartość nie ma większego znaczenia, o ile nie zapewnisz skończonej długości dla czegoś, co jest rekurencyjne i może prowadzić do nieskończonych wstawień. Jest używany tylko do wyboru najkrótszej alternatywy w przypadku wstawienia.

Ta abstrakcyjna interpretacja wiąże się z pewnymi kosztami i jeśli napiszesz wszystkie swoje parsery w monadycznym stylu, nieuniknione jest, że ta analiza powtarza się od nowa. więc: NIE NALEŻY NAPISOWAĆ MONADYCZNYCH STYLÓW STYLU PRZY KORZYSTANIU Z TEJ BIBLIOTEKI, JEŻELI JEST APLIKACJĄ ALTERNATYWNĄ.

Answer 2

Próbuje statycznie przeanalizować, ile danych wejściowych należy odczytać, aby zoptymalizować wydajność, ale tego rodzaju optymalizacja wymaga statycznie znanej struktury parsera - takiej, która może być zbudowana przez Applicative s, ponieważ efekt parsera nie może zależeć od parsera wartość taka, jaką robi (>>=).

A więc tak się dzieje - podczas korzystania z zapisu do przekłada się na wiązanie Monadic, które przerywa predykcję Applicative. Byłoby miło, gdyby biblioteka ujawniła tylko jeden z dwóch interfejsów, tak aby tego rodzaju błąd nie mógł się zdarzyć, ale zamiast tego istnieje pewna niespójność, jeśli używasz obu interfejsów razem w tym samym parserze.

Ponieważ korzystanie z do jest absolutnie niepotrzebne - nie korzystasz z dodatkowej mocy, którą zapewnia interfejs monadyczny - prawdopodobnie lepiej po prostu tego uniknąć.

Answer 3

Mam obejście, którego używam z monadycznymi analizatorami składni w uuparsinglib. Jego własny odpowiedź tutaj: Monadic parse with uu-parsinglib

może okazać się przydatna