Сообщение Re[19]: Опциональные типы от 03.03.2017 10:20
Изменено 03.03.2017 17:17 vdimas
Re[19]: Опциональные типы
Здравствуйте, fddima, Вы писали:
F>>>Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
V>>Это просто декомпозиция грамматик.
F> Ты можешь называть их как хочешь, я бы сказал наоборот — позволяет динамически видоизменять грамматику (это скорее композиция)
Пофик.
Разбиваем целое на части — декомпозиция.
Собираем целое из частей — композиция.
F>ведь ключи компиляции c99,c11 и т.п. напрямую влияют на этот процесс.
Да.
F>Ну и это проще отлаживать — ведь стэк содержит всё что надо, так что можно довольно легко "осмотреться".
Это только в тривиальных вещах, типа высокоуровневых объявлений.
А математические сложенные выражения с вызовами ф-ий отродясь было удобней восходящим разбором парсить.
Там и стек разбора более удобен для "осмотреться", бо в нём уже присутствуют свернутые однозначные нетерминалы. Сравнить с нисходящим разбором, где в каждый момент времени имеем лишь один из потенциальных вариантов.
F> Понятно, что на основе GLR и других подходов можно добиться даже бОльшего и вроде как и проще, но прийдется как минимум написать толковый генератор парсера с какими-то уникальными расширениями.
Фишка в том, что все мейнстримовые генераторы парсеров умеют генерить LR-разбор (LALR/GLR). А вот дополнительно LL(k), или обобщенный LL(1), т.е. Эрли — лишь считанные единицы из них. И такое жжж не спроста. (С)
F>В итоге, имхо, — проще сопровождать 1-2Мб кода без всяких выворотов, особенно когда сам язык и его грамматика вполне это позволяют.
Декомпозиция как раз избавляет от вывертов. В каждом текущем контексте разбора у нас обрабатывается ограниченное подмножество правил (т.е. имеем дело в подграмматикой). Например, ты не можешь внутри математических выражений объявлять типы.
F>Вдобавок и работают быстро. Для промышленных C/C++ — это вполне оправдано.
Быстро — это когда без откатов, т.е. LR-семейство.
Для LL(1) быстро будет только на заведомо однозначных выражениях — ну вот объявление типа, например. Такую ерунду легко парсить ручным LL(1-2) парсером (т.е. с предпросмотром на 1-2 лексемы).
F>Интересно какие парсеры используются в icc и msvc.
Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.
F>>>Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
V>>Это просто декомпозиция грамматик.
F> Ты можешь называть их как хочешь, я бы сказал наоборот — позволяет динамически видоизменять грамматику (это скорее композиция)
Пофик.
Разбиваем целое на части — декомпозиция.
Собираем целое из частей — композиция.
F>ведь ключи компиляции c99,c11 и т.п. напрямую влияют на этот процесс.
Да.
F>Ну и это проще отлаживать — ведь стэк содержит всё что надо, так что можно довольно легко "осмотреться".
Это только в тривиальных вещах, типа высокоуровневых объявлений.
А математические сложенные выражения с вызовами ф-ий отродясь было удобней восходящим разбором парсить.
Там и стек разбора более удобен для "осмотреться", бо в нём уже присутствуют свернутые однозначные нетерминалы. Сравнить с нисходящим разбором, где в каждый момент времени имеем лишь один из потенциальных вариантов.
F> Понятно, что на основе GLR и других подходов можно добиться даже бОльшего и вроде как и проще, но прийдется как минимум написать толковый генератор парсера с какими-то уникальными расширениями.
Фишка в том, что все мейнстримовые генераторы парсеров умеют генерить LR-разбор (LALR/GLR). А вот дополнительно LL(k), или обобщенный LL(1), т.е. Эрли — лишь считанные единицы из них. И такое жжж не спроста. (С)
F>В итоге, имхо, — проще сопровождать 1-2Мб кода без всяких выворотов, особенно когда сам язык и его грамматика вполне это позволяют.
Декомпозиция как раз избавляет от вывертов. В каждом текущем контексте разбора у нас обрабатывается ограниченное подмножество правил (т.е. имеем дело в подграмматикой). Например, ты не можешь внутри математических выражений объявлять типы.
F>Вдобавок и работают быстро. Для промышленных C/C++ — это вполне оправдано.
Быстро — это когда без откатов, т.е. LR-семейство.
Для LL(1) быстро будет только на заведомо однозначных выражениях — ну вот объявление типа, например. Такую ерунду легко парсить ручным LL(1-2) парсером (т.е. с предпросмотром на 1-2 лексемы).
F>Интересно какие парсеры используются в icc и msvc.
Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.
Re[19]: Опциональные типы
Здравствуйте, fddima, Вы писали:
F>>>Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
V>>Это просто декомпозиция грамматик.
F> Ты можешь называть их как хочешь, я бы сказал наоборот — позволяет динамически видоизменять грамматику (это скорее композиция)
Пофик.
Разбиваем целое на части — декомпозиция.
Собираем целое из частей — композиция.
F>ведь ключи компиляции c99,c11 и т.п. напрямую влияют на этот процесс.
Да.
F>Ну и это проще отлаживать — ведь стэк содержит всё что надо, так что можно довольно легко "осмотреться".
Это только в тривиальных вещах, типа высокоуровневых объявлений.
А математические вложенные выражения с вызовами ф-ий отродясь было удобней восходящим разбором парсить.
Там и стек разбора более удобен для "осмотреться", бо в нём уже присутствуют свернутые однозначные нетерминалы. Сравнить с нисходящим разбором, где в каждый момент времени имеем лишь один из потенциальных вариантов.
F> Понятно, что на основе GLR и других подходов можно добиться даже бОльшего и вроде как и проще, но прийдется как минимум написать толковый генератор парсера с какими-то уникальными расширениями.
Фишка в том, что все мейнстримовые генераторы парсеров умеют генерить LR-разбор (LALR/GLR). А вот дополнительно LL(k), или обобщенный LL(1), т.е. Эрли — лишь считанные единицы из них. И такое жжж не спроста. (С)
F>В итоге, имхо, — проще сопровождать 1-2Мб кода без всяких выворотов, особенно когда сам язык и его грамматика вполне это позволяют.
Декомпозиция как раз избавляет от вывертов. В каждом текущем контексте разбора у нас обрабатывается ограниченное подмножество правил (т.е. имеем дело в подграмматикой). Например, ты не можешь внутри математических выражений объявлять типы.
F>Вдобавок и работают быстро. Для промышленных C/C++ — это вполне оправдано.
Быстро — это когда без откатов, т.е. LR-семейство.
Для LL(1) быстро будет только на заведомо однозначных выражениях — ну вот объявление типа, например. Такую ерунду легко парсить ручным LL(1-2) парсером (т.е. с предпросмотром на 1-2 лексемы).
F>Интересно какие парсеры используются в icc и msvc.
Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.
F>>>Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
V>>Это просто декомпозиция грамматик.
F> Ты можешь называть их как хочешь, я бы сказал наоборот — позволяет динамически видоизменять грамматику (это скорее композиция)
Пофик.
Разбиваем целое на части — декомпозиция.
Собираем целое из частей — композиция.
F>ведь ключи компиляции c99,c11 и т.п. напрямую влияют на этот процесс.
Да.
F>Ну и это проще отлаживать — ведь стэк содержит всё что надо, так что можно довольно легко "осмотреться".
Это только в тривиальных вещах, типа высокоуровневых объявлений.
А математические вложенные выражения с вызовами ф-ий отродясь было удобней восходящим разбором парсить.
Там и стек разбора более удобен для "осмотреться", бо в нём уже присутствуют свернутые однозначные нетерминалы. Сравнить с нисходящим разбором, где в каждый момент времени имеем лишь один из потенциальных вариантов.
F> Понятно, что на основе GLR и других подходов можно добиться даже бОльшего и вроде как и проще, но прийдется как минимум написать толковый генератор парсера с какими-то уникальными расширениями.
Фишка в том, что все мейнстримовые генераторы парсеров умеют генерить LR-разбор (LALR/GLR). А вот дополнительно LL(k), или обобщенный LL(1), т.е. Эрли — лишь считанные единицы из них. И такое жжж не спроста. (С)
F>В итоге, имхо, — проще сопровождать 1-2Мб кода без всяких выворотов, особенно когда сам язык и его грамматика вполне это позволяют.
Декомпозиция как раз избавляет от вывертов. В каждом текущем контексте разбора у нас обрабатывается ограниченное подмножество правил (т.е. имеем дело в подграмматикой). Например, ты не можешь внутри математических выражений объявлять типы.
F>Вдобавок и работают быстро. Для промышленных C/C++ — это вполне оправдано.
Быстро — это когда без откатов, т.е. LR-семейство.
Для LL(1) быстро будет только на заведомо однозначных выражениях — ну вот объявление типа, например. Такую ерунду легко парсить ручным LL(1-2) парсером (т.е. с предпросмотром на 1-2 лексемы).
F>Интересно какие парсеры используются в icc и msvc.
Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.