OberonCore

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

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

Также сразу добавлю, что для упрощения нет смысла удалять то, что потом будет воспроизводиться снова. Это приводит не к упрощению, а усложнению, так как это пример ложной идеи «программирования с помощью языка, а не на языке», где разработчик не отказывается от необходимых понятий, а всего лишь отказывается от его нормального описания и контроля. Это как если бы лингвисты пытались упростить язык, на котором говорят люди, удаляя правила из учебника. Наоборот, все ключевые понятия должны быть описаны формально.

BITS() бывает полезна и при описании констант.

А почему не в виде SET?

Как сделать такую проверку?
В рантайме на каждый byte := integer? Тогда это дополнительный аргумент к тому что бы байт выпилить, потому что он становится не эффективным средством и/или требует оптимизирующего компилятора (получается усложнение, а не упрощение).
Гадить ворнингами на каждое byte := integer и затыкать компилер только через SYSTEM.VAL? no way.
Сбалансированное решение - или SHORT() в качестве галочки "я понимаю опасность возможного переполнения, обрезка - так и задумано, и понимаю что тут может быть рантайм проверка и всё будет тормозить", или выпилить BYTE. Второе ближе к онтопику.
На КП мне влом разбирать где там мой код и где не мой. И грепать проблематично.
Любые алгоримы где нужна и арифметика, и битовые операции одновременно. Всеразличная криптография, хэши, рандом, "битхаки".

Битовое представление требуется когда отдельными битами представлены дискретные входы и выходы. Манипулировать надо отдельно, а представлены они словом. Встроенной BITS действительно не хватает. Обратное то преобразование через ORD есть.

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

Но тут в этом случае надо спрашивать только тех, кто пользуется этим языком на практике.

Разумеется, проверка во время исполнения не требует оптимизирующего компилятора. Не думаю, что для тех, кто спешит, так уж сложно сделать опцию выключения проверки. Просто сделать и оптимизацию для такого кода:

По-моему, как раз SHORT не нужен.

MOD хороший вариант для затыкания ворнинга, ок.
Тем не менее удаление BYTE не сильно испортит вид программ, как мне кажется.

Есть простота машинная, это в сторону 0 и 1. Вот Вы сейчас про такую простоту. А есть, когда программы писать проще. Простота Лиспов именно машинная. И если уж речь зашла о Лиспах для сверхмалых процессоров, то они там никогда не имели и не будут иметь особого применения, поскольку Лисп-машина на них чудовищно неэффективна. Даже полученный с Оберона через трансляцию в Си машинный код будет намного лучше, ибо он будет нативным. Я как-то поучаствовал в испанском конкурсе, где написал на моём диалекте Оберона (вернее, портировал) игру Bolder Dash. Это работает на компьютере ZX Spectrum с 16 Кб ОЗУ (из которых 6 Кб это видеопамять). Объём игры (+ уровни, + графика, + звуки) около 9 Кб. Это динамическая игра, и повторить её на ретро-процессоре в таких объёмах с такой производительностью на любом Лиспе не представляется возможным.

На ретро-процессорах есть микро-Лиспы, но они урезанные по самое небалуйся и не годятся ни для чего практического.

Они и так, в основном, запрещены. Про это подумал Вирт и ввёл FLT().

А зачем вообще нужна BITS() и перевод целых в битовое представление? Но раз нужно, значит нужно. И в константах тоже. Если не верите — спросите у Бориса

Например, в модуле N есть константа, значение которой в битовом представлении нужно в модуле M, тоже в виде константы.

P.S. Упрощение О7 не одобряю категорически. Сам бы я посягнул только на PACK/UNPK, да и то, их выпиливание погоды не сделает. Эти упрощения вообще экстремизмом попахивают. Вы практики, господа, или просто умозрительно идейничаете?

Как-то Антон Кротов написал несколько крупных программ на О7 для KolibriOS, включая читалку книг в формате fb2. После полученного опыта у него есть заметки как раз не об упрощении, а об усложнении Оберона-07. Вот к этому я бы точно прислушался. Слово практика.

