OberonCore

А где используются ненастоящие эрзац-числа по модулю 2^N? Везде, кроме Лиспов?

Вот про эрзац-числа это очень сомнительное утверждение. Везде числа как числа, а у нас нет.

Поясните.

Вот. Ваша слабость в незнании низкого уровня. И не надо про специализированные аппаратные Лисп-машины. У нас под рукой их просто нет и не будет.

Переполнение в машкоде легко ловится, обычно после операции на него указывает установленный флаг C (carry).

Оберон тоже очень легко интерпретировать, только смысла нет.

Вы не уловили мой посыл. В Лиспе компиляция "ненастоящая". Не в родной машкод. Хотя я признаю наличие инструментов, которые, возможно, делают какие-то попытки в этом направлении, но в силу природы языка это слабые и плохие потуги. Вот поэтому и хуже. Для меня, не для Вас. Я свои выводы сделал, и Ваши посты меня в обратном никак не убеждают. Впрочем, и не должны. Не убеждают, что Лисп лучше и выгоднее для разработки, чем язык [ X ], что он повышает производительность и бла-бла. Ну нравится Вам, ради бога. Я сюда захожу про Оберон прочитать, а не про мифическую простоту Лиспа. 0 и 1 - куда уж проще.

А Вы не с Python сравнивайте, а с Rust или Zig. Какой смысл в ещё одной тормозной технологии?

((((((((((действительно?))))))))))

Я Вам уже писал, что простота Лиспа не в том, что на нём просто писать. Лисп требует серьёзной подстройки мышления (как Форт), но если в случае с Rust это ещё имеет какой-то смысл, то в случае Лиспа точно нет. И вот эти попытки самоутвердиться, что Вы-де из иной касты Познавших Тайную мудрость - они какие-то даже наивные. Вы мне этим напоминаете старого доброго Geniepro, только у него вместо Лиспа был Haskel. Тоже избранный, тоже вы все тут нифига не понимаете. Но про монады было интереснее.

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

Вот у Оберона простота человеческая. На нём удобно проектировать программы. За что и ценим. Если мне понадобится список, то я его легко сварганю. Но как Форт навязывает программисту свой стек и обратную польскую запись, так Лисп навязывает ему списки, скобки и префиксную. В любом случае, это уже требует "распаковки" кода в голове. А код на Обероне мы просто читаем, как есть. Неужто Вы не понимаете этой разницы? Только не говорите, что Вы с Марса, и там все на Лиспе думают.

P. S. А за "экспортируем всё" и "модули - они вообще не являются необходимыми" вообще убыв бы (c)

Скажите, в чём Ваш интерес ходить к оберонщикам и навязывать им свой Лисп?

Неверно. Я лишь пытаюсь сказать, что я захожу сюда за Обероном. А Лисп мне неинтересен.

Вы говорили про простоту Лиспа для мелких машин. В современный ARM Лисп вполне себе влезет, но толку с него там будет мало. Про задачи реального времени даже не будем начинать.

Они там существовали, скорее. Когда-то.

Хотя, Вы видите, мы и термин "мелкие машины" с Вами понимаем по-разному. Я не о ZeroPi, я о ретро из 80х. ZeroPi Ваш Лисп вывезет, было бы счастье.

Я понял, что Вы пытаетесь меня прогнать, так не пишите в лисп в теме, которая не про лисп. Я сам про это начал, но это было на основании моего понимания формулировки вопроса темы. Формулировку уточнили и больше здесь нечего обсуджать лисп. Вы пишете офтопик и нарушаете правила форума и нормы приличия. Тем более, не пишите неправду про лисп. Понимаете, если форум про оберон, это не значит, что про лисп на этом форуме надо писать неправду, преуменьшая его возможности и дезинформируя других посетителей. Я отвечу в другой теме, если найдётся подходящее место.

ответил здесь

viewtopic.php?f=26&t=6996&p=119210#p119210

Кому лень туда сходить, здесь я напишу, что утверждение, что "лисп компилирует в ненастоящий машинный код" - это ложь, и по ссылке это показано.

Я сделал какие-то макросы для Яра-22, учитывающие синтаксис, т.е. отличающие выражение, оператор и составной оператор, однако они получились сильно неэлегантными. Также и в Scala были большие проблемы с внедрением макросов. По сути дела элегантных вариантов я вижу только два: как в Си на уровне текста, где производится упрощённый анализ, как в препроцессоре (шаблоны с <> являются в принципе в каком-то смысле разновидностью оных) и как в лиспе. В полновесной AST слишком много полей и слишком много разных видов узлов. Например, отдельный узел для составного оператора, для простого оператора (как присваивание) и для выражения. С другой стороны, в лиспе макросы мешают отладке и нужно много с этим возиться. Можно ещё посмотреть, как сделано в Расте - вроде язык модный.

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

