OberonCore

Чтобы развивать, нужно хорошо понимать. Я не уверен (точнее, сильно сомневаюсь), что люди, это сейчас "развивающие", хорошо понимают, как это надо развивать. Просто потому, что вижу, что они не видят то, что очевидно нам. Значит, они не прошли весь путь минималистичного расширения от основ.

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

С.Перовский с DelphiKingdom говорил, что программист -- не профессия.
Я с ним согласен в том смысле, что программирование это некая ограниченная вещь вроде элементарной арифметики или исчисления предикатов, которую выучил и пользуй. А то, что идет дальше, это нечто совсем другое и притом разное.

Но "профессиональным программерам", особенно "компьютерным гениям" надо же подтверждать свой профессионализм и особенно гениальность.
Вот и рождаются монстры на пустом месте. Был С++ -- надоедать стал. Теперь ФЯ.

"Суета и томление духа."

Как-то Вы всё никак не поймёте, что макросы -- главнейший базовый киприч таких языков как Лисп, Немерле...
В Лиспе ФП -- побочное явление, там с помощью макросов можно реализовать любую известную человечеству парадигму программирования, хоть ФП, хоть ООП, хоть ЛП, хоть что...

Это сильно!
Да, видимо я неисправимый блаб-программист, т.к. для меня слова "макрос" и "отстой" практически синонимы

Давайте конкретно, без высокопарных слов про понимание, мэйнстрим, и т.п.
У нас в системе есть конкретный элемент - FastMathParse
Fast, потому-что, в отличие от просто MathParse, он сначала компилирует строку "по-настоящему", и далее просто передает управление этому бинарному коду. Многократно, до вызова метода doMathStr.
Далее, в 99% случаев эта строка - просто константа времени исполнения (где-то я это уже читал ), а метод doMathStr просто не используется юзером.

Какие будут КОНКРЕТНЫЕ предложения в стиле модульного программирования
Мне кажется правильным для такого случая делать вышеозначенную "компиляцию" в Compile-Time, и не иметь коды "компилятора" в целевой программе.
Кстати говоря, у нас FMP - не один с такими "потребностями", много где хочется писать коды времени компиляции... Меня давно этот вопрос мучает, по-большому счету-то...


P.S. Извините коллеги, но пока беседа напоминает мне древний анекдот

Примерно так:



Когда я буду генерировать модуль из выражения - глубоко пофигу. Вызовет ли команду CompileExpr разработчик, вызовется ли она в программе - механизм компиляции и динамической загрузки един.

Захочу, буду делать вставки в код специальными графическими объектами, в три строчки сделаю парсинг из кода этих объектов, вытаскивание из них макропараметров - и генерацию кода (хоть на их же место; хоть модулями же динамическими...) Захочу - эти графические объекты в коде будут содержать не текст, а схемы (типа Вашего HiAsma), и из них что-то будет порождаться.

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

Илья, извините, но то, что Вы сказали, выглядит примерно так: для определенного класса задач потребители (программисты) нашего "компилятора", создавая свою программу, требуют уже от своего пользователя иметь у себя на компе Flex+Bison
Хотя достаточно было бы запустить их у себя один раз.

Прекрасно понимаю, что это "сверх-логичное" развитие некой идеи. Вот только на бред смахивает.
Мне глубоко НЕ пофигу, на чьем компьютере будет произведен некий вычислительный процесс. И если некая математическая идея требует от меня чтобы было именно пофигу - пересмотрите математику, она перестала соответствовать жизни.
Хватит с меня и майнстрима, ласково уговоривающего меня, что мне все пофигу...


Мне кажется, ее (идею надежности программирования) можно было бы развивать и без доведения до абсурда. Концепция визуальных сред типа ДРАКОН или HiAsm позволяют совместить надежность программирования и "пластелиновый" язык.

Погодите, уточните, что именно Вас беспокоит. Я не понимаю пока.

