OberonCore

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

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

Поясните.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

то, что ofront этого не умеет, потому что транслирует в сишечку, а сишечка тоже этого не умеет — это интимные проблемы кривого ofront.

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

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

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

Прошу уточнить, что же я понимаю под мелкими машинами и на каком основании Вы это решили.

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

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

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

Минимальный лисп, который я нашёл за примерно 15 минут запускается на вот такой машине.

> The Arduino Uno and Arduino Nano are based on the Atmel ATmega328 processor, which is the smallest ATmega processor that uLisp supports. It runs at 16 MHz and provides 32 Kbytes of program memory, 2 Kbytes of RAM, and 2 Kbytes of EEPROM.

Кроме того, Вы прекрасно справляетесь с задачей писать про Лисп на этом форуме