Сейчас поискал в инете этот его пост и не нашёл. Где-то был на форуме OberSpace. Будем считать утерянным, жаль.

Полностью согласен.

this?

C CHAR вместо него, я же правильно понял?

Да, спасибо.

ЯП Julia позволяет использовать "макросы в стиле Lisp", которые работают на уровне abstract syntax trees (AST). ( Лучше ориентироваться на этот механизм метапрограммирования, чем на "чистый Lisp")
Да, именно так в Modula-3 и Ada.

P.S.
Кстати, в сообществе KolibriOS про этот компилятор помнят:
https://t.me/kolibri_os/116371

Ну не знаю, насколько уместно в этой теме продолжать говорить про лисп, но тут несколько целей оптимизации. Я не говорил, что интерпретаторы лиспа оптимальны для любых задач на микромашинах. Я говорил о том, что если у Оберона-07 и есть естественная ниша применения, то это микромашины, при условии, когда вся инфраструктура, включая компилятор, находится на борту. Это не относится к Вашему примеру с трансляцией через Си, ведь наверняка же компилятор Си не 9кб занимает. Кроме того, Ваша игра - не единственное возможное применение компьютера.

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



В выражении a + b происходит ли неявное приведение типов, если один из них INTEGER, а другой - BYTE? Была бы онлайн-песочница для O7, я бы проверил, но не нашёл.

Дело в абстракциях. Поскольку ретро-компьютеры это не специально сконструированные Лисп-машины, они более традиционно устроены, то и работать с динамическими списками на них неэффективно.

BYTE схавает без приведения. LONG и SHORT нету. Но тип BYTE особо не позиционируется для вычислений, он, скорее, для экономии памяти в записях/массивах.

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


Т.е. есть в этом случае неявное приведение, и я бы его выкинул. А константа 1 имеет какой тип? Нет такого, что выбирается минимально достаточный тип? Если да, то это тоже как раз добавляет проблемы, потому что не совсем ясно, чему тогда равно 127 + 127 + 127 .

oberon.html#6.1

Разница в типах переменных BYTE и INTEGER не в типе значения, а в ёмкости хранения. Такая особенность целых чисел. Нечто похожее, но со своей спецификой есть в открытых массивах — тип вроде бы один, а ёмкость разная. Любителям «чистых» концепций такие вещи бывают не понраву, но это проявление практичного взгляда на программирование, естественно, как это видит некоторый круг разработчиков.

Мне тоже не нравится концепция, в которой, единица может быть не равна единице, потому что они якобы принадлежат разным типам значений, и число должно быть преобразовано/конвертировано в типе. Ещё хуже, что из-за необходимости такой конверсии, в том виде, в котором его хотят видеть сторонники молчаливого отбрасывания старших разрядов, разные значения могут оказаться равными:


К слову, в КП SHORT согласно определению даёт identity, что означает вовсе не молчаливое отбрасывание старших разрядов, поскольку при наличии там единиц, никакого тождества нет. Насколько помню со слов Антона, BB умеет проверять переполнение диапазона с аварийным остановом, но по умолчанию это было выключено ради оптимизаций, а люди-то спешат. В результате этого было понатыкано много таких опасных отсеканий, а спецификацию, крохотную по современным меркам, люди не читают.

Принцип, самая, так сказать, базовая абстракция Лиспа это списки. Знаете же как расшифровывается аббревиатура LISP? Преобразовать даже (+ a b) во что-то, что нормально ляжет на традиционные архитектуры — это компиляция. Я не спец, Вы сами скажите сколько именно решений из Лисп-мира порождают прямой машинный код и могут превратить это сложение в одну машинную команду. Ну или хотя бы в две-три. А не в целую простыню байт-кода, который работает только на жирной виртуальной машине. Впрочем, о чём мы спорим-то. Мы с Вами ничего друг другу не докажем, мы из разных миров. Ваш каждый второй, если не первый пост неизбежно сбивается на Лисп. А в моём мире Лисп это просто ещё один подход, и не самый интересный. И не будь у нас мощных компьютеров, Лисп был бы вообще неприменим. А он и так почти неприменим для ресурсоёмких задач. Знаю, Вы тут захотите поспорить, но просто замечание: с Вас будет больше пользы на тематических форумах по Лиспам.