Генерируйте модуль на стороне разработчика. На стороне клиента выполняйте только вторую процедуру - Call. Динамическая загрузка - неотъемлемая часть современного рантайма.

Да даже и компилятор - один и на все случаи - особенно не утянет.
В том и прелесть, что компактность всего этого хозяйства позволяет иметь его на борту любого приложения, если нужно. Персональная ОС под приложение.

Я и сказал "пофигу" в том смысле, что могу обеспечить это хоть в develop-time, хоть в use-time (так точнее, смысла в compile-time и run-time тут как раз мы не видим).

Да даже и не надо, если чисто develop-time, петрушки с загрузкой через Meta. Модуль импортируется статически, через IMPORT. А генерируется разработчиком запуском процедуры-генератора.

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

Совершенно верно. То, что я называю САПРами.

Только САПР должен на что-то опираться.

Если создание таких сред традиционными средствами - целое событие, то поверх Оберона/ББ - это может быть весёлой работой, с быстрым результатом, с возможностью сделать это просто по конкретной нужде. Наконец, это не будет обособленный мирок, а ещё один компонент. Включающийся в интегральный эффект.

Опять же, именно эти Ваши слова относятся НЕ к Автору кодов конкретного элемента, а к программисту. О надежности работы которого мы как бы заботимся.
Мое понимание этой заботы - не говорить ему таковых слов. Обратите внимание, для других элементов тоже можно провести аналогичную "беседу". А под компиляцией можно понимать просто оптимизационные действия по превращению НКА в ДКА, что может быть употребимо не только при вычислении формулы.
Это если смотреть в суть вопроса, а не зацикливаться на деталях...
Элементарно все - действия, которые могут быть вычислены в Compile-Time - там и должны быть выполнены.
Именно там - мне не пофигу где, хотя и известно, сколько пофигистов породил мэйнстрим.
И при всем при этом, Автор уже элемента (назовем его модулем) понятия не имеет о не использовании метода doMathStr. Узнать это - это провести некий вычислительный процесс в Compile-Time, коды которого Автор и написал.


Типичные слова представителя мэйнстрима.
Мы, разработчики инструмента, решили за вас, что это нечто - неотемлимая часть. Назвали свое решение самым современным. Да, это потребует неких затрат, но это же немного!!!
Ничего не перепутал ???


Не убедительно. Меня больше интересуют embeded.
И особенно нравится (и получалось), когда буржуины используют ADSP за сотну вечнозеленых, решать ту же задачу на Atmega8 за 50 рублев.
И мне нужен инструмент (нет его у меня еще) помогающий в этой благородной цели.
В общем - другая система ценностей. Не усмотрел прелестей, затраты усмотрел.
Как-то так получилось, что в отличие от массы, охмуренной мэйнстримом, мне известны истинные цены некоторых задач. В байтах, тиках, и тп...


Угу. И мне кажется, что без кодов исполнения в Compile-Time - не очень хорошо.
Не то, чтобы кажется... Пробовали.

Про легкую прогулку.
Возможно, что замена Дельфи на CP - будет и красивше.
Только хорошо - не будет. Не первый год плаваем.
Числодробительные задачи - может получиться хуже чем у бэйсиков...
Получаются страшные требования к оптимизации, и нет таких языков, которые это делают.
Например, уже мы должны решать call/inline для каждого метода. Именно решать, сделать всегда call и сказать: "и так сойдет" - уже не катит.
Другая фаза наступает. Если по Жванецкому, то: "Общим видом овладели, теперь подробности не надо пропускать"
Много их, блин, этих подробностей

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

Я же пояснил - команду CompileExpr можно вызывать при компиляции программы. Вписать её в последовательность команд компиляции проекта, например.


Почему неотъемлемая? Хотите берите - хотите нет. Дело разработчика - сделать таким лёгким, чтобы можно было взять, если нужно.


Меня и они тоже.


Да почему хоть без. См. выше.


За счёт чего это прямо так и хуже? Вон Info21 сколько лет решает задачи..
Ну, нужно оптимизировать - соптимизируется. На Фортране куски написать, откомпилировать в DLL. И т.п.

