tech Май 2006

tech@asvk.cs.msu.ru

5 участники
4 обсуждения

Fwd: Re: [LVK Tech] Вопрос про поддержку ММ-языка
by Konstantin Savenkov 29 Май '06

29 Май '06

---------- Forwarded Message ---------- Subject: Re: [LVK Tech] Вопрос про поддержку ММ-языка Date: Sunday 28 May 2006 19:32 From: Konstantin Savenkov <savenkov(a)cs.msu.su> To: Maksim Chistolinov <mike(a)lvk.cs.msu.su> Макс, я не собираюсь нападать на Диану и mmt :-) Мне просто интересно, пытались ли делать чисто С++-решение и с какими трудностями при этом сталкивались. Если угодно, меня интересует использования макросов для обратной совместимости С++ библиотеки моделирования (например, той, которая разработана в рамках нашего проекта) с ММ. Однако обсуждением деталей ты меня, надо сказать, заинтересовал... > Собственно, что делает mmt: > 1. Отображение ММ на C++, при этом: > - скрываются всякие "нагромождения" С++ (то, что Анатолий > называл "ритуальными плясками") и детали интерфейсов > библиотеки моделирования; Для этого существуют средства языка С++. Абстракция + инкапсуляция, и никаких плясок с бубном. > - добавляется полезная информация, например, о номерах > строк и номерах операторов в тексте; Куда? В качестве отладочной информации в объектный файл? Как-то там отладчик для ММ поживает? :-) > 2. Выпоняется _полный_ синтаксический и семантический анализ > операторов ММ, что сделать "на макросах" достаточно затруднительно. > (не вполне удачный опыт - язык описания моделей СММ КБО). Макс, если ты объявляешь метод receive(), то его анализ выполняется g++, при этом никакие макросы не нужны. > 3. Диагностика формируется в терминах ММ-языка. > Не соглашусь, что она плоха. Если кто-то заметил там > ошибки в сообщениях - пишите bug report-ы, это легко пофиксеть. > Решать задачу "фильтрации" и "русификации" диагностики g++ > - это криво и очень громоздко. > (неудачный опыт - см. тот же СММ) ?? Если я сейчас -- первый, кто их заметил, то у меня нет слов. Впрочем, орфография ни на что не влияет, это я так, к слову пришлось :-) > 4. Строится синтаксическре дерево, которое может быть очень полезно > для решения задач анализа, трансляции, оптимизации и т.д. Макс, я, например, для удобной работы с ММ-языком (для анализа и трансляции как раз) написал свой парсер на Whale. Потому что так удобнее, чем работать с выходом ANTLR (с ним я раньше работал). Написал причём недели за две. > 5. На исходное множество возможностей С (С++) накладывается > ряд ограничений, что еще никому не было вредно. Э... не могу не прокомментировать. Это например то, что переменные должны быть объявлены на начале блока? > Я голосую за Язык + Транслятор. Да не вопрос :-) Ещё раз повторюсь -- меня интересует _возможность_ "чистой" реализации MM-like языка (скорее из соображений совместимости) и потенциальные проблемы. Это примерно как знаешь есть такая типичная история, когда админу говорят "ставь окна", а он ставит линух с кросс-офисом, и никто ничего не замечает. Это, конечно, байка, а вот с языком моделирования, сдаётся мне, такое вполне возможно :-) Костя. -------------------------------------------------------

3 13

Вопрос про поддержку ММ-языка
by Konstantin Savenkov 29 Май '06

29 Май '06

Привет, коллеги. Вопрос, наверное, в первую очередь к Никите, но м.б. у остальных тоже возникнут здравые идеи. Когда я думаю о том, как было бы грамотно организовать технически работу с ММ-языком, мне представляется нечто вроде билиотеки классов вида class Process { public: Process(const string& name, const vector<InputBuffer>&, const vector<OutputBuffer>&); void receive(Message& m, InputBuffer& b); void send(const Message& m, OutputBuffer& b); et cetera(); } и набор макросов, разворачивающих MM-style описание process P() <input i, output o> { ...text... } в class P : public Process { void body() { ...text... } } В мелких деталях я мог по ходу наврать, но идея, надеюсь, понятна. Вопрос: почему используется не подобный подход, а трансляция ММ->С ? М.б. приведённый мной подход пробовали, но нашли там подводные камни? Если нет, то вопрос к Саше Герасёву: нужно ли твоему студенту делать н-ную версию транслятора ММ-С? Не лучше ли его занять вышеприведённым вариантом? Спасибо за внимание, Костя.