Полностью согласен с Олегом - здесь все-таки топик про О7. И спасибо за мнение Антона Кротова. Что касается Лиспа, мой опыт его использования в системах компьютерной алгебры типа Reduce и Maxima показал, что они допускают ошибки при численном интегрировании. Это касается как CL, так и SBCL. И это при утверждении, что они компилируются в машинный код. А другие системы компьютерной математики, использующие императивные языки, таких ошибок не допускают.

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



Хотя это в стиле Олега, т.к. намешаны понятия. Компиляция в машинной код ортогональна императивности, CL и SBCL не являются однородными понятиями. CL - это стандарт языка и в ней ничего не говорится о том, куда компилировать, а SBCL - его реализация, которая компилирует в машкод (но может и интерпретировать). Возможно, Вы опечатались и имели в виду CCL? Дальше, Common Lisp, вообще говоря, является императивным языком (здесь у Вас с Олегом общее незнание вопроса). Дальше, системы компьютерной алгебры могут содержать ошибки, не имеющие корней в языке. Т.е. Ваша попытка очернить лисп в целом полностью компенсируется некомпетеностью того, как именно Вы пытаетесь это делать. Хотя с Олегом при такой постановке дела Вы точно найдёте общий язык

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

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

Да, и кстати, Reduce написана на своём диалекте лиспа, я не знаю, компилируется ли он в машинный код или в байт-код - я с ним никогда не работал. Лисп - это вообще-то семейство языков, некоторые реализации компилируют в машкод, некоторые - нет. Чтобы опровергнуть утверждение "лисп не компилирует в машинный код", достаточно существования хотя бы одного лиспа, который компилирует, и он существует. Однако я не утверждал, что в Reduce используется компиляция в машкод, а Вы так составили фразу, что получается, будто я это утверждал. Такая вот софистика. Зачем она?

Возвращаясь к макросам, если взглянуть на заголовочники ядра линукса, то там макрос на макросе и макросом погоняет. Конечно, можно много изображать благородство и говорить, что макросы не нужны, но тогда встаёт вопрос, а как же писать переносимые программы? В A2 этот вопрос решён, но препроцессор там всё же есть, состоящий из двух отдельных инструментов, которые в сумме дают часть функционала cpp, а также решается на уровне конфигурации. Часть решения зашита и в сам язык в виде переменного размера некоторых типов. Помогает здесь и возможность переименовывать модули при импорте. В итоге получается целостное и работающее решение, которое даже можно похвалить. Видимо, в Oberon07 такого нет, при том, что язык сам по себе не абстрактен от железа, ведь SET же имеет переменный размер. Поскольку в A2 возможность писать переносимые программы возникает только в комплексе из языка, его реализации и системы сборки, которая не является частью языка. Здесь можно говорить о том, что какого-то необходимого функционала в O7 недостаёт. Конечно, всегда есть такой вариант, как клонировать весь код, который прямо или косвенно зависит от особенностей платформы, но ведь в условии задачи было "не выкидывать то, что потом придётся делать".

(кстати в ЯОС я выкинул один из костылей, используемых в A2 для конфигурирования, и заменил его другим, гораздо более изящным костылём, находящимся вне языка, хотя сложно сказать, относится ли костыль в компиляторе именно к самому языку или к его реализации - надо смотреть описание языка A2). Теперь он живёт в скрипте сборки. Хотя вот прямо сейчас я это написал и понял, что я сделал хуже - декларативное превратил в процедурное. Надо над этим подумать на досуге. С третьей стороны реальные скрипты сборки образов A2 в любом случае не декларативны, а являются достаточно длинными скриптами, например, вот один из них в моём переложении и место, где выкинут костыль: https://tvoygit.ru/budden/ja-o-s/src/br ... 0.Tool#L74) так что я не сильно добавил к общей сумме греховности).

Ндя, божественно. Описание языка AO называется OberonLanguageReport.pdf, так же, как и описание Oberon07. Сразу видна высокая инженерная культура и экономия на названиях. Минимализм во всём. Я это заметил по той причине, что мне браузер предложил сохранить файл OberonLanguageReport (1).pdf. И естественно, про этот костыль, который называется replacements, в описании языка ничего нет. Про #if есть. Ох, тут уже грустно становится.

В моём интернете документ на странице Вирта называется Oberon07.Report.pdf, но я бы не удивился, если бы файлы совпали по названию, так как это ответвления одного документа. Для Oberon-2 и Active Oberon не создавалось отдельного описания с 0, а производились редактирования. Сравните:
Интересное «случайное» совпадение, как и структуры документов в целом. Подходит для викторины «отличите языки по diff»

