OberonCore

Ты как-то по диагонали читаешь то, что тебе пишут.
Zero-initialization изменяет состояние с undefined, но не делает программу рабочей. Для того, чтобы программа заработала нужно либо применить default(в рамках предметной области) или value-initialization, либо явно присвоить значение. Ни default ни value инициализации в КП нет. Можно сказать что раз нет, то и не нужна., что достигли, то и являлось целью, и продвигать zero initialization как средство от блох. Но оно вообще не решает никаких проблем, а лишь дает ложную иллюзию, что все под контролем и идет по плану.
Тем не менее, для указателей zero initialization предоставляет простое аппаратное решение ловли блох (рази енование пустого указателя) в виде исключитения, которое обрабатывается рантаймом. Другие решения э ой проблемы заведомо более сложны в реализации. Только и всего.

я не знаю, где тут можно было найти моё утверждение о том, что это делает программу рабочей (в плане корректности, ведь речь именно об этом, насколько я понимаю). можно цитату из меня с этим утверждением? возможно, при чтении по диагонали показалось, что «нет UB и хэйзенбагов» означает «делает программу рабочей (и корректной)», но это иллюзия, сии утверждения не синонимы. я даже открытым текстом писал несколько раз, что отсутствие UB помогает в отладке. каковой процесс для рабочей и корректной программы не нужен по определению.

также при чтении по диагонали можно упустить тот факт, что указатели в BBCB чистятся для того, чтобы сборщик мусора не сошёл с ума, а не чтобы защититься от чтения «пустого указателя». то есть, как раз для устранения UB (а трап при разыменовании NIL — просто приятный побочный эффект). о чём я и пишу уже которую страницу: UB надо устранять, и нет никакого смысла делать это выборочно (кроме быстродействия, и эта причина на сегодняшний день исчезла). а про то, что «defined = correct» я не писал нигде.

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

почему меня тут уже какую страницу пытаются убедить в том, что иметь UB лучше, чем не иметь — я понять решительно не могу.

кстати, вся эта эпопея тут вообще началась с того, что я написал про пир духа в оберон-рассылке, где выяснили, что CASE в O7 имеет UB. так вот: я, собственно, о том, что в Ultra Pascal это надо починить. технически иметь более толстого сторожа в WITH перед более тонким совершенно бессмысленно, и я намерен научить компилятор выражаться неприличными словами, если он такое заметит. а также (не забыть бы) написать в спеках UP, что сторожа в WITH проверяются строго в порядке их появления в исходнике, и никак иначе. а, и то же самое надо бы написать для дэйкстра-like WHILE. а то сначала отказываются строем ходить, а потом начинают выяснять, чья анархия красивей.

p.s.: кстати, fun fact. максимальная глубина наследования в CP2 установлена в 16 просто потому, что это красиво помещается в четыре бита. хотя технически я не припомню у себя софта, где не хватало бы восьми, но омики на всякий случай перестраховались.

Я такой эмулятор сделал на базе linref бутлоадера. Оно работает, но чутка не допилино.

Ну тут можно двояко охарактеризовать: либо это норма, либо это пандемия велосипедостроительства. В целом спасибо за ответ, я и не сомневался.

если б я не хотел своих велосипедов — то вряд ли так хотел бы писать на обероне (ну, КП, без разницы). и форкать BBCB не стал бы. и ещё много чего.

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

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

одна из главных причин, по котрым мне неинтересна A2: её никто не делает для себя. штука-то крутая, но… у семи нянек дитя с глазами в два ряда вокруг головы.

та же фигня с Direct-To-COM Compiler в BBCB, например: омики его делали для продажи, а не для себя. в коде он занимается тем, что мешает. поэтому я его выкинул.

то же, кстати, можно сказать про поддержку винды в LC. она мне досталась в наследство, и живёт по принципу: «ты меня не бойся, я хороший, я тебя не трону.»

в общем, всё, что делается не для себя — или не закончено, или плохо сдизайнено, или неюзабельно, или всё это вместе. а что делается для себя — имеет тенденцию спавнить велосипеды в больших количествах.

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

Это только говорит об уровне понимания. Интересно, что случится с пирующими, когда они узнают о том, что в Обероне и выход за границы массива, и разыменование 0-го указателя - это неопределённого поведение? А это, тем не менее, не проблема.

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