3 2

Fwd: Re: [LVK Tech] Вопрос про поддержку ММ-языка
by Konstantin Savenkov 29 Май '06

29 Май '06

---------- Forwarded Message ---------- Subject: Re: [LVK Tech] Вопрос про поддержку ММ-языка Date: Sunday 28 May 2006 16:22 From: Konstantin Savenkov <savenkov(a)cs.msu.su> To: Maksim Chistolinov <mike(a)lvk.cs.msu.su> Привет, Макс! > Ты давно заглядывал в файл __mm_prc.h ?! Ой, давно :-) > Тебе не кажется, что ты там видишь: <skipped> > Чем это принципиально, кроме имен и деталей, отличается от того, что ты > предлагаешь ? Тем, что то, что предлагаю я, компилируется g++, а не mmt, в котором даже сообщения об ошибках написаны с орфографическими ошибками. > Какой транслятор MM->C ? Э-ээ... mmt? > Ты о чем вообще ?! Я о том, по каким причинам нужно лишнее звено в виде транслятора ММ-языка? Возможно, что сейчас он уже не используется, тогда я серьёзно отстал от жизни. Я не предлагаю всё заменить на что-то другое или, упаси боже, переписать заново. Вопрос -- почему не использовать чистый С++ (ну ладно, грязный, с макросами). Take it easy. А? Костя. -------------------------------------------------------

1 0

Re: [LVK Tech] Вопрос про поддержку ММ-языка
by Maksim Chistolinov 29 Май '06

29 Май '06

On Sun, 28 May 2006, Konstantin Savenkov wrote: ... >> Чем это принципиально, кроме имен и деталей, отличается от того, что ты >> предлагаешь ? > Тем, что то, что предлагаю я, компилируется g++, а не mmt ... И в предыдущем письме: > и набор макросов, разворачивающих MM-style описание В том то и дело, что mmt как раз и разворачивает "MM-style описание" в С++, с использованием в отображении базовых классов, которые я приводил. При этом он выполняет еще несколько полезных функций. Собственно, что делает mmt: 1. Отображение ММ на C++, при этом: - скрываются всякие "нагромождения" С++ (то, что Анатолий называл "ритуальными плясками") и детали интерфейсов библиотеки моделирования; - добавляется полезная информация, например, о номерах строк и номерах операторов в тексте; 2. Выпоняется _полный_ синтаксический и семантический анализ операторов ММ, что сделать "на макросах" достаточно затруднительно. (не вполне удачный опыт - язык описания моделей СММ КБО). 3. Диагностика формируется в терминах ММ-языка. Не соглашусь, что она плоха. Если кто-то заметил там ошибки в сообщениях - пишите bug report-ы, это легко пофиксеть. Решать задачу "фильтрации" и "русификации" диагностики g++ - это криво и очень громоздко. (неудачный опыт - см. тот же СММ) 4. Строится синтаксическре дерево, которое может быть очень полезно для решения задач анализа, трансляции, оптимизации и т.д. 5. На исходное множество возможностей С (С++) накладывается ряд ограничений, что еще никому не было вредно. Короче, по моему опыту, "хороший" транслятор ММ никому не помешает. Сейчас можно обсуждать, что он _как он есть_ не очень хорош, деревом разбора пользоваться невозможно и т.д., но это, imho, не аргумент чтобы заменить его на C++. > Какой транслятор MM->C ? mmt: MM -> C++ >> Ты о чем вообще ?! > Я о том, по каким причинам нужно лишнее звено в виде транслятора ММ-языка? По-моему это явная провокация со стороны Кости :) > Я не предлагаю всё заменить на что-то другое или, упаси боже, переписать > заново. Вопрос -- почему не использовать чистый С++ (ну ладно, грязный, с > макросами). Take it easy. Вот именно, что "грязный" и "с макросами". Как это не странно может звучать, "неповоротливость" схемы Язык + отображение на С++ оказывает хорошую услугу при развитии средства. В ЛВК уже пережили несколько проектов с "самопальными" библиотеками моделирования. Так вот, легкость и бессистемность их модификации + "личные заглюки" их авторов сделали их гораздо менее прозрачными и, в итоге, менее востребованными, чем ММ. ММ (и любой специальный язык) по определению будет более минималистичен и более консервативен, чем любая библиотека. Оказывается, что это - хорошо. Я голосую за Язык + Транслятор. Макс

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

tech Май 2006