![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Комбинаторы парсеров на LINQ
Таки дорвался использовать Monadic Parser Combinators. Достаточно удобно, можно думать категориями Parsec-а, но ошибки компилятора или стеки вызовов при рунтайм-ошибках выглядят ужасающе.
Кстати, по моему, там TValue[] в Rep и Rep1 надо на IEnumerable заменить
Пришлось таки сделать иммутабельный список (как обычный хаскелевый) для входных токенов, а то по ссылке автор там хитро обошел - каждый раз при получении символа из строки создает новую подстроку-хвост. Как-то нехорошо это выглядит. А с обычными мутабельными итераторами дотнета это вообще работать по определению не будет.
Теперь думаю, куда бы это контекст со списком парсеров(которые изменяются по ходу разбора) засунуть. Тут подсказали стрелки, но как оные стрелки впихнуть в дотнет и LINQ это отдельный вопрос. Наверно, имеет смысл список парсеров (вернее map идентификатор -> парсер) поселить вместе со входным списком токенов и наколбасить хитрых парсеров, которые кроме того, что потребляют токены, еще и меняют список.
Ну и еще совсем непонятно, как это все будет работать в отсутствие ленивости и оптимизации хвостовых вызовов.
Кстати, по моему, там TValue[] в Rep и Rep1 надо на IEnumerable
Пришлось таки сделать иммутабельный список (как обычный хаскелевый) для входных токенов, а то по ссылке автор там хитро обошел - каждый раз при получении символа из строки создает новую подстроку-хвост. Как-то нехорошо это выглядит. А с обычными мутабельными итераторами дотнета это вообще работать по определению не будет.
Теперь думаю, куда бы это контекст со списком парсеров(которые изменяются по ходу разбора) засунуть. Тут подсказали стрелки, но как оные стрелки впихнуть в дотнет и LINQ это отдельный вопрос. Наверно, имеет смысл список парсеров (вернее map идентификатор -> парсер) поселить вместе со входным списком токенов и наколбасить хитрых парсеров, которые кроме того, что потребляют токены, еще и меняют список.
Ну и еще совсем непонятно, как это все будет работать в отсутствие ленивости и оптимизации хвостовых вызовов.
no subject
no subject
no subject
Монадический парсинг в хаскеле обладает теми же проблемами: непонятно, как избегать тонны стружек при парсинге.
Парсинг на стрелках же прекрасен в этом отношении.
no subject
no subject
Roll #10.
"...The name of the game is Petals Around the Rose?"
"Right, and the name is significant."
no subject
no subject
no subject
no subject
no subject
no subject
Эээ. А в чём проблема сделать константный массив а обертку с кастомными head && tail, если противно видеть списки ?
no subject
А массив и обертку сделать можно было, но мне было лень.
no subject
no subject
also, check http://en.wikibooks.org/wiki/Haskell/Understanding_arrows
no subject
no subject
Короче, с 17 страниц меня сморил сон с кошмарами про парсеры, стрелки и дотнет, а сегодня я продолжил читать дальше, дошел до нотации c -> -< и понял, что если я чего-нибудь такое привнесу в продакшен, это будет плач, скрежет зубовный и вакансии для хаскелистов, когда я в дурку таки слягу :)
no subject
no subject
no subject
Но мысль "объяснить стрелки свежепринятому на работу студенту" у меня вызывает приступы необъяснимого злорадства.
Очень хочется посмотреть на лицо руководства, когда оно поймет, что из-за экономии на закупку пару десятков обезъянокодеров оно оказалось с проектом, на который придется выписывать гуру из академической среды и мирится с тем, что у него в головах зловещие мертвецы и змеи :)
no subject