с моей точки зрения это говорит о том, что спеки языка надо починить. потому что иначе получается сишечка, где надо молиться, поститься, и всё равно наступишь на грабли с UB. поведение CASE/WITH должно быть чётко описано; для разыменования NIL и выхода за границы массива должно быть указано, что это вызывает трап. компилятор может предоставлять средства эти проверки отключать, но не обязан.

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

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

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

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

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

вообще, надо бы в ультрапаскале запретить в WITH использовать разные переменные. то есть, сделать примерно то же, что в O7. `WITH var AS … END`. всё равно `AS` я уже зарезервировал. `CASE`, конечно, красившее, но не хочу смешивать две разных конструкции, которые никак не различить без информации о типах.

в общем, две формы WITH теперь будет. или так:

или так:

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

Жонглирование терминами - это больше Ваше хобби, Константин. Если у Вас есть программа, которая устанавливает это "другое специальное значение", то значит, это изменение - не для Вас. Если же мы говорим о долгосрочном развитии какого-либо языка, то иногда приходится и программы менять, например, так происходит при переходе от Питона 2 к Питону 3. Конечно, это неприятно и вызывает у многих протест, но в реальной жизни только у Вирта сразу получаются идеальные языки, не требующие выхода новых редакций. В других же языках, созданных обычными людьми, а не пророками, рано или поздно происходят несовместимые изменения - либо из-за изначально допущенных ошибок, либо из-за насущных потребностей развития. И тогда все программы приходится пересматривать, а то и переделывать. В данном случае, можно было бы добавить аннотацию на уровне индивидуальной переменной - "не чисть эту переменную" или "заполни эту переменную мусором вместо нуля", и читателю кода было бы ясно, что здесь-то и может быть установлено специальное магическое значение мусора, которое для чего-то нужно. А так - магия полностью неявна и в этом ничего хорошего нет. Ну разве только кто-то работает на АНБ и закладки в линукс закладывает.

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

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

Вот просто в качестве примера, который меня вдохновлял. Фёдор Конюхов обошёл на яхте земной шар. Он шёл один (не считая автопилотов), но строил яхту не он. Евгений Гвоздев построил яхту, обошёл на ней земной шар. Но меньшее количество раз. Путь велосипедиста в программировании гораздо длиннее - легко можно проложить маршрут длиной в астрономические единицы - ведь вот они, небесные светила, прямо перед глазами - садись и крути педали, казалось бы. Но если целью является само движение, то тогда я умолкаю.

Это не проблема, но это означает, что заявления о какой-то там особенной надёжности Оберона - это просто рекламное враньё. Язык со сборкой мусора более уязвим по отношению к разрушению памяти, потому что его сложнее локализовать. Если эта неопределённость где-то реализована как разрушение кучи или стека, то я бы предпочёл писать на Си, а не на таком Обероне.

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

Тут я конечно сам себе противоречу, поскольку есть модуль SYSTEM. Но это по той принципе, что я думаю, а не выдаю готовые решения из головы. Модуль SYSTEM - это боль и его всё же можно локализовать хотя бы в пространстве исходных текстов, т.к. он требует явного импорта. А UB при инициализации переменных и, как теперь выясняется, при работе с массивами, размазано по всему исходнику и от него нельзя защититься. Т.е. тут есть разница. SYSTEM можно считать как необходимые куски сишного образа мысли в Обероне. Что отличается от тотальной деградации Оберона до уровня Си.

согласен с вами: велосипеды ради велосипедов — это весело, но малопродуктивно.

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

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

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

вот, например, декодер jpeg-ов я не понимаю — но это не критичная часть системы: это мне просто понадобилось однажды жыпег прочитать, я и спёр. можно было в пинг конвертнуть, конечо, но почему бы не спереть то, что плохо лежит. ;-) а вот декодер пингов я написал сам, и его я как раз понимаю. распаковщик deflate хоть и не мой, но там очень мало кода, и его несложно понять. X11 бэкэнд я тоже написал сам, и его я понимаю. также я довольно сильно переделал некоторые системные интерфейсы (Windows, тайлер, меню) — теперь я их тоже понимаю (ну, почти ;-).

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