---------- Forwarded Message ----------
Subject: Re: [LVK Tech] Вопрос про поддержку ММ-языка Date: Sunday 28 May 2006 19:32 From: Konstantin Savenkov savenkov@cs.msu.su To: Maksim Chistolinov mike@lvk.cs.msu.su
Макс, я не собираюсь нападать на Диану и mmt :-) Мне просто интересно, пытались ли делать чисто С++-решение и с какими трудностями при этом сталкивались. Если угодно, меня интересует использования макросов для обратной совместимости С++ библиотеки моделирования (например, той, которая разработана в рамках нашего проекта) с ММ.
Однако обсуждением деталей ты меня, надо сказать, заинтересовал...
Собственно, что делает mmt:
- Отображение ММ на C++, при этом:
- скрываются всякие "нагромождения" С++ (то, что Анатолий называл "ритуальными плясками") и детали интерфейсов библиотеки моделирования;
Для этого существуют средства языка С++. Абстракция + инкапсуляция, и никаких плясок с бубном.
- добавляется полезная информация, например, о номерах строк и номерах операторов в тексте;
Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-)
- Выпоняется _полный_ синтаксический и семантический анализ операторов ММ, что сделать "на макросах" достаточно затруднительно. (не вполне удачный опыт - язык описания моделей СММ КБО).
Макс, если ты объявляешь метод receive(), то его анализ выполняется g++, при этом никакие макросы не нужны.
- Диагностика формируется в терминах ММ-языка. Не соглашусь, что она плоха. Если кто-то заметил там ошибки в сообщениях - пишите bug report-ы, это легко пофиксеть. Решать задачу "фильтрации" и "русификации" диагностики g++
(неудачный опыт - см. тот же СММ)
- это криво и очень громоздко.
?? Если я сейчас -- первый, кто их заметил, то у меня нет слов. Впрочем, орфография ни на что не влияет, это я так, к слову пришлось :-)
- Строится синтаксическре дерево, которое может быть очень полезно для решения задач анализа, трансляции, оптимизации и т.д.
Макс, я, например, для удобной работы с ММ-языком (для анализа и трансляции как раз) написал свой парсер на Whale. Потому что так удобнее, чем работать с выходом ANTLR (с ним я раньше работал). Написал причём недели за две.
- На исходное множество возможностей С (С++) накладывается ряд ограничений, что еще никому не было вредно.
Э... не могу не прокомментировать. Это например то, что переменные должны быть объявлены на начале блока?
Я голосую за Язык + Транслятор.
Да не вопрос :-) Ещё раз повторюсь -- меня интересует _возможность_ "чистой" реализации MM-like языка (скорее из соображений совместимости) и потенциальные проблемы.
Это примерно как знаешь есть такая типичная история, когда админу говорят "ставь окна", а он ставит линух с кросс-офисом, и никто ничего не замечает. Это, конечно, байка, а вот с языком моделирования, сдаётся мне, такое вполне возможно :-)
Костя.
-------------------------------------------------------
---------- Forwarded Message ----------
Subject: Re: [LVK Tech] Вопрос про поддержку ММ-языка Date: Sunday 28 May 2006 19:32 From: Konstantin Savenkov savenkov@cs.msu.su To: Maksim Chistolinov mike@lvk.cs.msu.su
Макс, я не собираюсь нападать на Диану и mmt :-) Мне просто интересно, пытались ли делать чисто С++-решение и с какими трудностями при этом сталкивались.
Навскидку - я не знаю, как средствами чистого Си++ реализовать доступ к полям сообщения - с учётом того, что по синтаксису mm языка там используется операция ".", имена полей - свои для каждого типа сообщений, и одна и та же msg переменная может хранить сообщения любого типа.
Кроме того - определённые трудности могут быть с операторами select/accept.
А отвечая на всё - напоминаю два фактора:
- прошлые версии mmt были фактически препроцессором (без построения синтаксического дерева и т.п.). Это приводило к многочисленных техническим проблемам - конкретику я уже не помню, может Макс или Толя вспомнят - которые и были решены переходом к текущей схеме.
- разговор о том, нужен язык или Си++-библиотека, идёт уже лет так десять. Вывод, который сделал я, примерно такой - mm-язык любят "теоретики" (см. аргументы Макса в его письмах в этот thread), либо "менеджеры" (язык Дианы - trademark или как там это называется). А не любят те, кому приходится на нём реально программировать проекты.
- добавляется полезная информация, например, о номерах строк и номерах операторов в тексте;Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-)
В Диане было такое средство - переход от события к строке текста модели. Это было реализовано путём составления таблицы операторов; в трассу записывался номер оператора, а mmt в т.ч. создавал таблицу операторов, в которой хранилось в т.ч. положение этого оператора в исходном тексте модели.
- Строится синтаксическре дерево, которое может быть очень полезно для решения задач анализа, трансляции, оптимизации и т.д.
Макс, я, например, для удобной работы с ММ-языком (для анализа и трансляции как раз) написал свой парсер на Whale. Потому что так удобнее, чем работать с выходом ANTLR (с ним я раньше работал). Написал причём недели за две.
Это относится к вопросу о том, как сделать "удобный в использовании" транслятор. Между прочим, эта задача поставлена студенту, которым руководит Саша Герасёв. Ты взаимодействовал с ними по этому поводу?
On Monday 29 May 2006 12:35, Nikita V. Youshchenko wrote:
---------- Forwarded Message ----------
Subject: Re: [LVK Tech] Вопрос про поддержку ММ-языка Date: Sunday 28 May 2006 19:32 From: Konstantin Savenkov savenkov@cs.msu.su To: Maksim Chistolinov mike@lvk.cs.msu.su
Макс, я не собираюсь нападать на Диану и mmt :-) Мне просто интересно, пытались ли делать чисто С++-решение и с какими трудностями при этом сталкивались.
Навскидку - я не знаю, как средствами чистого Си++ реализовать доступ к полям сообщения - с учётом того, что по синтаксису mm языка там используется операция ".", имена полей - свои для каждого типа сообщений, и одна и та же msg переменная может хранить сообщения любого типа.
Создать иерархию типов сообщений. Использовать static_cast/dynamic_cast. Код станет только понятней.
Кроме того - определённые трудности могут быть с операторами select/accept.
А отвечая на всё - напоминаю два фактора:
- прошлые версии mmt были фактически препроцессором (без построения
синтаксического дерева и т.п.). Это приводило к многочисленных техническим проблемам - конкретику я уже не помню, может Макс или Толя вспомнят - которые и были решены переходом к текущей схеме.
- разговор о том, нужен язык или Си++-библиотека, идёт уже лет так десять.
Вывод, который сделал я, примерно такой - mm-язык любят "теоретики" (см. аргументы Макса в его письмах в этот thread), либо "менеджеры" (язык Дианы
- trademark или как там это называется). А не любят те, кому приходится на
нём реально программировать проекты.
- добавляется полезная информация, например, о номерах строк и номерах операторов в тексте;Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-)
В Диане было такое средство - переход от события к строке текста модели. Это было реализовано путём составления таблицы операторов; в трассу записывался номер оператора, а mmt в т.ч. создавал таблицу операторов, в которой хранилось в т.ч. положение этого оператора в исходном тексте модели.
Это решается путем записи в трассу текущего указателя команд x86 и нахождению строки по отладочной информации.
- Строится синтаксическре дерево, которое может быть очень полезно для решения задач анализа, трансляции, оптимизации и т.д.
Макс, я, например, для удобной работы с ММ-языком (для анализа и трансляции как раз) написал свой парсер на Whale. Потому что так удобнее, чем работать с выходом ANTLR (с ним я раньше работал). Написал причём недели за две.
Это относится к вопросу о том, как сделать "удобный в использовании" транслятор. Между прочим, эта задача поставлена студенту, которым руководит Саша Герасёв. Ты взаимодействовал с ними по этому поводу?
Если я правильно понимаю, студент как свою реализацию предоставил код, которые не компилируется, просто потому что так точек с запятой в правильном месте нет. Многообещающий студент, однако.
- Volodya
- добавляется полезная информация, например, о номерах строк и номерах операторов в тексте;Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-)
В Диане было такое средство - переход от события к строке текста модели. Это было реализовано путём составления таблицы операторов; в трассу записывался номер оператора, а mmt в т.ч. создавал таблицу операторов, в которой хранилось в т.ч. положение этого оператора в исходном тексте модели.
Это решается путем записи в трассу текущего указателя команд x86 и нахождению строки по отладочной информации.
Сомневаюсь, что это надёжно - особенно с учётом оптимизаций типа инлайнинга вызовов и переупорядочивания кода между проинлайненным и местным. Ровно как и сомневаюсь в целесообразности связываться со столь громоздкой вещью, как отладочная информация, для столь простой цели.
Макс, я, например, для удобной работы с ММ-языком (для анализа и трансляции как раз) написал свой парсер на Whale. Потому что так удобнее, чем работать с выходом ANTLR (с ним я раньше работал). Написал причём недели за две.
Это относится к вопросу о том, как сделать "удобный в использовании" транслятор. Между прочим, эта задача поставлена студенту, которым руководит Саша Герасёв. Ты взаимодействовал с ними по этому поводу?
Если я правильно понимаю, студент как свою реализацию предоставил код, которые не компилируется, просто потому что так точек с запятой в правильном месте нет. Многообещающий студент, однако.
А дело не в том, что студент плох (тем более что на момент, когда Костя этим занимался, ещё не было известно, каков студент), а в том, что одну и ту же [нетривиальную] задачу начинают решать два человека, сидящие в соседних комнатах, без попыток синхронизации. Сипмтоматично. Хотя и оффтопик для данной рассылки.
Если я правильно понимаю, студент как свою реализацию предоставил код, которые не компилируется, просто потому что так точек с запятой в правильном месте нет. Многообещающий студент, однако.
А дело не в том, что студент плох (тем более что на момент, когда Костя этим занимался, ещё не было известно, каков студент), а в том, что одну и ту же [нетривиальную] задачу начинают решать два человека, сидящие в соседних комнатах, без попыток синхронизации. Сипмтоматично. Хотя и оффтопик для данной рассылки.
Никит, когда я это сделал (прошлой осенью), студент эти не занимался. Более того, создание парсера имеет смысл, когда есть конкретная цель, для достижения которой будет строиться дерево разбора. Очевидно, что в моём случае это совсем не та цель, для которой этим занимается студент Саши.
Что до нетривиальности задачи...кхм. Задача кодогенерации -- возможно, но парсинг...
Костя.
Что до нетривиальности задачи...кхм. Задача кодогенерации -- возможно, но парсинг...
ИМХО, всё, что не делается за пару часов - нетривиально. Тут же шла речь про две недели.
Нет. Это тривиальная техническая работа -- последовательно идти по грамматике или описанию языка и приводить её в нужный вид. Просто этой работы довольно много по объёму. Здесь бы был нетривиальным семантический анализ, но я им не занимался.
Ну да ладно, в общем, оффтопик :-)
Костя.
Что до нетривиальности задачи...кхм. Задача кодогенерации -- возможно, но парсинг...
ИМХО, всё, что не делается за пару часов - нетривиально. Тут же шла речь про две недели.
Нет. Это тривиальная техническая работа -- последовательно идти по грамматике или описанию языка и приводить её в нужный вид. Просто этой работы довольно много по объёму.
Ну если на то пошло, то 95% всей программистской работы "тривиально" - просто её много. Смотря как определять тривиальность.
On Monday 29 May 2006 16:10, Nikita V. Youshchenko wrote:
- добавляется полезная информация, например, о номерах строк и номерах операторов в тексте;Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-)
В Диане было такое средство - переход от события к строке текста модели. Это было реализовано путём составления таблицы операторов; в трассу записывался номер оператора, а mmt в т.ч. создавал таблицу операторов, в которой хранилось в т.ч. положение этого оператора в исходном тексте модели.
Это решается путем записи в трассу текущего указателя команд x86 и нахождению строки по отладочной информации.
Сомневаюсь, что это надёжно - особенно с учётом оптимизаций типа инлайнинга вызовов и переупорядочивания кода между проинлайненным и местным.
Come on! Если ты добавляешь в генерированный код директивы препроцессора для указания номера строк, как это делается сейчас, то оптимизации с не меньшим удовольствием снесут эти номера строк.
Ровно как и сомневаюсь в целесообразности связываться со столь громоздкой вещью, как отладочная информация, для столь простой цели.
Открываешь трубу к gdb, и посылаешь одну команду. Все это делается за пол-дня.
Макс, я, например, для удобной работы с ММ-языком (для анализа и трансляции как раз) написал свой парсер на Whale. Потому что так удобнее, чем работать с выходом ANTLR (с ним я раньше работал). Написал причём недели за две.
Это относится к вопросу о том, как сделать "удобный в использовании" транслятор. Между прочим, эта задача поставлена студенту, которым руководит Саша Герасёв. Ты взаимодействовал с ними по этому поводу?
Если я правильно понимаю, студент как свою реализацию предоставил код, которые не компилируется, просто потому что так точек с запятой в правильном месте нет. Многообещающий студент, однако.
А дело не в том, что студент плох (тем более что на момент, когда Костя этим занимался, ещё не было известно, каков студент), а в том, что одну и ту же [нетривиальную] задачу начинают решать два человека, сидящие в соседних комнатах, без попыток синхронизации. Сипмтоматично. Хотя и оффтопик для данной рассылки.
Ну, можно в эту рассылку писать о всех непривиальных задачах, которые кто-то начинает решать.
- Volodya
Это решается путем записи в трассу текущего указателя команд x86 и нахождению строки по отладочной информации.
Сомневаюсь, что это надёжно - особенно с учётом оптимизаций типа инлайнинга вызовов и переупорядочивания кода между проинлайненным и местным.
Come on! Если ты добавляешь в генерированный код директивы препроцессора для указания номера строк, как это делается сейчас, то оптимизации с не меньшим удовольствием снесут эти номера строк.
В случае номером операторов конструкция "файл:строка" в виде СИ-шной строки вставлялась в генерируемый код.
Ровно как и сомневаюсь в целесообразности связываться со столь громоздкой вещью, как отладочная информация, для столь простой цели.
Открываешь трубу к gdb, и посылаешь одну команду. Все это делается за пол-дня.
... и тем самым создаёшь конструкцию, сложность которой совершенно не соответствует задаче. Особенно с учётом ... хмм ... того, что скорость работы gdb (да пожалуй и его стабильность) оставляет желать лучшего.
А дело не в том, что студент плох (тем более что на момент, когда Костя этим занимался, ещё не было известно, каков студент), а в том, что одну и ту же [нетривиальную] задачу начинают решать два человека, сидящие в соседних комнатах, без попыток синхронизации. Сипмтоматично. Хотя и оффтопик для данной рассылки.
Ну, можно в эту рассылку писать о всех непривиальных задачах, которые кто-то начинает решать.
Ну с точки зрения продуктивности работы это было бы наверное неплохо. Хотя сомневаюсь, что получится реально заставить себя это писать, читать и комментировать.
С другой стороны, в данном конкретном случае информация была - в виде постановки задачи на форуме...
А дело не в том, что студент плох (тем более что на момент, когда Костя этим занимался, ещё не было известно, каков студент), а в том, что одну и ту же [нетривиальную] задачу начинают решать два человека, сидящие в соседних комнатах, без попыток синхронизации. Сипмтоматично. Хотя и оффтопик для данной рассылки.
Ну, можно в эту рассылку писать о всех непривиальных задачах, которые кто-то начинает решать.
Ну с точки зрения продуктивности работы это было бы наверное неплохо. Хотя сомневаюсь, что получится реально заставить себя это писать, читать и комментировать.
С другой стороны, в данном конкретном случае информация была - в виде постановки задачи на форуме...
На тот момент у меня парсер уже был. Я говорил об этом Саше. Но если у студента была задача ознакомиться с Whale, то написание грамматики для простого разбора MM-языка -- это ТРИВИАЛЬНЕЙШАЯ задача, на которой это ознакомление можно провести. Особенно с учётом того, что грамматика С для Whale существует и доступна.
Костя.
Макс, я не собираюсь нападать на Диану и mmt :-) Мне просто интересно, пытались ли делать чисто С++-решение и с какими трудностями при этом сталкивались.
Навскидку - я не знаю, как средствами чистого Си++ реализовать доступ к полям сообщения - с учётом того, что по синтаксису mm языка там используется операция ".", имена полей - свои для каждого типа сообщений, и одна и та же msg переменная может хранить сообщения любого типа.
По-моему, в ММ и так есть базовый для всех тип MESSAGE, на которым строится иерархия типов сообщений. При этом для того, чтобы изменился "распознаваемый" тип переменной, используется конструкция assume -- вместо неё с успехом может быть тот или иной cast (ну или assume может разворачиваться в cast макросом).
Кроме того - определённые трудности могут быть с операторами select/accept.
Их можно сделать как switch c предварительным вызовом функции монитора, возвращающей нужный буфер. Ну или как-то так.
А отвечая на всё - напоминаю два фактора:
- прошлые версии mmt были фактически препроцессором (без построения
синтаксического дерева и т.п.). Это приводило к многочисленных техническим проблемам - конкретику я уже не помню, может Макс или Толя вспомнят - которые и были решены переходом к текущей схеме.
Вот-вот, очень интересно было бы. потому что я предполагаю, что проблемы должны быть. Но пока то, что писал Макс относится скорее к идеологии.
- разговор о том, нужен язык или Си++-библиотека, идёт уже лет так десять.
Вывод, который сделал я, примерно такой - mm-язык любят "теоретики" (см. аргументы Макса в его письмах в этот thread), либо "менеджеры" (язык Дианы
- trademark или как там это называется). А не любят те, кому приходится на
нём реально программировать проекты.
- добавляется полезная информация, например, о номерах строк и номерах операторов в тексте;Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-)
В Диане было такое средство - переход от события к строке текста модели. Это было реализовано путём составления таблицы операторов; в трассу записывался номер оператора, а mmt в т.ч. создавал таблицу операторов, в которой хранилось в т.ч. положение этого оператора в исходном тексте модели.
Да, это интересная проблема.
Костя.
Навскидку - я не знаю, как средствами чистого Си++ реализовать доступ к полям сообщения - с учётом того, что по синтаксису mm языка там используется операция ".", имена полей - свои для каждого типа сообщений, и одна и та же msg переменная может хранить сообщения любого типа.
По-моему, в ММ и так есть базовый для всех тип MESSAGE, на которым строится иерархия типов сообщений. При этом для того, чтобы изменился "распознаваемый" тип переменной, используется конструкция assume -- вместо неё с успехом может быть тот или иной cast (ну или assume может разворачиваться в cast макросом).
Итак, конструкция в mm:
... assume m == message X; m.x1 = 5; m.x2 = 6; ... assump m == message Y; m.y1 = 7; m.y2 = 8; ...
Причём это в одном блоке кода. Корректная с точки зрения mm-языка конструкция. Как предлагается построить средство типа "локальный препроцессор" - без памяти о том что где-то раньше был assume для m, который ничем не был перекрыт - которое правильно в первых двух присваиваниях сделает cast на message_X, а во втором - на message_Y?
Да и отдельный cast не очень понятен - что в строке "m.x1 = 5" ты сделаешь макросом? Варианты с изменением синтаксиса языка не канают :).
В сообщении от 29 Май 2006 16:28 Nikita V. Youshchenko написал:
Навскидку - я не знаю, как средствами чистого Си++ реализовать доступ к полям сообщения - с учётом того, что по синтаксису mm языка там используется операция ".", имена полей - свои для каждого типа сообщений, и одна и та же msg переменная может хранить сообщения любого типа.
По-моему, в ММ и так есть базовый для всех тип MESSAGE, на которым строится иерархия типов сообщений. При этом для того, чтобы изменился "распознаваемый" тип переменной, используется конструкция assume -- вместо неё с успехом может быть тот или иной cast (ну или assume может разворачиваться в cast макросом).
Итак, конструкция в mm:
... assume m == message X; m.x1 = 5; m.x2 = 6; ... assump m == message Y; m.y1 = 7; m.y2 = 8; ...
Причём это в одном блоке кода. Корректная с точки зрения mm-языка конструкция. Как предлагается построить средство типа "локальный препроцессор" - без памяти о том что где-то раньше был assume для m, который ничем не был перекрыт - которое правильно в первых двух присваиваниях сделает cast на message_X, а во втором - на message_Y?
Если ММ-язык позволяет использовать нечто вроде
receive(m,i); assume m == message X; int a = m.a; assume m == message Y; int b = m.b;
то это явный design flaw синтаксиса языка, поскольку я с трудом представляю ситуацию, в которой это может сработать. Должен быть динамический контроль типа, так, чтобы assume на "неправильный тип" не работал. Это можно и нужно делать при помощи dynamic_cast.
Если ты посмотришь на то, как assume используется, то парадигма такая:
receive(m,i); if(m == message X) { assume m == message X; ... } if(m == message Y) { assume m == message Y; ... }
И только так!
Ну максимум что нужно будет сделать -- использовать m->x1 вместо m.x1 :-) m == message X => dynamic_cast<X>(m) assume m == message X => m = dynamic_cast<X>(m)
Я думаю, что Володя сможет предложить более красивое и полное решение, но нужно ли? Принципиальных проблем тут нет.
Я полагаю, что по части синтаксиса тут в полной мере работает правило 80/20, т.е. на 20% поддержки синтаксиса потребуется 80% всех усилий. А то и на 5%. Так что проще слегка изменить синтаксис :-)
Костя.
-
Konstantin Savenkov -
Nikita V. Youshchenko -
Vladimir Prus