В О7 это будет INTEGER. В КП — BYTE, но в КП все целочисленные вычисления производятся в 32 битах, а если хотя бы один из аргументов 64 бита, то в 64. В О2 тип для вычислений — это двухбайтовый INTEGER (сложилось исторически, т.к. на старых процах такие вычисления эффективнее).

Очень даже ясно. Если при вычислении константы понадобится увеличить разрядность типа — компилятор это и сделает.

AOT: у меня вопрос к упрощаторам. ЗАЧЕМ вообще упрощать О7? Какой в этом высокий и сакральный смысл? Смысл был бы, если бы язык при этом улучшился. Лавры Вирта покоя не дают? Я вот, например, понимаю, что последняя ревизия Oberon-07/16 это просто снапшот, и если бы мэтр Никлаус им дальше занимался, то более новая ревизия точно бы выглядела несколько иначе. Может BYTE выпилил бы. Может впилил бы два целых типа для 32- и 64-битных вычислений. Мы не знаем. Просто специфика системы для FPGA наложила отпечаток на то, что мы сейчас считаем финальным зафиксированным Обероном. И как бы кто его ни пытался менять — он всё равно останется последним Виртовским Обероном. Так-то.

Реализуя в Ofront+ поддержку O7, я даже не пытался сделать его более полноценным, только постарался придерживаться последнего описания языка. Но это потому, что в Ofront'е+ O7 работает в связке с другими диалектами. Скажем, можно в модуле на O7 импортировать 64-битный тип LONGINT из модуля на КП. А иначе не получится смешивать в одном проекте разные диалекты. Но у Кротова ситуация другая. Он пытался реализовать такой O7, который был бы полноценным и удобным для разработки. Так что у практиков типа Кротова больше оснований расширять O7. Но не упрощать, блин...

Так если не хотите, чтобы я с Вами спорил, то и не надо делать сомнительных утверждений. (+ a b) в лиспе не совсем однозначно из-за динамической типизации. Кроме того, в общелиспе по умолчанию используются настоящие числа, а не эрзац-числа по модулю 2^N. А настоящие числа нельзя сложить одной машинной командой. Хотя если из анализа объявлений типов компилятору будет известно, что их сумма не вызовет переполнения fixnum-а, то может быть в компиляторах (компиляторов CL в машинный код я знаю 4 штуки, а уж сколько компиляторов Схемы - наверное, десятки) это и превратится в одну машинную команду - я не проверял.

Да, для эффективного выполнения лиспа нужна компиляция. Ну и что? Для Оберона она тоже нужна. Из того, что лисп к тому же очень легко интерпретировать, вы пытаетесь вывести, что он хуже? Не получится.

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

Касаемо жирных виртуальных машин, на фоне Java и Python Лисп достаточно хорошо выглядит по производительности и по расходу памяти, если правильно писать. Т.е. с Java он будет наравне, после разогрева явовского JIT, а до этого момента - намного быстрее. А Python будет безнадёжно позади на средней задаче. Поэтому говорить, что лисп медленный - ну как-то не совсем честно в наше время, если вы туда же не включаете и Питон, к примеру.

> Впрочем, о чём мы спорим-то.

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

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

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

> В О7 это будет INTEGER.

Это хорошо.

> Просто специфика системы для FPGA наложила отпечаток на то, что мы сейчас считаем финальным зафиксированным Обероном.

О, теперь я понял, откуда это. Однако, в школе Вирта было принято делать специализированные языки под конкретную задачу, как я понял. И это хороший подход, спасибо покойному Фёдору Васильевичу, что он мне это разъяснил - я не сразу понял. Значит, действительно, правильный подход состоит не в том, чтобы подпиливать отдельные заусенцы в сделанном Виртом, а в том, чтобы делать под новые задачи - новые языки.