я вообще-то не вижу ни одной разумной причины прятать сдвиги в 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), так пусть уж используют не неведому зверушку, а чётко описаные фичи.
как-то вот так.
|