[pure С] Макросы как инструмент построения eDSL

[Илья Ермаков]

Прошу прощения, это действительно немножечко другое, нежели сопрограммы, хотя реализация схожа, можно переделать.
По вопросу сопрограмм и оптимизации компилятором концевых вызовов (как варианте реализации) я писал на ОберонКоре, ветка с анализом проблемы GOTO. Позже дам ссылку, когда у местного провайдера кончатся проблемы.

[Peter Almazov]

Никакой поддержки ОС не требуется, легковесный библиотечный параллелизм, поскольку стек один, можно иметь очень много параллельных задач.

Кстати, в моём биосном примере стек тоже один.

[igor]

На выходных мы с сыном решили переписать пример Vlad'а на КП/Блэкбокс, в учебно-тренировочных целях, так сказать. К тому же, сын выступил в качестве консультанта по языку С++, поскольку сам я с этим языком не дружу. 

Полной аналогии с исходным примером конечно нет, но такой цели и не ставилось. Комментировать особо не буду, и так всё видно.

[Илья Ермаков]

Обещал ссылку в тему сопрограмм.

Вот такая веточка у нас есть:
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3237
И в ней я высказывал свои мысли про концевой вызов процедур:
http://forum.oberoncore.ru/viewtopic.php?p=59493#p59493

[valexey]

Мысли это хорошо, а реализацию то покажешь? :-)

[vlad]

Полной аналогии с исходным примером конечно нет, но такой цели и не ставилось. Комментировать особо не буду, и так всё видно.

Да, он достаточно аналогичен. Без глобальных переменных

[Илья Ермаков]

Мысли это хорошо, а реализацию то покажешь? :-)

Про концевой вызов - нету реализации; т.к. я не занимаюсь пока что вещами, требующими модификации компилятора.

А про лёгкий параллелизм - не покажу , а вот если кому реально надо, для реальной задачи, готов в личке рассказать и показать (если человек объяснит, опять же, зачем надо).
А для праздного любопытства я не стану выделять эту реализацию из общего каркаса, время публикации которого ещё не пришло.

[valexey]

Тогда к чему было это упоминать? Ладно, Реализацию не можешь показать, тогда покажи хотя бы пример использования например применительно к обсуждаемой задаче. Тут ни выделять из каркаса ничего не надо, ни публиковать. Просто пример использования. Код.

[Илья Ермаков]

IMPORT Tasks;

PROCEDURE Task (IN par: ANYREC);
BEGIN
  WITH par: ... DO
    ...step1...;
    Tasks.Pass;
    ...step2...;
    Tasks.Pass;
    ...step3...
  END
END Task;

PROCEDURE X;
  VAR par: ...;
BEGIN
  par.. := ...
  Tasks.Begin(Task, par)
END X;

[igor]

Да, он достаточно аналогичен. Без глобальных переменных

Должен сказать, что цели "избавиться от глобальных переменных" нами не ставилось. Ваш подход к решению привёл к тому, что глобальные переменные исчезли как бы нечаянно. 

Хочу отметить, что не смотря на то что КП несравненно меньше и проще языка С++, он тем не менее оказался достаточно выразительным и пригодным для такого применения.

Из недостатков (или особенностей, которые вызвали неудобство) могу отметить следующие:

• Отсутствие полноценных конструкторов заставляет эмулировать их при помощи довольно корявого вызова обычного метода сразу после NEW.
• Отсутствие шаблонов классов вызвает затруднение при описании вектора, который может состоять из однотипных элементов абсолютно любого типа (в примере описан вектор, который может состоять только из процедур).

Про достоинства сильно "трещать" не буду, ибо пользы от этого мало. 

[vlad]

Да, он достаточно аналогичен. Без глобальных переменных

Должен сказать, что цели "избавиться от глобальных переменных" нами не ставилось.

Просто глобальные переменные - это лакмусовая бумажка Показывающая будущие проблемы в сопровождении. Поэтому я привык их избегать любой ценой.

Хочу отметить, что не смотря на то что КП несравненно меньше и проще языка С++, он тем не менее оказался достаточно выразительным и пригодным для такого применения.

Выразительностью я бы не стал особо восхищаться... А то, что КП пригоден - никто не сомневался.

Из недостатков или особенностей, которые вызвали неудобство) могу отметить следующие:

• Отсутствие полноценных конструкторов заставляет эмулировать их при помощи довольно корявого вызова обычного метода сразу после NEW.

Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.

• Отсутствие шаблонов классов вызвает затруднение при описании вектора, который может состоять из однотипных элементов абсолютно любого типа (в примере описан вектор, который может состоять только из процедур).

Да, подобные велосипеды не добавляют выразительности И заставляют идти по пути глобальных переменных

[DIzer]

Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.

Да фабрики хороши - одна проблема - не гарантируют создания экземпляра  ИСКЛЮЧИТЕЛЬНО по ЗАДАННЫМ правилам или я ошибаюсь?.

[igor]

Всё-таки нужно различать прикладной код и библиотечный.

Если я пишу какую-либо прикладную программу, в которой нужно однократно решить изначальную задачку (см. самое первое сообщение Geniepro в теме), то лучшим решением будет то, которое я предложил в начале.

Если данная задачка встречается довольно часто, то нужно библиотечное решение, и тогда лучшим решением будет то, которое предложил Vlad.

Решение, основанное на использовании макросов, мне откровенно не нравится (концептуально, а не по исполнению!). Что-то типа библиотеки для ленивых. Но говорю это с большой долей субъективизма.

[valexey]

Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.

Да фабрики хороши - одна проблема - не гарантируют создания экземпляра  ИСКЛЮЧИТЕЛЬНО по ЗАДАННЫМ правилам или я ошибаюсь?.

Почему же? Они именно для этого и есть, то есть для создания объектов по жестким заданным правилам.

[valexey]

Решение, основанное на использовании макросов, мне откровенно не нравится (концептуально, а не по исполнению!). Что-то типа библиотеки для ленивых. Но говорю это с большой долей субъективизма.

Не нравится сама идея создания и использования eDSL, или же реализация её посредством макросов?