Оберон-клуб «ВЄДАsoft» https://zx.oberon.org/forum/ |
|
реформа https://zx.oberon.org/forum/viewtopic.php?f=79&t=360 |
Страница 1 из 3 |
Автор: | budden [ 24 янв 2018, 18:09 ] |
Заголовок сообщения: | реформа |
Вот тут я уже задавал вопросы. Вопросов и предложений с тех пор прибавилось, но я начну только с части. Я пришёл из вселенной лиспа. Оберон - маленький, Лисп - большой. У всего есть своя область применения, но я хочу язык размером больше Оберона. Часть того, что я хочу, лучше делать, внеся изменения в сам Оберон, для этого придётся делать форк. Пока я рассматриваю для этого BB, но вообще какой-нибудь консольный вариант может оказаться лучше. Что я бы поменял? По ходу написания этого списка я понял, что не всё ещё продумано. Вот некоторые более-менее устоявшиеся вещи. 1. INTEGER - это целое число неограниченного размера, живёт в куче и является ссылочным типом. Также есть RANGE(MIN,MAX), частными случаями которого являются нынешние SHORTINT и т.п. Существующий INTEGER придётся переименовать. 2. Точная сборка мусора. Я остаюсь при своём мнении: консервативная сборка мусора - нанадёжный механизм. Точная сборка может привести к сокращению диапазона INTEGER на 1-2 бита, поскольку понадобится отличить указатель от числа. 3. Тип BOX или VARIANT - ему может быть присвоен объект любого типа. BOX знает runtime тип своего объекта, т.е. это - не void *, а поэтому он безопасен. Конструкция with соответствующим образом обобщается. Заметьте, что здесь вводится не больше динамической типизации, чем в случае расширения типов, просто она обобщается и на другие типы. Конкретную семантику нужно ещё уточнять. ANYPTR в BB недостаточен, т.к. в нём (если я правильно понял) нельзя хранить произвольные массивы. Невозможность хранения примитивных типов можно было бы обойти, включив для каждого из них отдельное поле. 4. Ненулевые указатели - такие, которым нельзя присвоить NIL. Соответственно, добавляется конструкция IFNULL P P1 <Ветка если NIL> ELSE <Ветка если не NIL>, где P - нулевой указатель на T, а P1 - имя переменной . В ветке "если не NIL" указатель P1 имеет тип ненулевого указателя на T и равно значению P в момент проверки условия. В ветке "если NIL" P1 отсутствует. 5. Возможность перебрать все объекты в куче и сделать какое-то действие для каждого из них. Два действия, которые точно нужны - это подсчёт количества объектов, удовлетворяющих заданному условию, и создание списка указателей на такие объекты. 6. Иммутабельность. В простейшем случае это подразумевает добавление одной функции "заморозить", см. Object.freeze. Но лучше добавить ещё и поддержку ключевого слова const. Для указателя, как и в Си, ввести два понятия - иммутабельность самого указателя, и иммутабельность указываемого объекта. 7. Ввести больше разновидностей char, чтобы поддерживать разные виды международной письменности. 16-разрядный CHAR в BB недостаточен, 8-разрядный из Оберона-2 - тем более. Хотя для европейских языков 16 разрядов хватит. Другое дело, что наличие тега типа может уменьшить количество доступных полезных разрядов на 2-4 бита. 8. API, позволяющее подменять функцию во всех точках вызова. Первое применение этого API - трассировка, но есть и другие. Надо отметить, что лучше иметь указателем по умолчанию указатель не нулевой, иммутабельный и указывающий на иммутабельный объект. Это сегодня в моде - считается, что такие программы проще и надёжнее. Поскольку слово POINTER уже занято, можно взять для этой цели какой-нибудь PTR, тогда существующую ф-ю PTR придётся переименовать. Примерно так. На самом деле, это часть планов по Яру, но теперь я переосмысливаю их в контексте Оберона и не всё получается так вот сразу. Яр построен на лиспе, там некоторые вещи проще (например, нет различия между непосредственными и ссылочными типами). Я знаю, что у Оберона есть консервативные приверженцы, которые считают, что в языке есть всё, что нужно. При всём уважении к этой точке зрения, я говорю не о внесении изменений в язык, а о создании другого языка на базе оберона-2. Соответственно, я ищу либо попутчиков, желающих поучаствовать в реализации хотя бы некоторых пунктов этого плана, или, возможно, ссылки на проекты, которые уже идут в том же направлении. |
Автор: | vlad [ 25 янв 2018, 00:14 ] |
Заголовок сообщения: | Re: реформа |
budden писал(а): Что я бы поменял? По ходу написания этого списка я понял, что не всё ещё продумано. Вот некоторые более-менее устоявшиеся вещи. Я не буду обсуждать сами изменения, но мы тут в соседней ветке как раз сошлись (вроде) в том, что оберон имеет смысл "расширять" под конкретную задачу. Если "улучшать" просто потому, что в моем любимом ЯП вот так, то я сомневаюсь, что получится что-то ценное. |
Автор: | budden [ 25 янв 2018, 11:49 ] |
Заголовок сообщения: | Re: реформа |
Ага, я видел, что вы сошлись в таком мнении. Но также я вижу, что особого энтузиазма мои предложения в Оберон-сообществе не вызвали. Я уже имею довольно большой опыт в продвижении и он говорит о том, что продвигать что-либо - это очень дорогое развлечение. Мои результаты в плане продвижения идей пока близки к нулю ![]() п 1 действительно вытекает из опыта лиспа. Подход к целым числам как к числам неограниченной точности - единственный надёжный подход. Такая программа при переносе на процессор меньшей разрядности может работать медленно и съесть память, но она будет работать правильно или съест память. Программа, где диапазон целых зависит от разрядности, будет "как бы работать" при переносе на другой процессор. Это - худшее из зол. п 2 - это здравый смысл, без него язык нельзя считать надёжным. п 3 и 5 - можно считать вкусовщиной, но в реальности в точном сборщике эта информация уже есть и за неё уже уплачено снижением производительности. Не использовать эту информацию - это то же, что купить билет и не поехать. Пп 4 и 6 отражают прогресс в программировании. Было осознано, что иммутабельность объекта делает программы гораздо более понятными и надёжными. Из них в лиспе п.4 делается, а п 6. в лиспе тоже не хватает. Лисп - это старый язык, его стандарт давно не обновлялся (с 1994 года). Тут я могу достаточно категорично сказать, что язык, в котором этого нет, не может претендовать на право называться надёжным, и нет никаких оснований не включить эту возможность в ядро самого Оберона, разве только какие-то проблемы с местом на системах с малым объёмом памяти. п. 7 возможно, я просто не в курсе и это уже сделано, но на интернационализацию должен быть какой-то ответ, и он должен быть в ядре языка. Может быть, это будет опция сборки (Oberon с поддержкой юникода и без), но это должно быть стандартизовано - нет никакого смысла устраивать здесь велопарад. п. 8 можно считать вкусовщиной. |
Автор: | budden [ 25 янв 2018, 12:19 ] |
Заголовок сообщения: | Re: реформа |
А вообще идея расширения под конкретную задачу приводит к неконкурентоспособности. Приходит человек и говорит, допустим: "хочу иммутабельные коллекции". В Clojure ему говорят "на, пользуйся", а в Oberone ему сначала говорят "а они не нужны", а потом говорят "ладно, так и быть, мы разрешаем тебе написать и поддерживать своё расширение языка, в котором они будут". Понятно, что человеку при прочих равных дешевле решить свою задачу на Clojure. Есть другой вариант: включить требование контроля иммутабельности в стандарт языка, но сделать такой контроль необязательным. Т.е. простой компилятор просто будет игнорировать любые декларации const. В контроле будет дыра, но можно будет для проверки собрать и протестировать программу более мощным компилятором, перед тем, как запускать её на более слабом железе, в которое контроль иммутабельности, допустим, просто не помещается. |
Автор: | budden [ 25 янв 2018, 12:21 ] |
Заголовок сообщения: | Re: реформа |
Помимо этого, идея расширения под конкретную задачу имеет и другие недостатки. У языка должно быть свойство целостности. А то придёт Вася, расширит под свою задачу. Придёт Маша, немного другим способом расширит под такую же задачу. Придёт Петя, расширит под другую задачу. А потом Вова попытается задействовать одновременно расширения, предложенные Васей, Машей и Петей. Это не какая-то умозрительная угроза. Я уже в лиспе таким Вовой побывал и понял, что по сути мне придётся либо всё переделывать, либо выбирать, какие два из этих трёх мне придётся выкинуть. |
Автор: | budden [ 25 янв 2018, 13:45 ] |
Заголовок сообщения: | Re: реформа |
А, ну я смотрю, тут уже сделали Eberon, причём автор явно носитель славянского языка. Ха-ха. Т.е. кому надо - тот просто молча делает. Тогда мой текущий план состоит в том, чтобы взять этот OberonJs и сделать из него то, что надо. Заодно попрактикуюсь в Js. Не знаю, насколько хватит сил, но я хотя бы начну... BlackBox поломать было бы лучше, но это явно будет более трудозатратно. |
Автор: | Zorko [ 25 янв 2018, 14:13 ] |
Заголовок сообщения: | Re: реформа |
Просто взгляды на то, как именно расширять язык, очень уж разнятся. Влад, по-моему, много спорных расширений внёс в Eberon, но он же для себя делает и никому ничего не должен. Думаю, найти единомышленника, желающего расширения языка в том же ключе, будет весьма трудно. Мне повезло, нашёл Олега Комлева. Но сейчас у него нет времени на Оберон. ![]() GPCP, опять же, расширен над КП, правда, в основном в сторону более бесшовной интеграции с .NET и JVM. Мы тоже Ofront+ расширяем. Константные массивы реализовали и "правильный FOR", некоторые фичи из КП. Zonnon для разнообразия посмотрите, O2M, OberonD, Modula-2 R10 и Objective Modula-2 (не знаю, правда, есть ли трансляторы), Modula-3, может быть даже Ada. |
Автор: | budden [ 25 янв 2018, 15:30 ] |
Заголовок сообщения: | Re: реформа |
Да, это печальная картина анархии ![]() |
Автор: | vlad [ 25 янв 2018, 16:16 ] |
Заголовок сообщения: | Re: реформа |
budden писал(а): Ага, я видел, что вы сошлись в таком мнении. Но также я вижу, что особого энтузиазма мои предложения в Оберон-сообществе не вызвали. Многие твои предложения сильно отклоняются от генеральной обероновской линии партии "как можно проще". Ну и оценить возможный профит нововведений, не имея опыта с лиспом, трудно. budden писал(а): п 1 действительно вытекает из опыта лиспа. Подход к целым числам как к числам неограниченной точности - единственный надёжный подход. Такая программа при переносе на процессор меньшей разрядности может работать медленно и съесть память, но она будет работать правильно или съест память. Программа, где диапазон целых зависит от разрядности, будет "как бы работать" при переносе на другой процессор. Это - худшее из зол. п 1 может быть не так важен, как тебе кажется. Я вот, например, до сих не знаю чего там будет в питоне с целыми при переполнении и какая там у них разрядность. При том, что я пользуюсь этим языком больше 10 лет. Ну не было у меня там задач с серьезной целочисленной арифметикой. Не говоря о том, что перенос на другую платформу, особенно с меньшей разрядностью неактуален для 99.99% программ, написанных на ББ. budden писал(а): п 2 - это здравый смысл, без него язык нельзя считать надёжным. Точный сборщик, конечно, лучше. Но тоже ничего не меняет для 99.99% программ. budden писал(а): п 3 и 5 - можно считать вкусовщиной, но в реальности в точном сборщике эта информация уже есть и за неё уже уплачено снижением производительности. Не использовать эту информацию - это то же, что купить билет и не поехать. п 3 уже есть в ББ в виде ANY PTR. п 5 - похож на профайлер, иногда полезно иметь, но ЯП для этого менять не надо, это фича рантайма. budden писал(а): Пп 4 Ненулевые указатели у меня в планах для oberonjs. Это, пожалуй, самая близкая для меня тема из всего твоего списка. budden писал(а): и 6 отражают прогресс в программировании. Согласен. budden писал(а): п. 7 возможно, я просто не в курсе и это уже сделано, но на интернационализацию должен быть какой-то ответ, и он должен быть в ядре языка. Ну есть в ББ CHAR, какие конкретно претензии? budden писал(а): п. 8 можно считать вкусовщиной. То же, что и п5 - профайлер/дебаггер. Язык для этого трогать не надо. |
Автор: | budden [ 25 янв 2018, 19:33 ] |
Заголовок сообщения: | Re: реформа |
Язык не надо, а реализацию это серьёзно может затронуть. Она станет больше и какие-то программы могут перестать помещаться в память (всё же Оберон минималистичен). К тому же внесение изменеий в реализацию - это всё равно форк. |
Страница 1 из 3 | Часовой пояс: UTC + 2 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |