OberonCore

собственно, сабж. почему LSH осталось сидеть в SYSTEM, хотя BITS разрешили штатно? пока BITS не было, можно было мотивировать тем, что LSH заточено на битовое представление чисел, так что оно логично спрятано в системно-зависимой части. но когда появился BITS, то LSH — это же просто `ORD(BITS(ASH(c, -1)) * {0..30})`, только через афедрон и с лишними операциями. если уж возможность «видеть» целое как набор битов сделали штатно — нет больше никакого смысла прятать LSH.

как вы считаете, это просто омики недосмотрели (ну, не надо было им, вот и забыли), или есть какая-то ещё причина? потому что я сильно склоняюсь к тому, что это просто недосмотр, и LSH надо из SYSTEM вытащить. как и ROT, кстати, которое с BITS тоже спокойно реализуется без SYSTEM, но ещё более неудобно.

то есть, добавление BITS мгновенно прибивает гвоздями представление целых как 2-complement, и больше нет никакой причины прятать «беззнаковые» операции в SYSTEM.

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

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

в DevCPT, после

тупо добавляем:

that's it. и DevAnalyzer тоже их магически увидит.

а что будет, например, после LSH(x, 36)

точно то же самое, что и после `ASH(x, 36)` — UB будет. а вот для `ASH(x, y)` таки делается проверка диапазона, и будет трап. почему не проверяются константные сдвиги — я не знаю.

(ASH, LSH и ROT обрабатываются одним и тем же кодом в кодогене, так что между ними можно различий в данном случае не делать.)

это и есть ответ на вопрос: почему эти операции были в простран,тве имён system.

мягко намекаю, что ASH не было в пространстве имён SYSTEM. равно как и BITS. об чём и спич в начальном посте.

ASH тоже должна была быть в SYSTEM, как это было даже в Активном Обероне. Но совместимость с унаследованным кодом оригинального Обероне (1990), требовала, чтобы ASH была доступна в глобальном пространстве, остальные сдвиги там были опциональны и находились в SYSTEM.

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

итак. мы только что устранили все UB (добавив проверки констант прямо в компиляторе, как он делает, например, с константными индексами массивов). проверки во время исполнения тоже есть. какая ещё осталась причина упрятывать сдвиги в SYSTEM?

я, впрочем, знаю один язык, который усердно делает вид, что очень далёк от реальной архитектуры машин: «си» называется. авторы стандарта си до сих пор пребывают в уверенности, что на свете огромное количество архитектур, где целые числа представлены не в двоичной системе, а если в двоичной, то не как 2-complement. всё, чего они этим добились — люди просто пишут программы с UB, и затыкают компилятору квакало соответствующими ключами.

если мы в Обероне/CP начнём утверждать, что и размеры INTEGER неизвестны, и вообще представление этих самых интегеров непонятно какое, и ходите в SYSTEM за обычными арифметическими операциями, которые буквально от сотворения процессоров натурально на них есть, и широко используются в различных алгоритмах — мы добьёмся ровно того же, чего добились авторы стандарта си. то бишь, все будут ходить в SYSTEM, использовать эти операции, продолжать затачивать код на 2-complement, и считать авторов языка идиотами. очень не без причины, смею сказать.

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

с той же переносимостью у софта на классическом обероне всё равно всё очень-очень плохо, потому что там нет типов SYSTEM.ADDRESS и SYSTEM.SIZET, и все кастуют адреса в тридцатидвухбитные инты и наоборот. никакой SYSTEM от этого не спасает. потому что — внимание! — идея SYSTEM была вовсе не в том, чтобы изолировать все архитектурно-зависимые операции, а в том, чтобы изолировать опасные операции. которые могут нарушить гарантии работоспособности системы. ни ASH, ни LSH, ни ROT, ни BITS эти гарантии нарушить не могут — а поэтому им не место в SYSTEM. всё, что делает помещение их в SYSTEM — заставляет импортировать SYSTEM там, где он не нужен, создавая ложное впечатление опасности безопасного модуля.

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

как-то вот так.

p.s.: указание в спеках языка требований к размерам и точному битовому представлению интов, кстати, повышает переносимость кода, а не понижает.

к сожалению, омики сделали ещё одну ошибку в спеках, не специфицировав разрядность промежуточных вычислений для чисел с плавающей точкой. в итоге я уверен, что есть код, который ожидает FPU и промежуточное в 80 бит, что весьма затрудняет перенос на архитектуры, где такого FPU нет, а промежуточные, например, те же IEEE doubles. стоило в самом начале запретить FPU так делать, и в спеках чётко прописать, что промежуточные для REAL всегда REAL, что REAL всегда IEEE, и что промежуточные для SHORTREAL — тоже REAL, а обратно с округлением (которое тоже чётко специфицировать).