Info21 писал(а):
Пётр Кушнир писал(а):
Надо ещё язык переделать слегка. Чтобы было ultra. Чтобы преодолеть Оберон и дальше жить.
Что переделать слегка?
Ну, скажем так, я первый раз формирую такой список "претензий", поэтому будет слегка сумбурно. Есть несколько видимых направлений в сторону примитивизации и наращивания перспектив одновременно. (это я сейчас обобщаю многолетний опыт оберон-бытия и уже многолетний опыт мейнстрим-страдания). Это касается как языка, так и рантайма и фреймворка.
Для начала, я бы слегка упростил систему описания блоков команд (сейчас в разных видах это присутствует в теле модуля, в теле процедуры, в теле IF, WHILE...), можно это всё унифицировать, что откроет путь к поддержке параллелизма, асинхронности и кложурности, но на уровне, близком к описанию машинной организации фреймов и т.д. Потому что если посмотреть на это всё здраво, то это одно и то же, модуль это процедура, процедура это блок команд и т.д. Просто модуль это такая процедура, которую ядро зачем-то запомнило, как главную. Вот. Все блоки команд снабдить обязательным описанием предусловий и постусловий, входными выходными и регистровыми параметрами, забыть про т.н. "функции" и закрыть этот вопрос. Тут вот многим кажется, что наоборот, надо идти к функциональности, к тому, что всё есть выражение и вообще вся программа это одно выражение, мне вот кажется, надо наоборот.
Во-вторых, я бы слегка причесал систему примитивных типов, перенёс бы её в невидимый модуль CORE (аналог SYSTEM для всех платформ) и добавил бы туда базовые контейнеры (LIST, MAP, SET), чтобы уже закрыть этот вопрос, к тому же, учитывая то, что расширяемую систему типов ждёт пересмотр. Ну и плюс к этому возможность описать в стандартном модуле нужные в 2019 математические типы, тензоры векторы комплексные числа, троичную логику, это всё фишки, которые можно сделать компонентными и "встроенными" одновременно, тоже закрывая вопрос с тем, чего там не хватает крикливым упырям из Питон-мира
Ну и самое важное, на мой взгляд, надо отказаться от классической модели ООП в сторону двойной системы пользовательской классификации множеств объектов в рантайме. Первая, то что называют интерфейсами, по набору видимых поведений, вторая по возможности объединения в математические множества, то есть это алгебраическая система типов на тегах, их отношениях и возможности движения от одного типа к другому. В самых смелых фантазиях это вообще откат к контролируемому полю типа, при чём оно должно быть даже у примитивных типов, что-то типа разделения состояния объекта на информационное и канальное.
На первых порах можно воспользоваться приципами описания типов из уже готовых систем, типа
https://ru.wikipedia.org/wiki/Web_Ontology_Language а потом и оберон-вэй придумается.
По моим экспериментам, для этого достаточно введения атомарного типа данных, который суть просто идентификатор, описывающий сам себя. Самым интересным в этом плане будет являться использование того, что придумали оберонщики, тег типа к каждому вообще значению, объекту, и тд, это открывает возможность дать юзеру контроль над этим тегом типа, возвращаясь к контейнерам, мы можем описывать логику типизирования значений в контейнере как нам надо, и это будет гораздо мощнее и полнее, чем джавовский <? extends MyType> и вот это всё.
Дальше уже открываются возможности описывать не только формальные признаки программируемых объектов, но и их сущностные характеристики, границы применимости той или иной типизации, когда свойства ограничиваются типом но и тип ограничивается свойствами, и не будет в выдуманном аутистами-программистами мире письменных столов длиной в километр или вагонов с тысячей колёсных пар. Но это конечно перспективные движения, они требуют первого шага по отказу от ООП.
Дальше уже более приземлённые вещи, в модуль CORE (это я уже отхожу от языка к рантайму) вынести все стандартные процедуры, а в язык добавить возможность описывать инфиксные процедуры, которые заменят собой концептуально устаревшие модули математики, операций со строками, и тд. Конечно, такие важные модули будут под контролем сообщества, но опять же, учитывая упрощения понятий модуля процедуры и тд
Ещё можно подумать над программируемостью процесса компиляции, но это фичи рискованные.
Ну, слим-бинарники с возможностью процессинга и переопределения кода, полезная вещь, особенно в будущем компонентном мире блоков кода, где совокупность поведения (методов) это определитель интерфейса.
Герметичность, куда же без неё, никаких больше SYSTEM, как это сделано во всех операционных системах, хочется в памяти байты переставлять, пожалуйте писать драйвер, да под пользовательский разъем вне ядра, помимо прочего это даст возможность написания рантаймов не только под разные ОС, но и под разные платформы исполнения, типа видеокарт.
А вообще, это конечно уже на перспективу, хотелось бы чтобы оберон охватывал в едином неразрывном стиле все шаги из схемы жизни программы, которые я когда-то описал. На самом деле всё что тут описано может быть реализовано минимальными средствами да ещё и в эстетике оберон-языков, ну вот тогда уже можно и ультра-паскаль объявлять.
Вход
FAQ
Поиск
