Сообщение Re[21]: Опциональные типы от 11.03.2017 10:44
Изменено 11.03.2017 10:52 vdimas
Re[21]: Опциональные типы
Здравствуйте, WolfHound, Вы писали:
V>>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов.
WH>Это тривиальная задача. Делается, вообще не приходя в сознание.
Ну вот вы делали генератор для ПЕГ более 2-х лет.
Я не считаю, что 2 года — это трививально.
Для моего случая полноценных минимум 3-4 рабочих дня вынь да положь.
Это если охота именно погонять, а не "просто взглянуть на алгоритм".
WH>Настоящая веселуха начинается, когда начинаешь после ошибок восстанавливаться.
Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок?
По-моему, ты сам себя закопал только что.
WH>Покажи хоть чей. Там же по твоим утверждениям всё просто.
Хоть чей ты можешь взглянуть и без меня.
WH>Значит кто-то должен был это сделать.
Ну вот Бизон делает GLR, смотрел?.
Там лексер кладёт код текущего разобранного символа-нетерминала в глобальную переменную.
Потом вызывается парсер, который читает эту глобальную переменную.
Догадайся с одного раза, как будет "константа" в такой реализации. ))
Разумеется, сам алгоритм парсинга тут не при чем, это просто наследство архитектуры 20-тилетней давности, где проги ранее почти всегда собирались с однопоточным рантаймом и где скорость компиляции больше ограничивалась быстродействием дисковой подсистемы.
V>>Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов.
V>>И с последним у тебя явные проблемы.
WH>Сколько десятков часов ты уже потратил отвечая на мои сообщения?
По 3-5 мин на сообщение.
Одному человеку редко отвечаю более 2-х сообщений в день, разве что по выходным.
Когда писал сниппет кода про альфа-блендинг потратил минут на 5-7 больше.
Позже перечитал, увидел кучу описок и поисправлял.
В общем, я пишу сюда в кач-ве "отдыха" от программирования. ))
Некоторые в этот самый момент на перекур ходят, к примеру...
V>>Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение.
WH>В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно.
Недостаточен всего один следующий символ, ты хотел сказать.
Желательно закончить некое выражение, верно?
А для этого нужен текущий стек разбора, верно?
Причем, в рекурсивном спуске у нас стек разбора неявный, т.е. недоступный для его обхода/реинтерпретации, верно?
Поэтому нужен какой-нить другой алгоритм, типа Эрли, который даст стек (стэки) разбора в виде, доступном для обхода.
Так вот, LR-парсеры содержат стек разбора в явном виде.
V>>У тебя же сплошной стиль "а у вас зато молоко убежало". ))
WH>Так от тебя никакой информации нет. Одно хвастовство которое противоречит всем работам, которые я читал.
Отчего же стандартом де-факто остаётся старенький Бизон?
WH>>>Так что это если не изменение грамматики во время разбора?
V>>А в C# вот тут:
WH>C# тупо парсит всё. А на этапе типизации говорит
WH>Pointers and fixed size buffers may only be used in an unsafe context
Тем не менее, это тоже был пример контекстно-зависимой грамматики.
Просто я не люблю спекуляции на эти темы.
Почти все известные языки являются КЗ, но парсеры под них — КС.
За счет semantic actions обыгрываются всякие вполне конкретные моменты.
У тебя на "using syntax XXX" происходит "кое-что".
Так вот, вся спекуляция тут в том, что всё это далеко от тру КЗ, где КЗ-правила можно выражать декларативно.
Все эти semantic actions — это всё "черные ящики", у которых их работа описана в документации, а не в доступном для формальной обработки виде.
Кароч, не заставляй коллег делать лишний раз "охотничью стойку", упоминая про КЗ. )))
Давай мы будем говорить про КЗ тогда, когда будет его полноценная формальная поддержка.
Т.е. когда можно будет задавать любой контекст как угодно, а не только через некие ключевые фразы навроде "using syntax".
WH>А у меня идёт именно загрузка новой грамматики. О которой автор основной грамматики в общем случае даже не догадывается.
Надеюсь, в твоём случае, в отличие от Влада, моей фразы "декомпозиция грамматик" будет достаточно для демонстрации понимания того, что при этом происходит?
Мои претензии не к реализации вот этой штуковины (лично я голосую за любую востребованную функциональность). Претензии были к тому, что вот этот момент тоже нифига к обсуждению не относится. Будем считать, что ты кое-чем похвастался, ОК.
V>>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов.
WH>Это тривиальная задача. Делается, вообще не приходя в сознание.
Ну вот вы делали генератор для ПЕГ более 2-х лет.
Я не считаю, что 2 года — это трививально.
Для моего случая полноценных минимум 3-4 рабочих дня вынь да положь.
Это если охота именно погонять, а не "просто взглянуть на алгоритм".
WH>Настоящая веселуха начинается, когда начинаешь после ошибок восстанавливаться.
Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок?
По-моему, ты сам себя закопал только что.
WH>Покажи хоть чей. Там же по твоим утверждениям всё просто.
Хоть чей ты можешь взглянуть и без меня.
WH>Значит кто-то должен был это сделать.
Ну вот Бизон делает GLR, смотрел?.
Там лексер кладёт код текущего разобранного символа-нетерминала в глобальную переменную.
Потом вызывается парсер, который читает эту глобальную переменную.
Догадайся с одного раза, как будет "константа" в такой реализации. ))
Разумеется, сам алгоритм парсинга тут не при чем, это просто наследство архитектуры 20-тилетней давности, где проги ранее почти всегда собирались с однопоточным рантаймом и где скорость компиляции больше ограничивалась быстродействием дисковой подсистемы.
V>>Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов.
V>>И с последним у тебя явные проблемы.
WH>Сколько десятков часов ты уже потратил отвечая на мои сообщения?
По 3-5 мин на сообщение.
Одному человеку редко отвечаю более 2-х сообщений в день, разве что по выходным.
Когда писал сниппет кода про альфа-блендинг потратил минут на 5-7 больше.
Позже перечитал, увидел кучу описок и поисправлял.
В общем, я пишу сюда в кач-ве "отдыха" от программирования. ))
Некоторые в этот самый момент на перекур ходят, к примеру...
V>>Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение.
WH>В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно.
Недостаточен всего один следующий символ, ты хотел сказать.
Желательно закончить некое выражение, верно?
А для этого нужен текущий стек разбора, верно?
Причем, в рекурсивном спуске у нас стек разбора неявный, т.е. недоступный для его обхода/реинтерпретации, верно?
Поэтому нужен какой-нить другой алгоритм, типа Эрли, который даст стек (стэки) разбора в виде, доступном для обхода.
Так вот, LR-парсеры содержат стек разбора в явном виде.
V>>У тебя же сплошной стиль "а у вас зато молоко убежало". ))
WH>Так от тебя никакой информации нет. Одно хвастовство которое противоречит всем работам, которые я читал.
Отчего же стандартом де-факто остаётся старенький Бизон?
WH>>>Так что это если не изменение грамматики во время разбора?
V>>А в C# вот тут:
WH>C# тупо парсит всё. А на этапе типизации говорит
WH>Pointers and fixed size buffers may only be used in an unsafe context
Тем не менее, это тоже был пример контекстно-зависимой грамматики.
Просто я не люблю спекуляции на эти темы.
Почти все известные языки являются КЗ, но парсеры под них — КС.
За счет semantic actions обыгрываются всякие вполне конкретные моменты.
У тебя на "using syntax XXX" происходит "кое-что".
Так вот, вся спекуляция тут в том, что всё это далеко от тру КЗ, где КЗ-правила можно выражать декларативно.
Все эти semantic actions — это всё "черные ящики", у которых их работа описана в документации, а не в доступном для формальной обработки виде.
Кароч, не заставляй коллег делать лишний раз "охотничью стойку", упоминая про КЗ. )))
Давай мы будем говорить про КЗ тогда, когда будет его полноценная формальная поддержка.
Т.е. когда можно будет задавать любой контекст как угодно, а не только через некие ключевые фразы навроде "using syntax".
WH>А у меня идёт именно загрузка новой грамматики. О которой автор основной грамматики в общем случае даже не догадывается.
Надеюсь, в твоём случае, в отличие от Влада, моей фразы "декомпозиция грамматик" будет достаточно для демонстрации понимания того, что при этом происходит?
Мои претензии не к реализации вот этой штуковины (лично я голосую за любую востребованную функциональность). Претензии были к тому, что вот этот момент тоже нифига к обсуждению не относится. Будем считать, что ты кое-чем похвастался, ОК.
Re[21]: Опциональные типы
Здравствуйте, WolfHound, Вы писали:
V>>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов.
WH>Это тривиальная задача. Делается, вообще не приходя в сознание.
Ну вот вы делали генератор для ПЕГ более 2-х лет.
Я не считаю, что 2 года — это трививально.
Для моего случая полноценных минимум 3-4 рабочих дня вынь да положь.
Это если охота именно погонять, а не "просто взглянуть на алгоритм".
WH>Настоящая веселуха начинается, когда начинаешь после ошибок восстанавливаться.
Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок?
По-моему, ты сам себя закопал только что.
WH>Покажи хоть чей. Там же по твоим утверждениям всё просто.
Хоть чей ты можешь взглянуть и без меня.
WH>Значит кто-то должен был это сделать.
Ну вот Бизон делает GLR, смотрел?.
Там лексер кладёт код текущего разобранного символа-нетерминала в глобальную переменную.
Потом вызывается парсер, который читает эту глобальную переменную.
Догадайся с одного раза, какая будет "константа" в такой реализации. ))
Разумеется, сам алгоритм парсинга тут не при чем, это просто наследство архитектуры 20-тилетней давности, где проги ранее почти всегда собирались с однопоточным рантаймом и где скорость компиляции больше ограничивалась быстродействием дисковой подсистемы.
V>>Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов.
V>>И с последним у тебя явные проблемы.
WH>Сколько десятков часов ты уже потратил отвечая на мои сообщения?
По 3-5 мин на сообщение.
Одному человеку редко отвечаю более 2-х сообщений в день, разве что по выходным.
Когда писал сниппет кода про альфа-блендинг потратил минут на 5-7 больше.
Позже перечитал, увидел кучу описок и поисправлял.
В общем, я пишу сюда в кач-ве "отдыха" от программирования. ))
Некоторые в этот самый момент на перекур ходят, к примеру...
V>>Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение.
WH>В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно.
Недостаточен всего один следующий символ, ты хотел сказать.
Желательно закончить некое выражение, верно?
А для этого нужен текущий стек разбора, верно?
Причем, в рекурсивном спуске у нас стек разбора неявный, т.е. недоступный для его обхода/реинтерпретации, верно?
Поэтому нужен какой-нить другой алгоритм, типа Эрли, который даст стек (стэки) разбора в виде, доступном для обхода.
Так вот, LR-парсеры содержат стек разбора в явном виде.
V>>У тебя же сплошной стиль "а у вас зато молоко убежало". ))
WH>Так от тебя никакой информации нет. Одно хвастовство которое противоречит всем работам, которые я читал.
Отчего же стандартом де-факто остаётся старенький Бизон?
WH>>>Так что это если не изменение грамматики во время разбора?
V>>А в C# вот тут:
WH>C# тупо парсит всё. А на этапе типизации говорит
WH>Pointers and fixed size buffers may only be used in an unsafe context
Тем не менее, это тоже был пример контекстно-зависимой грамматики.
Просто я не люблю спекуляции на эти темы.
Почти все известные языки являются КЗ, но парсеры под них — КС.
За счет semantic actions обыгрываются всякие вполне конкретные моменты.
У тебя на "using syntax XXX" происходит "кое-что".
Так вот, вся спекуляция тут в том, что всё это далеко от тру КЗ, где КЗ-правила можно выражать декларативно.
Все эти semantic actions — это всё "черные ящики", у которых их работа описана в документации, а не в доступном для формальной обработки виде.
Кароч, не заставляй коллег делать лишний раз "охотничью стойку", упоминая про КЗ. )))
Давай мы будем говорить про КЗ тогда, когда будет его полноценная формальная поддержка.
Т.е. когда можно будет задавать любой контекст как угодно, а не только через некие ключевые фразы навроде "using syntax".
WH>А у меня идёт именно загрузка новой грамматики. О которой автор основной грамматики в общем случае даже не догадывается.
Надеюсь, в твоём случае, в отличие от Влада, моей фразы "декомпозиция грамматик" будет достаточно для демонстрации понимания того, что при этом происходит?
Мои претензии не к реализации вот этой штуковины (лично я голосую за любую востребованную функциональность). Претензии были к тому, что вот этот момент тоже нифига к обсуждению не относится. Будем считать, что ты кое-чем похвастался, ОК.
V>>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов.
WH>Это тривиальная задача. Делается, вообще не приходя в сознание.
Ну вот вы делали генератор для ПЕГ более 2-х лет.
Я не считаю, что 2 года — это трививально.
Для моего случая полноценных минимум 3-4 рабочих дня вынь да положь.
Это если охота именно погонять, а не "просто взглянуть на алгоритм".
WH>Настоящая веселуха начинается, когда начинаешь после ошибок восстанавливаться.
Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок?
По-моему, ты сам себя закопал только что.
WH>Покажи хоть чей. Там же по твоим утверждениям всё просто.
Хоть чей ты можешь взглянуть и без меня.
WH>Значит кто-то должен был это сделать.
Ну вот Бизон делает GLR, смотрел?.
Там лексер кладёт код текущего разобранного символа-нетерминала в глобальную переменную.
Потом вызывается парсер, который читает эту глобальную переменную.
Догадайся с одного раза, какая будет "константа" в такой реализации. ))
Разумеется, сам алгоритм парсинга тут не при чем, это просто наследство архитектуры 20-тилетней давности, где проги ранее почти всегда собирались с однопоточным рантаймом и где скорость компиляции больше ограничивалась быстродействием дисковой подсистемы.
V>>Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов.
V>>И с последним у тебя явные проблемы.
WH>Сколько десятков часов ты уже потратил отвечая на мои сообщения?
По 3-5 мин на сообщение.
Одному человеку редко отвечаю более 2-х сообщений в день, разве что по выходным.
Когда писал сниппет кода про альфа-блендинг потратил минут на 5-7 больше.
Позже перечитал, увидел кучу описок и поисправлял.
В общем, я пишу сюда в кач-ве "отдыха" от программирования. ))
Некоторые в этот самый момент на перекур ходят, к примеру...
V>>Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение.
WH>В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно.
Недостаточен всего один следующий символ, ты хотел сказать.
Желательно закончить некое выражение, верно?
А для этого нужен текущий стек разбора, верно?
Причем, в рекурсивном спуске у нас стек разбора неявный, т.е. недоступный для его обхода/реинтерпретации, верно?
Поэтому нужен какой-нить другой алгоритм, типа Эрли, который даст стек (стэки) разбора в виде, доступном для обхода.
Так вот, LR-парсеры содержат стек разбора в явном виде.
V>>У тебя же сплошной стиль "а у вас зато молоко убежало". ))
WH>Так от тебя никакой информации нет. Одно хвастовство которое противоречит всем работам, которые я читал.
Отчего же стандартом де-факто остаётся старенький Бизон?
WH>>>Так что это если не изменение грамматики во время разбора?
V>>А в C# вот тут:
WH>C# тупо парсит всё. А на этапе типизации говорит
WH>Pointers and fixed size buffers may only be used in an unsafe context
Тем не менее, это тоже был пример контекстно-зависимой грамматики.
Просто я не люблю спекуляции на эти темы.
Почти все известные языки являются КЗ, но парсеры под них — КС.
За счет semantic actions обыгрываются всякие вполне конкретные моменты.
У тебя на "using syntax XXX" происходит "кое-что".
Так вот, вся спекуляция тут в том, что всё это далеко от тру КЗ, где КЗ-правила можно выражать декларативно.
Все эти semantic actions — это всё "черные ящики", у которых их работа описана в документации, а не в доступном для формальной обработки виде.
Кароч, не заставляй коллег делать лишний раз "охотничью стойку", упоминая про КЗ. )))
Давай мы будем говорить про КЗ тогда, когда будет его полноценная формальная поддержка.
Т.е. когда можно будет задавать любой контекст как угодно, а не только через некие ключевые фразы навроде "using syntax".
WH>А у меня идёт именно загрузка новой грамматики. О которой автор основной грамматики в общем случае даже не догадывается.
Надеюсь, в твоём случае, в отличие от Влада, моей фразы "декомпозиция грамматик" будет достаточно для демонстрации понимания того, что при этом происходит?
Мои претензии не к реализации вот этой штуковины (лично я голосую за любую востребованную функциональность). Претензии были к тому, что вот этот момент тоже нифига к обсуждению не относится. Будем считать, что ты кое-чем похвастался, ОК.