Кстати, полноценного описания Активного Оберона, увы, нет, и он давно превратился в язык, определяемый реализацией.

Я стараюсь сделать описание Яра-22, точнее, раньше старался. Который очень мало отличается от Активного Оберона. Всё, что удавалось узнать у Сергея, я туда вписывал, иногда прямо в виде чата. Картина, конечно, не очень, местами набор костылей, особенно плохо обстоят дела с обработкой исключений (которая FINALLY или что-то в этом роде, уже не помню слово). Но работать в принципе возможно.

Можно убрать возможность перечислять переменные через запятую.

Это то, что вы не хотите использовать?

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

Можно попробовать выкинуть WITH и заменить его одним типом и несколькими процедурами:

* тип метаданныеТипаВремениВыполнения
* дайМетаданныеВремениВыполненияДляТипа(выражениеТипИлиЗначение)
* дайМетаданныеВремениВыполненияДляЗначения(Значение)
* являетсяЛиРасширениемТипа(базовый, расширение: метаданныеТипаВремениВыполнения)

Можно также вынести на пользователя такое:
* совместимыЛиПоПрисваиванию(типПриёмника, типИсточника: метаданныеТипаВремениВыполнения)

Тогда можно выкинуть конструкцию WITH. Мало того, что из языка переносим семантику
в библиотеку, увеличивается гибкость без потери безопасности (если я не ошибся).

Тут, правда, возникает та проблема, что в A2/ЯОС, да и наверняка в других Оберонах
нет достаточно хороших метаданных типа времени выполнения для всех типов, например, для
какого-нибудь ARRAY OF ARRAY OF INT, но вроде как WITH с этим и не работает. Поэтому можно ограничиться
записями и указателями на них.

Выражение охраны типа значение(Тип) надо переделать. Это плохая конструкция,
потому что её можно перепутать с вызовом процедуры. Она должна записываться как-то так:
* Охр(значение, тип)

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

Можно попробовать выкинуть WITH и заменить его одним типом и несколькими процедурами:

* тип метаданныеТипаВремениВыполнения
* дайМетаданныеВремениВыполненияДляТипа(выражениеТипИлиЗначение)
* дайМетаданныеВремениВыполненияДляЗначения(Значение)
* являетсяЛиРасширениемТипа(базовый, расширение: метаданныеТипаВремениВыполнения)

Можно также вынести на пользователя такое:
* совместимыЛиПоПрисваиванию(типПриёмника, типИсточника: метаданныеТипаВремениВыполнения)

Тогда можно выкинуть конструкцию WITH. Мало того, что из языка переносим семантику
в библиотеку, увеличивается гибкость без потери безопасности (если я не ошибся).

Тут, правда, возникает та проблема, что в A2/ЯОС, да и наверняка в других Оберонах
нет достаточно хороших метаданных типа времени выполнения для всех типов, например, для
какого-нибудь ARRAY OF ARRAY OF INT, но вроде как WITH с этим и не работает. Поэтому можно ограничиться
записями и указателями на них.

Выражение охраны типа значение(Тип) надо переделать. Это плохая конструкция,
потому что её можно перепутать с вызовом процедуры. Она должна записываться как-то так:
* Охр(значение, тип)

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

А, ну я на самом деле не совсем прав, если выкинуть конструкцию WITH, то надо будет
приводить тип внутри каждой ветки. Ну что же, придётся потерпеть. Хотя сейчас Константин скажет,
что это не лишний функционал и даже будет прав, пожалуй. Или эта конструкция называется не WITH,
а CASE? Никак не упомню. Короче, я имел в виду конструкцию,
где тип некоего значения можно последовательно сравнить с несколькими всё более и более узкими типами
и дальше в каждой ветке выполнить какие-то действия над местом,
при том, что его тип сужен В ЯОС это называется просейТип.

И кстати, имеется проблема в этой конструкции, вроде она есть в A2/ЯОС, и, как ни странно, такая же беда имеется в SBCL. Ничто не защищает от того, чтобы внутри ветки присвоить изучаемому месту
значение более широкого типа и тем самым всё сломать. Притом запрет делать это внутри самой конструкции не поможет - это может произойти неявно за сценой другим кодом. Поэтому на самом деле, внутри этой конструкции нужно проверять тип значения при каждом использовании, либо использовать не место, а значение. В принципе можно научить компилятор делать что-то из перечисленного неявно. Но если мы выкидываем данную конструкцию, то и эту проблему мы тоже выкидываем вместе с конструкцией.