В смысле кажется? Вы же пишите статью для обучения, и надеюсь, прочитали то, что (вам) понаписали?
Что-то у меня после этих ваших заявлений очень сильный скепсис по поводу выполнения вами поставленной цели объяснить математику просто. Для этого в первую очередь ляпов не должно быть.
В дополнение можно указать, что ошибка, выдаваемая rust-peg, более простая, в сравнении с lalrpop - а именно, первый выдаёт только позицию и список ожидаемых токенов,
Зато вы можете самостоятельно перепарсить это место (т.е. начать разбор с указанного парсером места ошибки) уже другим парсером (даже PEG парсером, т.е. фактически другим правилом из той же грамматики) и получить то, что хотите. Хоть отдельный символ (хотя это и так уже есть по умолчанию), хоть слово (причем вы сами определяете, что такое "слово"). Более того, такие правила (на ошибочный вход), можно сознательно вставлять в грамматику в вероятных местах ошибки и прямо включать в выстраиваемый AST, чтобы потом обработать их на более верхнем уровне. Еще лучше, чтобы это делал парсер автоматически, но rust-peg этого (пока?) не умеет. Но если поинтересоваться темой, то люди делали такое для PEG парсеров и на хабре есть статья об этом.
Ваша идея довольно экстремальная - это ж придётся в процедурном макросе фактически произвести весь парсинг,
Так вы же и так это делаете в своем парсере MVL. Просто как я понял, сейчас вы запускаете генератор, он делает файлы, а потом эти файлы идут на вход компилятору Rust. Компилятор Rust вынужден эти исходники парсить, чтобы получить список токенов, которые потом он обрабатывает. А можно на вход компилятору сразу подавать список токенов.
разрешение идентификаторов, упорядочивание переменных по их зависимостям, аналитические и алгоритмические преобразования и оптимизации, и прочие операции.
А сейчас это кто делает? Ваш pipeline сейчас: (1)MVL -> (2)модель MVL в декларативных макросах Rust -> (3)декларативные макросы генерируют Rust код -> (4)компилятор Rust делает бинарник.
Я предлагаю убрать шаг 2 с сразу генерировать Rust код, как будто вы руками раскрыли макросы с шага 2, т.е. так: (1)MVL -> (2)процедурный макрос генерируют Rust код -> (3)компилятор Rust делает бинарник.
Как-то все же остались неясности, почему уже в самом описании парсера нельзя указать, тут name ключевое слово или нет. Ну то есть если в парсере в этом месте написано "name", то явно именна такая последовательность тут и ожидается и это ключевое слово. При этом оно ведь ожидается только в этом месте, в других местах вы спокойно в грамматике пишите <kw_name:id> и если там разбираемом тексте встретится name, оно будет как идентификатор распознано, а не ключевое слово. Или я тут чего-то не понимаю? Кстати, не смотрели на rust-peg?
Еще у вас получилось как-то странно: я так понял, вы написали парсер языка MVL, чтобы сгенерировать Rust-код на макросах, примерно повторяющем структуру исходного MVL, а в реализации макросов уже все делается. А почему бы просто не написать процедурный макрос, который принимает на вход MVL, а на выход дает Rust код, который это реализует?
Как использовать в сборке зависимости через rlib-файлы без исходников
Ну, просто в следствиях вы написали, что стало точнее. А это неправда (с численной точки зрения) и в скобочках можно было бы указать, что все было не так просто.
Конечно, в стародавние времена Копернику было достаточно сместить точку отсчёта с Земли на Солнце — небесная механика выровнялась с земной, а наблюдаемые результаты совпали с теми, что давали эпициклы.
Все-таки модель Коперника показывала предсказательные результаты хуже, чем модель эпициклов. Так что ссылаться на нее, как на хрестоматийный пример, некорректно. Вот когда Кеплер ввел эллипсы, тогда модель стала точнее.
Забавно, что можно провести параллели с этой статьей. Даже верные идеи (думаю, автор считает свою таковой, иначе зачем об этом писать?) могут быть искажены деталями в принятой реализации.
Думаю, если у этой пары людей дошло дело до автоматизации их процесса, то связь у них давно налажена намного более удобным образом, который не зависит от наличия в прямой видимости всяких китайских железок к примотанными к ним скотчем динамиками.
Ну, судя по фото в статье, он как раз торчит, ничем не приметный, среди другой такой же рассыпухи и даже рядом с каким-то разъемом (да там вся плата по размеру с один сплошной разъем, не сильно больше USB A, насколько я вижу -- все еще подходит под "разломал USB" ;)?). Если там на самой плате не написано, что это микрофон, то и не заметить, мне кажется...
А какой же? На самом устройстве на корпусе, поди, не написано, что вот тут микрофон, и даже дырочки нет, наверное. Это конечно не сразу что-то плохое, но оно отлично описывается словом hidden.
Удивительно, почему было сразу не начать с проверки мест использования изменившихся констант? Если только бит передвинулся, очевидно же, что с этим как-то связано
В смысле кажется? Вы же пишите статью для обучения, и надеюсь, прочитали то, что (вам) понаписали?
Что-то у меня после этих ваших заявлений очень сильный скепсис по поводу выполнения вами поставленной цели объяснить математику просто. Для этого в первую очередь ляпов не должно быть.
Зато вы можете самостоятельно перепарсить это место (т.е. начать разбор с указанного парсером места ошибки) уже другим парсером (даже PEG парсером, т.е. фактически другим правилом из той же грамматики) и получить то, что хотите. Хоть отдельный символ (хотя это и так уже есть по умолчанию), хоть слово (причем вы сами определяете, что такое "слово"). Более того, такие правила (на ошибочный вход), можно сознательно вставлять в грамматику в вероятных местах ошибки и прямо включать в выстраиваемый AST, чтобы потом обработать их на более верхнем уровне. Еще лучше, чтобы это делал парсер автоматически, но rust-peg этого (пока?) не умеет. Но если поинтересоваться темой, то люди делали такое для PEG парсеров и на хабре есть статья об этом.
Пример (в синтаксисе pegjs):
Как будто это что-то оправдывает
Сложным путем идет товарищ... Что мешало просто сохранить
findexв стеке Lua?Так вы же и так это делаете в своем парсере MVL. Просто как я понял, сейчас вы запускаете генератор, он делает файлы, а потом эти файлы идут на вход компилятору Rust. Компилятор Rust вынужден эти исходники парсить, чтобы получить список токенов, которые потом он обрабатывает. А можно на вход компилятору сразу подавать список токенов.
А сейчас это кто делает? Ваш pipeline сейчас: (1)MVL -> (2)модель MVL в декларативных макросах Rust -> (3)декларативные макросы генерируют Rust код -> (4)компилятор Rust делает бинарник.
Я предлагаю убрать шаг 2 с сразу генерировать Rust код, как будто вы руками раскрыли макросы с шага 2, т.е. так:
(1)MVL -> (2)процедурный макрос генерируют Rust код -> (3)компилятор Rust делает бинарник.
Как-то все же остались неясности, почему уже в самом описании парсера нельзя указать, тут
nameключевое слово или нет. Ну то есть если в парсере в этом месте написано"name", то явно именна такая последовательность тут и ожидается и это ключевое слово. При этом оно ведь ожидается только в этом месте, в других местах вы спокойно в грамматике пишите<kw_name:id>и если там разбираемом тексте встретитсяname, оно будет как идентификатор распознано, а не ключевое слово. Или я тут чего-то не понимаю? Кстати, не смотрели на rust-peg?Еще у вас получилось как-то странно: я так понял, вы написали парсер языка MVL, чтобы сгенерировать Rust-код на макросах, примерно повторяющем структуру исходного MVL, а в реализации макросов уже все делается. А почему бы просто не написать процедурный макрос, который принимает на вход MVL, а на выход дает Rust код, который это реализует?
Было бы интересно почитать
То есть сложный алгоритм на полтысячи строк не должен быть прокомментирован? Не завидую вашим читателям
Если верить квантовой механике, то как раз наоборот -- все в мире скачкообразно.
Гвоздь подвешен на нитке за острие.
Ну, просто в следствиях вы написали, что стало точнее. А это неправда (с численной точки зрения) и в скобочках можно было бы указать, что все было не так просто.
Ну-у-у, это и у математиков есть такая уязвимость. Наверное, поэтому им нобелевки не дают.</s>
Все-таки модель Коперника показывала предсказательные результаты хуже, чем модель эпициклов. Так что ссылаться на нее, как на хрестоматийный пример, некорректно. Вот когда Кеплер ввел эллипсы, тогда модель стала точнее.
Забавно, что можно провести параллели с этой статьей. Даже верные идеи (думаю, автор считает свою таковой, иначе зачем об этом писать?) могут быть искажены деталями в принятой реализации.
Ну так паники вместо встроенных неявных сегфолтов в C. А если при неправильном использовании все равно падать, то какие-то странные наезды получаются.
Думаю, если у этой пары людей дошло дело до автоматизации их процесса, то связь у них давно налажена намного более удобным образом, который не зависит от наличия в прямой видимости всяких китайских железок к примотанными к ним скотчем динамиками.
А если там половина строк -- это комментарии? Тоже плохо?
Ну, судя по фото в статье, он как раз торчит, ничем не приметный, среди другой такой же рассыпухи и даже рядом с каким-то разъемом (да там вся плата по размеру с один сплошной разъем, не сильно больше USB A, насколько я вижу -- все еще подходит под "разломал USB" ;)?). Если там на самой плате не написано, что это микрофон, то и не заметить, мне кажется...
А какой же? На самом устройстве на корпусе, поди, не написано, что вот тут микрофон, и даже дырочки нет, наверное. Это конечно не сразу что-то плохое, но оно отлично описывается словом hidden.
Но емкость дисков росла, чтобы это процентное отношение уменьшать, а не поддерживать постоянным...
А как они это померяли? Или просто от балды цифру в отчете написали, чтобы боялись?
Удивительно, почему было сразу не начать с проверки мест использования изменившихся констант? Если только бит передвинулся, очевидно же, что с этим как-то связано