Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Запилил статейку на эту тему со своими практиками, предлагаю обсудить. Но — с конструктивом, а не просто: "ты лошара неграмотная, я тебя на работу не возьму".
НС>Не помню такого. Но технологический уровень описанного, скажем так, не особо выше плинтуса.
Было, было.
Спасибо, что глянул и нашел время почитать. На высокий технологический уровень я и не претендовал, я и писал с целью вызвать дискуссию с прицелом узнать что-то новое и поднять свой уровень.
НС>Особо неверно вот это: НС>
НС>Делайте тупой построчный разбор. В 90 процентов случаев этого достаточно для DSL
Хочу не согласиться. Но, может, это просто моя "ошибка выжившего". Обычно хватает тупых инишек. Иногда — древовидных, где вложенность определяется отступами. Ещё реже — построчник с более хитрым синтаксисом, нежели у инишки. Полноценный лексер/парсер по всем правилам науки обычно нужен, если хочется парсить ЯП.
. Построчник, маркер директивы — '$', маркер продолжения строки (как в сишечке) — '\', маркеры для тупого сплита строки — ':' '-'. Зато через неделю уже в бой пошло.
НС>На прочтение и освоение чего то вроде драконов нужно потратить пару недель один раз в жизни, коли уж с профильным образованием не срослось. После этого пугаться лексеров и парсеров не будешь.
Дракон — драгон бук, что ли? Читал. Про образование — это типа задеть хотел? Я на кафедре ВТ учился, у нас было ближе к железу. Приятель учился на мат обеспечении ЭВМ, у них по парсерам был курс(ы). Я вот парсеры пишу между делом, а он 1С конфигурирует.
НС>Теперь про создание DSL в частности и языков в общем.
Спс. Хороший текст.
Но есть вопросы.
1) Примеры удачных DSL? Где взять? Чтобы с сорцами, чтобы понимать, как оно сделано. И сколько времени на это потрачено?
2) Тесты — хм. На них нет времени. Но у меня два отдела сотрудников, которые юзают мой DSL, если что-то не так — присылают исходники, которые его ломают.
3) Тесты — дампы AST как должно быть — руцами писать? У меня нет пары лет на вылизывание всего этого. Я за недельку по вечерам хочу тулзу сделать, чтобы снять часть рутины в основной работе
4) Вот пример
исходника на моём языке. Он сейчас вполне всех устраивает. Если тебе не сложно, не мог бы ты коротенько написать, как бы ты сделал его разбор? Ну, и как можно улучшить сам язык
У нас эта шляпа используется для обмена данными по шинам RS-232, RS-485 и CAN по своему протоколу. Его автор краем глаза посматривал на CANopen. Сейчас вот появились сторонние устройства в нашей CAN-сетке с CANopen'ом, пришлось в том проекте пересесть на CANopen и этот язык отлично на него лег. А вот CANopen'овские EDS — для описания профилей устройств используют что? Да-да, тупые инишки. А могли бы нормально сделать, там куча бездельников, и за каждый сраный документ денег хотят
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Я его трогал, тогда была только джава.
НС>Ты не перепутал язык, на котором он написан и его таргеты? Таргет для С++ там уже лет 20 точно есть.
Думаю, что не перепутал. Думаю, ты про 20 лет загнул. Я его трогал вроде во второй половине нулевых, и плюсиков вроде не было. Ну, или я эпично затупил, что тоже возможно
Здравствуйте, Marty, Вы писали:
M>Хочу не согласиться. Но, может, это просто моя "ошибка выжившего". Обычно хватает тупых инишек. Иногда — древовидных, где вложенность определяется отступами.
Хватать то хватает. Но ты продолжаешь делать ту же ошибку. Экономя человекодни на разработке инструмента теряешь человекогоды на его использовании. Активно используемый DSL (а делать его имеет смысл только при активном использовании) на много порядков умножает любое, даже копеечное удобство.
НС>>На прочтение и освоение чего то вроде драконов нужно потратить пару недель один раз в жизни, коли уж с профильным образованием не срослось. После этого пугаться лексеров и парсеров не будешь. M>Дракон — драгон бук, что ли? Читал. Про образование — это типа задеть хотел?
Нет. Просто не могу иначе объяснить проблему с элементарными вещами. Написать простейший LL парсер проще и быстрее, чем рукопашный непонятный парсер лопатить, а потом годами вылавливать из него баги.
M>Но есть вопросы. M>1) Примеры удачных DSL? Где взять?
DSL на то и DSL, что они D. Про твой D я ничего тебе посоветовать не могу. Возможно VHDL будет неплохим примером.
M>2) Тесты — хм. На них нет времени.
Мне надо повторить тезис про технологический уровень?
M>3) Тесты — дампы AST как должно быть — руцами писать? У меня нет пары лет на вылизывание всего этого.
Откуда взялась пара лет? Я куда более сложные DSL, уровня SQL, за 3-4 месяца один писал. С тестами. А то что у тебя — я вообще пока не понял при чем тут DSL. Такой ерунды у меня в том числе в текущих проектах — тонны каждый спринт.
M>4) Вот пример
исходника на моём языке. Он сейчас вполне всех устраивает. Если тебе не сложно, не мог бы ты коротенько написать, как бы ты сделал его разбор? Ну, и как можно улучшить сам язык
Зачем там знаки $ и #? Что в нем такого, чего нельзя описать на yaml или json примерно теми же усилиями? Зачем тут вообще DSL, если, за исключением разве импортов да typedef, это простейшая древовидная структура? Если основные потребители — те кто использует плюсы и шарп, то зачем было изобретать свой нестандартный синтаксис? ?#!rdlc в начале зачем? Чем отличается include от import?
Что касается улучшения — очень сложно тебе что то посоветовать не варясь в вашей предметной области и не понимая смысла написанного. Если совсем обще — я бы убрал весь визуальный мусор, все эти ненужные значки, ввел бы нормальный конец строки и отказался от бейсиковых слешей для переноса. Синтаксис взял бы стандартный сишный. Сделал бы язык попонятнее — какие то префиксы в импорте, которых ниже по тексту нет, какой то ro, какие то неймспейсы сами по себе не ясно к чему относящиеся. Куча underscores.
generator=cpp:struct как бы намекает, что вместе с целевой областью тут какая то мешанина инструкций для процессинга, зачем оно там? В той секции что капсами — куча повторяющихся слов.
<< это что? Распиновка? >> может там быть? Если нет, то ты зря направленную, да еще и двойную лексему использовал. Достаточно симметричного значка типа -. Почему там слева везде только 1? Там может быть что то другое? Часто?
$typedef u8 : bool. По смыслу — новый тип u8, идентичный bool. А судя по тому что ниже — наоборот. Я понимаю что моск С++ испорчен, но там хоть : нет и можно какую то извращенную логику натянуть. Но лучше не заставлять человека гадать. type bool = u8 любого, с любым бекграундом, в заблуждение не введет, в отличие от.
Здравствуйте, Marty, Вы писали: M>Запилил статейку на эту тему со своими практиками, предлагаю обсудить. Но — с конструктивом, а не просто: "ты лошара неграмотная, я тебя на работу не возьму". Хочу понять, как таки это делать правильно и быстро.
Если честно, то ничего не понял. Больше похоже не на статью, а на тизер. Ну, типа как "экстреманльная евангелизация в фейсбуке" — пишем что-то типа "ANTLR говно, yacc говно, писать на yacc/bison — обмазаться говном", провоцируем дискуссию, в рамках которой ссылка на настоящую статью, приведённая в стартовом посте, всплывает в топ.
А так — непонятно примерно ничего. Объём текста большой, но нет никаких конкретных фактов, за которые бы можно было зацепиться взглядом или мозгом.
Зато есть куча путаницы. Типа — вот у нас парсинг, потом построение AST, потом генерация кода.
Тут же ремарка: "по факту про генераторы кода я ничего и не написал. Тут всё зависит от того, как вы спроектируете AST своей предметки."
И сразу же "Если генерить немного — просто пишу код генератора на плюсиках. "
Я уже запутался: кто что генерирует? Кто что написал или не написал?
Что значит "просто пишу код генератора на плюсиках"?
"код генератора" и "генератор кода" — это одно и то же, или наоборот?
Что значит "на плюсиках"? Упоминание о том, вы пишете на С++, уже было.
Оффтоп
Для полноты картины стоило бы, конечно, упомянуть и о том, что писать инструменты по трансляции кода на плюсах — это боль.
Например потому, что примерно 90% любого транслятора — это манипуляции с деревьями, в процессе которых узлы трансформируются, удаляются, и добавляются. Отслеживать время жизни руками — устанешь пот со лба утирать.
Любой язык со сборкой мусора даст 100 очков вперёд.
Далее, обработка гетерогенного дерева — это либо паттерн матчинг, либо паттерн визитор. Визитор — многословное, непонятное, трудноотлаживаемое месиво.
Поэтому, например, писать инструменты по трансляции кода на жабе — это боль.
Любой язык с паттерн-матчингом и сборкой мусора в этом смысле заруливает язык без них в минуса.
Именно поэтому, кстати, так популярны инструментальные средства по построению компиляторов для С++ и прочего — рукопашная работа там это просто ужоснах.
Вроде бы из этого сумбурного текста следует, что вы хотите рассказать о том, как делать AST из потока лексем.
Вот в этот момент было бы неплохо порассуждать о том, как, по-вашему, должно быть устроено это AST, от чего зависит это устройство, и так далее. Привести примеры.
Потом уже можно (потенциально) обсуждать, как именно поток байтиков (или лексем) превращается в AST. Увы, ничего этого нету. Кроме советов "просто пишите код".
В конце вы почему-то перескакиваете на генерацию кода, и внезапно оказывается, что задача написания своего DSL решается вовсе без DSL, прямой генерацией.
Кто на ком стоял?
В общем, тема — интересная, опыт у вас — богатый; но решительно непонятно, что именно вы хотели сказать, и чему научить аудиторию.
К примеру, у нас на ФИТ НГУ читают такой курс, как "Методы трансляции и компиляции программ". За 15 пар семинаров (это примерно 1 рабочая неделя) детишки от состояния "читаю java со словарём" переходят к состоянию "мы написали верифицирующий компилятор для аннотированных программ на модельном языке недетерминированного программирования". Очень рекомендую всем начинающим.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alpha21264, Вы писали:
A>Это очень зависит. A>Нынешняя практика парсинга опирается на Хомского, дегенераивные грамматики и позиционные языки, похожие на английский.
Ну Хомский там очень условный, как только что-то практическое — начинается отклонение.
Регэкспы — давно не вкладываются в регулярные грамматики.
PEG используется каждым вторым.
И прочая и прочая.
A>Я в моей практике (не очень сложных парсеров) пришёл к противоположной методике. A>Каждое слово языка имеет тэг. Первый символ (несколько символов) любой переменной — это тэг. A>И этот тэг определяет в какой массив и какую структуру AST ты его записываешь.
Есть такие языки, но в целом это неудобно. А вот необязательные префиксы с ролью принудительного чтения токена как идентификатора или как ключевого слова (то есть минимум два таких) — да, критично важно для современного языка. И ещё один для тегов (аннотации Java, "атрибуты" C#, хотя слово слишком многозначно).
И ещё, я думаю, у тебя нет префикса для всяких == < + и тому подобных
значит, подход неполный.
A>PS. A>Вот тут один персонаж (еретик) рассказывает про подобную методику. Только он ещё "иероглифы" (это такие своеобразные тэги) делает:
A>https://youtu.be/LxMj6ZYfbpU?t=898
Тоже забавно, но в общую практику вряд ли будет принято.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет. Просто не могу иначе объяснить проблему с элементарными вещами. Написать простейший LL парсер проще и быстрее, чем рукопашный непонятный парсер лопатить, а потом годами вылавливать из него баги.
Ну, ок, возможно. Где бы еще посмотреть на что-то такое готовое, чтобы понять, как оно делается
M>>2) Тесты — хм. На них нет времени. НС>Мне надо повторить тезис про технологический уровень?
Технологический уровень — как самоцель?
M>>4) Вот пример
исходника на моём языке. Он сейчас вполне всех устраивает. Если тебе не сложно, не мог бы ты коротенько написать, как бы ты сделал его разбор? Ну, и как можно улучшить сам язык НС>Зачем там знаки $ и #?
$ — признак директивы
# — комент
// — тоже комент
#!rdlc в начале — шебанг НС>Что в нем такого, чего нельзя описать на yaml или json примерно теми же усилиями? Зачем тут вообще DSL, если, за исключением разве импортов да typedef, это простейшая древовидная структура? Если основные потребители — те кто использует плюсы и шарп, то зачем было изобретать свой нестандартный синтаксис? ?#!rdlc в начале зачем? Чем отличается include от import?
$include — это просто текстуальное включение внешнего файла, как в сишечке
$import — импорт другого устройства. Например, в роботе несколько плат, но пульт общается с одной мастер платой, однако ему нужно смотреть регистры других плат. Тогда мастер-плата их форвардит, включая регистры дочернего устройства (причем только нужные в данном устройстве, для экономии адресов). Что-то типа наследования в плюсах
Пример
// Импортируемое устройство:
----
#!rdlc
$once
$type [format="#08b";generator=cpp:flags;generator=csharp:enum] SafetyStatusBits : u, 32 - "Биты внутреннего регистра Safety Status"
CELL_UNDERVOLTAGE : 1 << 0
$end_type
$type OtherSampleType : u32 - "Просто шляпа для примера"
thrill : 1<<5
fear : 1<<6
shake : 0x12<<7
fly : 'BF'
or : shake | creep | bit 12
CELL_UNDERVOLTAGE : ~(shake | SafetyStatusBits:CELL_UNDERVOLTAGE | 1<<6) - "Вытащил константу из другого типа. Ну, тут можно было наверно как в C++ сделать ::"
$end_type
$device "driver" - Драйвер
$namespace rw
$group
[tag=speed] speed_ctrl : s8 - скорость в % от -100 до 100
position_ctrl : u16 - позиция в градусах
$namespace ro
$group
[public] public : u8 - public
[protected] protected : u8 - protected
[private] private : u8 - private
$group Group A
[tag=speed] speed : s8 - текущая скорость в % от -100 до 100
position : u16 - позиция
$group [tag=status] Group B
temperature : u8 - температура мотора
current : s8 - текущий ток в % от -100 до 100
status : u8 - состояние драйвера, битовое поле ошибок
----
// Импортирующее устройство:
----
#!rdlc
$device "robot" - Робот Хоббот-Боббот
$import "driver" from "driver.rdl" as "Public1" prefix "pub1_" - Import public
$import [public] "driver" from "driver.rdl" as "Public2" prefix "pub2_" - Import public explicit
$import [protected] "driver" from "driver.rdl" as "Protected" prefix "prot_" - Import protected
$import [private] "driver" from "driver.rdl" as "Private" prefix "priv_" - Import private
$import [tag=speed] "driver" from "driver.rdl" as "Speed" prefix "speed_imp_" - Import speed by tag
$import [tag=status] "driver" from "driver.rdl" as "Status" prefix "status_imp_" - Import status by tag
$import [tag=speed,status] "driver" from "driver.rdl" as "SpeedStatus" prefix "speed_status_imp_" - Import speed and status by tag
$import [tag=speed;tag=status] "driver" from "driver.rdl" as "SpeedStatus2" prefix "speed_status_imp2_" - Import speed and status by tag - multiple tag attribute
----
НС>Что касается улучшения — очень сложно тебе что то посоветовать не варясь в вашей предметной области и не понимая смысла написанного. Если совсем обще — я бы убрал весь визуальный мусор, все эти ненужные значки, ввел бы нормальный конец строки и отказался от бейсиковых слешей для переноса.
Не обижай сишечный символ продолжения строки
На самом деле это было добавлено в самом конце, и стоило полкопейки. В результате развития хотелок пользователей добавились атрибуты (типа шарповых), и строки стали длинноваты, поэтому для удобства и добавил этот перенос.
НС>Синтаксис взял бы стандартный сишный. Сделал бы язык попонятнее — какие то префиксы в импорте, которых ниже по тексту нет, какой то ro, какие то неймспейсы сами по себе не ясно к чему относящиеся. Куча underscores.
Ну, у нас в протоколе все регистры делятся на два неймспейса — ReadOnly — статусные, и RW — управляющие
Сишный синтаксис — ну, такое. Например, я делал $typedef u32 uint32_t, ими 0 человек пользуется.
Язык для нас вполне понятный. Префиксы — это если в текущем и импортируемом устройстве есть одинаковые регистры, то при импорте можно задать префикс, чтобы не было ошибок.
НС>generator=cpp:struct как бы намекает, что вместе с целевой областью тут какая то мешанина инструкций для процессинга, зачем оно там? В той секции что капсами — куча повторяющихся слов.
Сразу видно, что это будет в целевом языке. Удобно. Мне и части коллег удобно так, другие задают всё в командной строке.
Про капс. Сишный коллега видно из кода дефайны тупо скопипастил, потому и капс. Повторяющихся — нет. Это параметры работы, на которой у нас BMS аккума сделан.
НС><< это что? Распиновка? >> может там быть? Если нет, то ты зря направленную, да еще и двойную лексему использовал. Достаточно симметричного значка типа -. Почему там слева везде только 1? Там может быть что то другое? Часто?
Это сдвиг, как в сишечке. Везде единичка — потому что это одиночные биты, другое тоже может быть, но редко. Обычно если нужна маска из нескольких бит, то обычно по or ('|') объединяются несколько ранее описанных битовых констант
НС>$typedef u8 : bool. По смыслу — новый тип u8, идентичный bool.
Нет. Новый тип bool, идентичный u8, как в сишечке.
НС>А судя по тому что ниже — наоборот.
А это паскалевский стиль. Тип переменной можно опустить, тогда будет принят u8, как самый часто встречающийся. Ну, некоторая нелогичность наверное есть, но вот никто, кроме тебя, не обращал внимания. Вообще, по языку вопросов никто не задавал, по языку — только хотелки, вопросы только по опциям командной строки возникают
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>Классический учебник по теме — https://www.springer.com/gp/book/9783642148453
МД>Отбой, она платная. Я люблю только всё на безвозмедной основе.
Я нашёл полный pdf этой книжки. Если кому-то нужно, могу выслать.
Здравствуйте, Marty, Вы писали:
M>Ну, ок, возможно. Где бы еще посмотреть на что-то такое готовое, чтобы понять, как оно делается
Примеры к antlr? Можно начать с калькулятора.
M>>>2) Тесты — хм. На них нет времени. НС>>Мне надо повторить тезис про технологический уровень? M>Технологический уровень — как самоцель?
Как необходимое условие выдавать код качественно и быстро.
НС>>Зачем там знаки $ и #? M>$ — признак директивы
Зачем?
M># — комент M>// — тоже комент
Зачем два коммента и оба, судя по всему, однострочных?
M>#!rdlc в начале — шебанг
Зачем? Все равно ведь эту штуку только из билда надо запускать.
M>$include — это просто текстуальное включение внешнего файла, как в сишечке M>$import — импорт другого устройства. Например, в роботе несколько плат, но пульт общается с одной мастер платой, однако ему нужно смотреть регистры других плат. Тогда мастер-плата их форвардит, включая регистры дочернего устройства (причем только нужные в данном устройстве, для экономии адресов).
Не многовато ли импортов для простенького файла?
M>На самом деле это было добавлено в самом конце, и стоило полкопейки.
Отличное оправдание. См. выше что я писал про экономию на разработке тула.
M>Язык для нас вполне понятный.
Понятный — не значит удобный. Домашнее задание: попробуй сократить размер своего примера хотя бы процентов на 30 без потери читаемости и семантического наполнения.
M> Префиксы — это если в текущем и импортируемом устройстве есть одинаковые регистры, то при импорте можно задать префикс, чтобы не было ошибок.
И неймпейсы, и префиксы. Опять миллион способов сделать одно и то же в простеньком языке.
НС>>А судя по тому что ниже — наоборот. M>А это паскалевский стиль.
Нет. В паскале type <TypeName> = type definition; end;
M> Тип переменной можно опустить, тогда будет принят u8, как самый часто встречающийся. Ну, некоторая нелогичность наверное есть, но вот никто, кроме тебя, не обращал внимания. Вообще, по языку вопросов никто не задавал
Ну вот и получился поэтому не особо удачный результат.
Здравствуйте, Marty, Вы писали:
M>Запилил статейку на эту тему со своими практиками, предлагаю обсудить. Но — с конструктивом, а не просто: "ты лошара неграмотная, я тебя на работу не возьму". Хочу понять, как таки это делать правильно и быстро.
I. Генератор кода для небольшого количества бульменее стабильных исходных — пишите на чем умеете прямо на том языке, без DSL.
II. Нужно чуть больше — берите XML (джейсон, если хотите и есть норм библиотеки)
III. Делайте тупой построчный разбор. В 90 процентов случаев этого достаточно для DSL
IV. Если метите в разработчики компиляторов — используйте соответствующие инструменты
V. Если вы уже разработчик компилятора — пишите всё ручками, оно потом дешевле будет
Можете раскрыть тему п.2 vs п.3 и п.3 vs п.4? П.2 и п.4 приходилось делать в том или ином виде, но не понятно какая мотивация нужна для п.3.
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>#!rdlc в начале — шебанг НС>Зачем? Все равно ведь эту штуку только из билда надо запускать.
Разные форматы могут требовать разной обработки.
Опираться только на суффикс файла — может быть непригодно для метода сопровождения проекта, и вообще некузяво.
M>>$include — это просто текстуальное включение внешнего файла, как в сишечке M>>$import — импорт другого устройства. Например, в роботе несколько плат, но пульт общается с одной мастер платой, однако ему нужно смотреть регистры других плат. Тогда мастер-плата их форвардит, включая регистры дочернего устройства (причем только нужные в данном устройстве, для экономии адресов). НС>Не многовато ли импортов для простенького файла?
Один простой файл может организовывать весь проект, это типично.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>>Классический учебник по теме — https://www.springer.com/gp/book/9783642148453
МД>>Отбой, она платная. Я люблю только всё на безвозмедной основе.
A>Я нашёл полный pdf этой книжки. Если кому-то нужно, могу выслать.
Это находится легко. Вот рецензию по смыслу было бы полезнее. Пока что увидел, что там подходы заметно отличаются от типовых направлений "драконщины", но с обилием математики — продираться будет долго.
Здравствуйте, alpha21264, Вы писали:
A>А что там такого? Покупать книжку за 50 долларов, чтобы убедиться, что там лажа я не буду. A>Это лучше или хуже, чем вот это? Тут вся грамматика английского языка умещается на одной странице:
Грамматика английского в принципе не может быть умещена на одной странице, если описывать в достаточных деталях. Например, в каких сочетаниях допускаются need или dare в качестве вспомогательных глаголов, или с какими глаголами допустим инфинитив в качестве прямого дополнения, с какими — герундий, а с какими — оба, но с разным смыслом.
A>И напоминаю — мы обсуждаем DSL. Натуральные языки — это совершенно другая тема.
Если смотреть на правила какого-нибудь C#, в каком случае > будет считаться знаком сравнения, а в каких — закрывающей скобкой шаблона, то это уже заметно напоминает естественные языки. А C++ так вообще превращается в один из них со своей зависимостью от контекста, который ещё не задан
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Здравствуйте, Marty, Вы писали:
МД>Нафига в ЖЖ? Ты бы еще в контактике запилил.
Вам-то чем плохо? Относительно надёжное хранилище (разве что весь СУП выльют), с надёжными постоянными ссылками, возможностью комментирования кем угодно (по openid), никто не фильтрует.
Здравствуйте, netch80, Вы писали:
N>Разные форматы могут требовать разной обработки. N>Опираться только на суффикс файла — может быть непригодно для метода сопровождения проекта, и вообще некузяво.
Да не надо опираться ни на шебанг, ни на суффикс файла. Такие вещи — часть build pipeline, а не что то, что нужно запускать руками из шелла.
НС>>Не многовато ли импортов для простенького файла? N>Один простой файл может организовывать весь проект, это типично.
Что значит организовать весь проект и при чем тут дизайн DSL? Чем больше ты всякой ерунды напихаешь в DSL, тем менее удобным он будет.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте!
M>Точнее — парсинг и построение AST
M>Запилил статейку на эту тему со своими практиками, предлагаю обсудить. Но — с конструктивом, а не просто: "ты лошара неграмотная, я тебя на работу не возьму". Хочу понять, как таки это делать правильно и быстро.
За последнее время делал пару раз DSL.
Один раз на Котлине, по типу грейдла, то есть никакох парсеров и прочих антлров нету. Просто описание модели в kts по типу gradle.
Второй раз на долбанном питоне. Схема та же самая DSL тоже питоновский скрипт, по удобству и выразительности убогому питону до котлина далеко. Впрочем тоже довольно удобно получилось.
Все конечно зависит от, но самое простое и быстрое это DSL as code. Подход Gradle, Jenkins и т.д.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Разные форматы могут требовать разной обработки. N>>Опираться только на суффикс файла — может быть непригодно для метода сопровождения проекта, и вообще некузяво. НС>Да не надо опираться ни на шебанг, ни на суффикс файла. Такие вещи — часть build pipeline, а не что то, что нужно запускать руками из шелла.
При чём тут шелл? Это стандарт де факто пометки типа содержимого файла. Я много раз видел варианты типа
#! foo 3
соответственно "формат foo, версия 3". Транслятор видит пометку и переключается в соответствующий режим, редактор на них реагирует, и всё такое.
И чем тут противоречие с build pipeline, не понимаю. Как раз удобно просто сказать "вот эти файлы включить в проект" и дальше пусть машина думает, что с ними делать — и да, таки build pipeline обрабатывает эти указания.
НС>>>Не многовато ли импортов для простенького файла? N>>Один простой файл может организовывать весь проект, это типично.
НС>Что значит организовать весь проект
Как в C, один файл с main() и ссылками на прочие декларации и/или исходники.
НС> и при чем тут дизайн DSL? Чем больше ты всякой ерунды напихаешь в DSL, тем менее удобным он будет.
Это верно ровно до тех пор, пока это действительно "ерунда", а не необходимые вещи.
Здравствуйте, netch80, Вы писали:
N>При чём тут шелл?
При том что эта фича в основном на запуск из шелла заточена.
N>соответственно "формат foo, версия 3". Транслятор видит пометку и переключается в соответствующий режим, редактор на них реагирует, и всё такое.
Ну вот о том и речь, что совершенно служебные вещи тащим в исходник.
НС>>Что значит организовать весь проект N>Как в C, один файл с main() и ссылками на прочие декларации и/или исходники.
Зачем? Почему не сделать файл проекта отдельным, не создавая ненужного шума в исходниках?
НС>> и при чем тут дизайн DSL? Чем больше ты всякой ерунды напихаешь в DSL, тем менее удобным он будет. N>Это верно ровно до тех пор, пока это действительно "ерунда", а не необходимые вещи.
Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место
Главный критерий языка — удобство его использования человеком.
Ты бы еще в контактике запилил.
