Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 29 мар 2024, 04:31

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: реформа
СообщениеДобавлено: 24 янв 2018, 18:09 
Не в сети

Сообщения: 350
Вот тут я уже задавал вопросы. Вопросов и предложений с тех пор прибавилось, но я начну только с части. Я пришёл из вселенной лиспа. Оберон - маленький, Лисп - большой. У всего есть своя область применения, но я хочу язык размером больше Оберона. Часть того, что я хочу, лучше делать, внеся изменения в сам Оберон, для этого придётся делать форк. Пока я рассматриваю для этого 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. Соответственно, я ищу либо попутчиков, желающих поучаствовать в реализации хотя бы некоторых пунктов этого плана, или, возможно, ссылки на проекты, которые уже идут в том же направлении.


Последний раз редактировалось budden 25 янв 2018, 19:31, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 00:14 
Не в сети

Сообщения: 108
budden писал(а):
Что я бы поменял? По ходу написания этого списка я понял, что не всё ещё продумано. Вот некоторые более-менее устоявшиеся вещи.


Я не буду обсуждать сами изменения, но мы тут в соседней ветке как раз сошлись (вроде) в том, что оберон имеет смысл "расширять" под конкретную задачу. Если "улучшать" просто потому, что в моем любимом ЯП вот так, то я сомневаюсь, что получится что-то ценное.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 11:49 
Не в сети

Сообщения: 350
Ага, я видел, что вы сошлись в таком мнении. Но также я вижу, что особого энтузиазма мои предложения в Оберон-сообществе не вызвали.
Я уже имею довольно большой опыт в продвижении и он говорит о том, что продвигать что-либо - это очень дорогое развлечение. Мои результаты в плане продвижения идей пока близки к нулю :) Т.е. смысл обращения был в том, чтобы найти тех, кто уже сейчас думает почти так же, как я. Поэтому я тоже особо много не готов обсуждать - вряд ли затраты энергии оправдаются. Могу очень коротко обосновать.

п 1 действительно вытекает из опыта лиспа. Подход к целым числам как к числам неограниченной точности - единственный надёжный подход. Такая программа при переносе на процессор меньшей разрядности может работать медленно и съесть память, но она будет работать правильно или съест память. Программа, где диапазон целых зависит от разрядности, будет "как бы работать" при переносе на другой процессор. Это - худшее из зол.

п 2 - это здравый смысл, без него язык нельзя считать надёжным.
п 3 и 5 - можно считать вкусовщиной, но в реальности в точном сборщике эта информация уже есть и за неё уже уплачено снижением производительности. Не использовать эту информацию - это то же, что купить билет и не поехать.
Пп 4 и 6 отражают прогресс в программировании. Было осознано, что иммутабельность объекта делает программы гораздо более понятными и надёжными. Из них в лиспе п.4 делается, а п 6. в лиспе тоже не хватает. Лисп - это старый язык, его стандарт давно не обновлялся (с 1994 года). Тут я могу достаточно категорично сказать, что язык, в котором этого нет, не может претендовать на право называться надёжным, и нет никаких оснований не включить эту возможность в ядро самого Оберона, разве только какие-то проблемы с местом на системах с малым объёмом памяти.
п. 7 возможно, я просто не в курсе и это уже сделано, но на интернационализацию должен быть какой-то ответ, и он должен быть в ядре языка. Может быть, это будет опция сборки (Oberon с поддержкой юникода и без), но это должно быть стандартизовано - нет никакого смысла устраивать здесь велопарад.
п. 8 можно считать вкусовщиной.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 12:19 
Не в сети

Сообщения: 350
А вообще идея расширения под конкретную задачу приводит к неконкурентоспособности. Приходит человек и говорит, допустим: "хочу иммутабельные коллекции". В Clojure ему говорят "на, пользуйся", а в Oberone ему сначала говорят "а они не нужны", а потом говорят "ладно, так и быть, мы разрешаем тебе написать и поддерживать своё расширение языка, в котором они будут". Понятно, что человеку при прочих равных дешевле решить свою задачу на Clojure.

Есть другой вариант: включить требование контроля иммутабельности в стандарт языка, но сделать такой контроль необязательным. Т.е. простой компилятор просто будет игнорировать любые декларации const. В контроле будет дыра, но можно будет для проверки собрать и протестировать программу более мощным компилятором, перед тем, как запускать её на более слабом железе, в которое контроль иммутабельности, допустим, просто не помещается.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 12:21 
Не в сети

Сообщения: 350
Помимо этого, идея расширения под конкретную задачу имеет и другие недостатки. У языка должно быть свойство целостности. А то придёт Вася, расширит под свою задачу. Придёт Маша, немного другим способом расширит под такую же задачу. Придёт Петя, расширит под другую задачу. А потом Вова попытается задействовать одновременно расширения, предложенные Васей, Машей и Петей. Это не какая-то умозрительная угроза. Я уже в лиспе таким Вовой побывал и понял, что по сути мне придётся либо всё переделывать, либо выбирать, какие два из этих трёх мне придётся выкинуть.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 13:45 
Не в сети

Сообщения: 350
А, ну я смотрю, тут уже сделали Eberon, причём автор явно носитель славянского языка. Ха-ха. Т.е. кому надо - тот просто молча делает. Тогда мой текущий план состоит в том, чтобы взять этот OberonJs и сделать из него то, что надо. Заодно попрактикуюсь в Js. Не знаю, насколько хватит сил, но я хотя бы начну... BlackBox поломать было бы лучше, но это явно будет более трудозатратно.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 14:13 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Просто взгляды на то, как именно расширять язык, очень уж разнятся. Влад, по-моему, много спорных расширений внёс в Eberon, но он же для себя делает и никому ничего не должен.

Думаю, найти единомышленника, желающего расширения языка в том же ключе, будет весьма трудно. Мне повезло, нашёл Олега Комлева. Но сейчас у него нет времени на Оберон. :-(

GPCP, опять же, расширен над КП, правда, в основном в сторону более бесшовной интеграции с .NET и JVM. Мы тоже Ofront+ расширяем. Константные массивы реализовали и "правильный FOR", некоторые фичи из КП.

Zonnon для разнообразия посмотрите, O2M, OberonD, Modula-2 R10 и Objective Modula-2 (не знаю, правда, есть ли трансляторы), Modula-3, может быть даже Ada.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 15:30 
Не в сети

Сообщения: 350
Да, это печальная картина анархии :) Когда нет тирана, который всех заставляет делать единообразно, то получается вроде бы хорошо (свобода), но с другой стороны и плохо (мало возможностей). В роли тирана выступает заказчик/работодатель.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 16:16 
Не в сети

Сообщения: 108
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 - профайлер/дебаггер. Язык для этого трогать не надо.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: реформа
СообщениеДобавлено: 25 янв 2018, 19:33 
Не в сети

Сообщения: 350
Язык не надо, а реализацию это серьёзно может затронуть. Она станет больше и какие-то программы могут перестать помещаться в память (всё же Оберон минималистичен). К тому же внесение изменеий в реализацию - это всё равно форк.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club