Здравствуйте, Odissey_, Вы писали:

O_>Идею я понял, думаю смогу переписать под себя. Без try? Ну у Hutton`a вроде как формируется
O_>пустой список при неудачном парсинге, никаких исключений не бросается.

try здесь никак не связан с исключениями, этот комбинатор нужен для неограниченного заглядывания вперед.

Парсер foo1 не будет пробовать альтернативу baz, если bar съел часть входной строки и завершился неудачно; foo2 — будет.

foo1 = bar <|> baz
foo2 = try bar <|> baz

Здравствуйте, Odissey_, Вы писали:

Исходя из здравого смысла и того, что я не знаю Haskell — как-то так
Для работы нужен Parsec, хотя возможно Hutton's парсер тоже пойдет (сможет без try?)

type Tag  = String

data Node = Node Tag [Node]
          | Text String
            deriving(Show,Eq)

parseTag =  do { char '<'
               ; tag <- many1 lower
               ; char '>'
               ; return tag
               }
tagLikeThis tag =  do{ char '<' 
                     ; string tag
                     ; char '>'
                     ; return tag
                     }

parseText = do { txt <- many lower
               ; return $ Text txt
               }
               
parseTagNode = try ( do { x <- parseText
                        ; tag   <- parseTag
                        ; node  <- parseTagNode
                        ; tagLikeThis tag
                        ; y <- parseText
                        ; return $ Node ("<"++tag++">") [x,y,node]
                        } )
               <|> parseText
------------------------------------------------------------------
*Main> run parseTagNode "eee<aa>fff<bb>uuu<dd><dd><bb>ee<aa>ss"
Node "<aa>" [Text "eee",Text "ss",Node "<bb>" [Text "fff",Text "ee",Node "<dd>" [Text "uuu",Text "",Text ""]]]

Здравствуйте.
Пытаясь написать функциональный парсер (тему изучал по "Higher-Order Functions for Parsing∗" Graham Hutton), наткнулся вот на какую проблему:

Разбираемый текст состоит из обычного текста и текста обрамленного тэгами. Начльный и конечный тэг обычно имеют одинаковое "начертание" и тэги могут быть сколь угодно вложенными (но при этом вложенные тэги отличаются).
То есть, на примере, если мы имеем тэги "aa" и "bb", то корректным текстом считается — "taattbbttbbtttaat" и разбиратся как то так — [(Text "t"), (aa [(Text "tt"),(bb [(Text "tt")], (Text "ttt")]), (Text "t")]

data TagNode = Text* | Tag Text* TagNode Text* Tag

Подскажите пожалуйста, как (хотя бы общие принципы) лучше и проще реализовать парсинг пободного текста, с учетом того, что количество тэгов может быть расширено. Можно просто дать ссылки на простую реализацию подобного парсера (смотрел код hxml-0.2 но код довольно сложен для меня).

Прошу прощения, если вопрос показался довольно простым, — Haskell начал изучать сравнительно недавно.

Здравствуйте, z00n, Вы писали:

Z>Здравствуйте, Odissey_, Вы писали:

Z>Исходя из здравого смысла и того, что я не знаю Haskell — как-то так
Z>Для работы нужен Parsec, хотя возможно Hutton's парсер тоже пойдет (сможет без try?)

Большое спасибо, вижу Monadic Parser проще и понятнее . Parsec подключать не хотелось бы — хотел бы получить опыт построения ручками.
Идею я понял, думаю смогу переписать под себя. Без try? Ну у Hutton`a вроде как формируется
пустой список при неудачном парсинге, никаких исключений не бросается. Думаю разбирусь, в крайнем случае перепишу все с монадами. Еще раз спасибо.

Здравствуйте, Odissey_, Вы писали:

O_>Идею я понял, думаю смогу переписать под себя. Без try? Ну у Hutton`a вроде как формируется
O_>пустой список при неудачном парсинге, никаких исключений не бросается. Думаю разбирусь, в крайнем случае перепишу все с монадами. Еще раз спасибо.

try — это следствие оптимизации Хаттоновского парсера, внесенное в Parsec (подробности можно посмотреть в тут). Хаттоновский парсер имеет по умолчанию неограниченный бэктрэкинг, поэтому, скорее всего, в нем все заработает и так.