Ну вот опять....
А я пояснил, что лично я - не знаю какая схема будет у пользователя нашей среды. И рассказывать пользователю премудрости использования командной строки, супер-пупер дополнительных инструментов для целей оптимизации - ни малейшего желания. С учетом того, что теоретически, речь может идти не только о FMP, но и о некоторых других элементах, предположительно способных к оптимизации.

Блин, как сегодня работают: пишут скрит для некого язычка ориентированного на задачу, запускают Flex, Bison, собирают все вместе и снова компилируют, матюгаясь и преодолевая нестыковки.
Вы нам это предлагаете ??? И называете это надежным программированием ???
И все по причине того, что "макросы" - это от лукавого, оказывается.

Кстати говоря, типовой лексер, это больше 1000 строк кода. Работают - от силы 20 (обыкновенный табличный автомат). Чем занимаются остальные ???
Предпроцессинг - вычисления в Compile-Time


Ну я пока сомневаюсь, что какой-нибудь "вычислитель" (одна/две/три тупых формулы для конкретной инженерной задачи), сделанный на ББ как форма винды (дружественный интерфейс), можно будет передать пользователю как exe с кодовым сегментом в 1K.
Я ни в коем случае не утверждаю, что именно так надо абсолютно всегда. Утверждаю, что именно такова (с запасом) истинная цена задачи.
А еще, что достигнуть такого уровня оптимизации (начиная с компонентной разбивки) без исполнения в в Compile-Time - фигу получится.

А вы на это "исполнение" нападаете так усердно.
Да, надеюсь не надо объяснять, что перекладывать этот Compile-Time на пользователя - у меня и в мыслях не было.

Ну запихнёте вы нужные выражерния в лямбда-функцию, ну передадите её в другую, ну получите тот же результат - и что, это будет проще? В случае макроса time, например, вам нужно обернуть кусок кода в пару выражений для замера времени, именно обернуть и именно кусок кода. И макросы позволяют сделать это самым прямым путём. Так зачем тогда искусственно усложнять задачу и дописывать какие-то лямбда-выражения или, тфу тфу тфу, выносить функционал в отдельную статическую процедуру? Наиболее простой и естественный способ сделать что-то почти всегда является лучшим - принцип Калашникова, не так ли?


Ну и причём здесь макросы? Ну вот ANSI Common Lisp вроде с 94 года не менялся, в Scheme вообще хз когда последний раз что-то новое включали. В Clojure, правда, относительно часто включают новые вещи из clojure.contrib, ну так и самому языку то официально 2 года всего, и стандарт ещё никто не закреплял.
Или вы думаете, что макросы делают новый язык? Ну да, внешне так и получается, лисперы вот всё время говорят, что синтаксиса в их языке вообще нет. Но по сути то ничего нового от макросов в языке не появляется, равно как и от новых пользовательских функций. deprecated макросы тоже вещь крайне редкая - после компиляции в бинариках никаких макросов нет, ниоткуда исключать их не недо и таскать старые библиотеки для поддержки старого же кода тоже нет необходимости. Ну и где вы здесь видите проблему "новых фич"? Я ещё раз говорю, вы сначала попрактикуйтесь в использовании, а потом уже говорите что эта фича сложная, а эта вообще не нужна.


Вы не "правильную" архитектуру строите, а архитектуру, котороя позволяет обойти ограничения языка вместо того, чтобы сделать напрямую то, что вам нужно. Вообще говоря, это очень глупо затрагивать проблемы архитектуры при обсуждении базовых средств языка - это вопрос другого порядка, но я всё же позволю себе один пример. В Java, как известно, нет нормального понятия модуля, такого, как есть в том же Обероне. При этом может возникнуть множество проблем, таких как сокрытие данных, и наоборот, межклассовое взаимодействие в одном пакете. Но ещё веселее, когда на Java вам нужно получить именно модульную функциональность, например, создать некий объект, который будет существовать в системе в единственном варианте. В Обероне у вас даже не возникнет вопросов - таким объектом ялвяется модуль! А что на Java? А там тоже нет проблем, есть же паттерны! Ну конечно же, кто не знает известнейший паттерн Singleton! Вот, вроде и решили проблему с единственным экземпляром. И что, теперь справляться с задачи модульности на Java так же удобно, как и на Обероне? Да ни разу. Даже если не вспоминать о проблемах, связанных с классами-синглтонами, паттерны и рядом не лежат с нормальной, хорошо организованной модульностью (особенно при том, что паттернов разных - тьма, а понятия модульности - одно, причём простое для освоения и применения). С этим вы согласны? Так почему тогда вы считаете, что куча паттернов и "местных обезболивающих" лучше одного проверенного штатного средсва?

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

Как-раз такие авторы прекрасно понимают, что всего в мире не предусмотришь и поэтому нужно дать своим пользователям (программистам на этом языке) удобные средства для построения нужного им (пользователям) языка.
В качестве таких средств эти авторы выбрали макросы. Другие авторы выбрали что-то другое, потому они и другие авторы...

Проще не будет, но и сложнее не будет тоже. Вам нужно где-то определить макрос time, верно, так чем это отличается от определения функции?
Вызов этой функции тоже сложнее не будет -- написали имя функции, передали ей замеряемый кусок кода, этот кусок кодя сдвинули вправо для красоты (скобки некрасиво выглядят).
Было:Стало:где функция timeIt определяется в вспомогательном модуле Utils так:Ну да, приходится дописывать "fun _ ->", ну так 8 символов дописать не так уж и трудно, зато не надо париться с закрывающими скобками...

О "профессиональных программерах" говорить не будем. НО!...
Когда-то объемы бочек вычисляли вручную Пока не появились интегралы.
Вы в программировании сейчас остаетесь на уровне тех самых ручных вычислений объемов.
А в программировании зарождается "интегральное исчисление".

Математика - это тоже не профессия. Она призвана обслуживать все другие сферы деятельности человека. Выучил - и пользуйся.
Но математика превратилась с течением времени в самостоятельную сферу деятельности. Так и программирование.
Идет исследование способов алгоритмизации.
К сожалению, на форумах вместо конструктивного обсуждения это превращается в "священные войны". Причем хороши обе стороны: и "профессиональные программеры" и "профессиональные физики".

Пример Ильи Ермакова меня почти убедил, что мне ничего не потребуется, кроме ББ. Окончательно удостоверюсь при конкретной работе.

По поводу макросов еще хочу напомнить о Форте. Саморасширяющийся язык - со средой, естественно. Но бызис расширения - самый минимальный из всех. И тоже "нет синтаксиса".

Разве Вы забыли, как R6RS расколол скимеров на три лагеря -- за новый стандарт (R6RS), за старый стандарт (R5RS), и за альтернативу новому стандарту (ER5RS)?

Как я понял, Вам нужно вычислять записанные пользователем мат. выражения (viewtopic.php?p=35400#p35400):
Предложенный Ермаковым вариант решения на ББ/КП:
* преобразовать мат. выражение в текст процедуры-функции на КП (и завернуть в модуль ест-но)
* передать текст штаному компилятору (получаем кодовый файл модуля)
* штаными средствами вызвать функцию из этого модуля

(кодовые файлы можно кэшировать в некой подсистеме)

Прочитайте внимательно сообщение, которое Вы цитируете (viewtopic.php?p=35352#p35352). Вам там отвечено не про макросы.

Было время, когда я активно использовал макросы для уменьшения писанины. Своё текущее мнение про макросы изложил тут (выделено в цитате): viewtopic.php?p=35331#p35331. Вы меня не переубедите (вернутся к тому, от чего уже отказался). Вас переубеждать не собираюсь (используйте, если Вам удобно). Из дискуссии о необходимости макросов удаляюсь.