Манифест Somatic Pascal

Somatic Pascal — это идея создания нового языка на платформе Somatic Runtime (тоже существует в виде идеи, но отдельные части уже реализованы).

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

Основные положения

Язык программирования должен опираться на платформу, крайне желательно, доступную и для других языков. Для Somatic Pascal это будет Somatic Runtime. В качестве примера можно посмотреть на Objective-C и Objective-C runtime. Objective-C runtime можно изпользовать не только в языке Objective-C, в отличие от Delphi, где на других языках создавать классы (официально, без хаков) невозможно, можно только подключать пакеты, скомпилированные Delphi. И в том же Delphi существует язык в языке, всё, что связано с COM и не завязано на конкретную версию компилятора, и именно эта часть нередко изпользуется для взаимодействия между компонентами, когда нужно отвязаться от версии компилятора или сделать межъязыковое взаимодействие. Однако, COM, в отличие от Objective-C runtime и Somatic Runtime, не поддерживает наследование реализаций, поэтому не может заменить родные языковые средства, а может лишь дополнить. Somatic Runtime, идейный наследник IBM SOM, именно эту роль и выполнит в языке Somatic Pascal. IBM SOM лучше, чем Objective-C по ряду причин¹, поэтому за основу берётся именно он, но в общем и целом подходы, применённые в экосистеме Objective-C верны, так что многое имеет смысл перенимать именно оттуда, а не из OS/2, откуда родом IBM SOM. Может быть, в OS/2 действительно есть другие интересные решения, но они относительно устарели, а библиотеки экосистемы Objective-C относительно свежи, надо только натянуть на них объектную модель IBM SOM. Например, есть Core Foundation для C и Foundation для Objective-C. Их открытые реализации существуют по отдельности, а в экосистеме Apple они сдвоены, но у этой двойной реализации коды закрыты. Можно было бы взять OpenCFLite и превратить в сдвоенную реализацию для C и для SOM, и то, что получится, назвать Somatic Foundation.
Pascal в названии языка должен быть только для рекламы, как в Component Pascal, а на самом деле быть потомком, например, Modula-2+. Это решение основано по результатам массового игнорирования среди паскалистов языка Ада, что особенно удивительно для создателей Free Pascal. Компилятор написать смогли, а по сторонам посмотреть не смогли. Удивительно, как ловко сюда примазался Oxygene, назвавшись Object Pascal, но это уж очень своеобразный Object Pascal. Если где–то в wiki про Паскаль в «См. также» добавляется Oxygene, эта правка остаётся, а совершенно аналогичную правку про язык Ада убирают. Это свинство нужно иметь в виду, и только ради этого в названии будет Pascal, и якобы Somatic Pascal будет реализовывать Object Pascal, точно так же якобы, как якобы это делает Oxygene, вне зависимости от реального положения дел. Ну, подумаешь, вместо TObject SOMObject, а вместо TClass — SOMClass. Вылитый Object Pascal.
Взаимодействие со старым кодом предполагается через компиляторы Delphi и Free Pascal с помощью IBM SOM Compiler (sc.exe). IBM SOM по замыслу многоязыковая, вот как раз и пригодится это качество.
В то время, как Delphi или, более вероятно, Free Pascal, могут теоретически вобрать в свой синтаксис средства для упрощённой работы с SOM, так же, как это сделано с COM, в Somatic Pascal должны быть изначально некоторые ограничения IBM SOM, которые не могут, не ломая преемственности, вобрать в себя эти языки. IBM SOM даёт большую гибкость (добавить метод, мигрировать метод, изменить структуру наследования классов) в том, чтобы, не ломая совместимость, производить изменения. В языках Delphi, Ada, C++ и многих других, допускающих разбиение на разделяемые библиотеки (.bpl), возникает проблема хрупкого базового класса и многие другие проблемы, которые призван решить IBM SOM. Somatic Pascal, в отличие от гипотетического Free Pascal with Somatic Extensions, должен с самого начала проектироваться, опираясь на SOM. Как и в Delphi.NET или Oxygene, это может привести к тому, что unit будет компилироваться в класс или вместо unit будет что–то другое. Результатом такого подхода должно быть отсутствие какого–то местечкого формата .bpl, жёстко привязанного к версии компилятора и чувствительного к малейшим изменениям interface своих зависимостей, а вместо этого должны быть .dll или другой формат для соответствующей операционной системы. Разумеется, тоже чувствительный к изменениям, но степень этой чувствительности в SOM ниже, чем где–либо.
На уровне синтаксиса лёгкий способ создавать коллекции Somatic Foundation и манипулировать ими. Читать и писать из/в property lists, JSON, YAML, другие форматы.
В подавляющем большинстве языков нормальной практикой при компиляции зависимого проекта является установить все зависимости и после этого компилировать. При этом то, что было скомпилировано, получается привязано к конкретным установленным версиям зависимостей, а при запуске версия зависимости может быть ниже, что приведёт к ошибке. В Somatic Pascal должно быть легко собрать компонент без всяких там установок зависимостей. Зависимость должна быть только от SDK, которые могут быть гораздо старше, чем установленные пакеты. При сборке сложных проектов должна быть нормальной ситуация, когда разные компоненты собираются с разными версиями SDK. Желательно, чтобы версии SDK зависимостей мог указывать тот же человек, что и пишет код компонента. Если SDK небольших размеров, то можно целиком включать .idl в свой проект.
На основании документа Object-Oriented Programming Versus Abstract Data Types родилась мысль, что модулям правильно быть классами, а экземпляры ADT должны быть виртуально представлены двойным указателем, первый указатель — на модуль–класс, реализующий все действия с этим ADT, второй указатель — на экземпляр этого ADT. Действия над ADT разрешены только если у них одинаковый модуль–класс. Практически, большую часть времени в оперативной памяти будут только указатели на ADT, а первый указатель будет как бы «в уме», в метаинформации компилятора. Надо над этим ещё подумать.
Потенциальная компиляция в JavaScript, но, желательно, не 1:1, как во многих других языках, а, преодолевая некоторые проблемы. В JavaScript есть проблема, что нужно возвращать выполнение на самый верх время от времени, при этом нет нормальных продолжений, а если применять генераторы, то всё равно пробрасывать через все генераторы выполнение на самый верх проблематично, и браузеры код с генераторами медленно изполняют. Одна из реализаций Turbo Pascal для web реализует виртуальную машину, которая возвращает управление после превышения числа итераций, либо при вызове Delay. Этот подход можно развить до компиляции фрагментов кода в JavaScript так, чтобы в циклах и вызовах функций проверялся отведённый предел итераций. Реализовать иллюзию многопоточности.
Даже в натив компиляция, возможно, будет только через C. За основу может быть взят проект вроде http://adatoccpptranslator.free.fr/ . В противном случае тяжело работать с платформами типа FlasCC, NativeClient, asm.js, OpenRISC, Zylon CPU и прочими постоянно плодящимися, под которые нет других компиляторов, кроме C и C++, и эту гонку, как сейчас видно, не выиграть. Снизить негативное влияние постоянных шоков всё же можно.

Принципы Somatic Runtime

В качестве основы взять somFree. Какие–то фрагменты, возможно, подойдут от NOM.
Вторым важным компонентом является Wine, конкретно, такая возможность, как Winelib. Многое может быть вырезано, так как хорошая эмуляция Windows не нужна.
Для таких архитектур, как MIPS (ТВ–приставки, роутеры), допустимо примемение родных для этой платформы форматов. Однако, для x86 и x86-64 крайне желательно в качестве основного формата изпользовать .exe (PE COFF), компилируемых один раз для каждой архитектуры. При запуске определяется, на какой платформе сейчас запущена программа и в зависимости от этого загружаются библиотеки для соответствующей платформы: для работы с сетью, для GUI, для остального. Для GUI, вполне возможно, будет выбран wxWidgets. В текущих обстоятельствах wxWidgets требует компиляции под каждую OS: FreeBSD, Solaris, Mac OS X, Darwin, Windows, а в составе Somatic Runtime единый .exe с вашей программой, будучи запущенным на любой из этих OS, подключит и начнёт изпользовать версию для соответствующей OS.
Получается бинарный аналог Java. Хочется надеяться, этот бинарный аналог положит конец засилью Windows и сделает интересным изпользование не только Linux, но и других OS.
UTF-32 и UTF-8 как основные форматы строк.
На будущее (подумать): взаимодействие с Erlang. Или, лучше http://www.parasail-lang.org/ , когда он созреет. Или https://awelonblue.wordpress.com/ ?

Видео

Сноски

^ См. статью Сравнение объектных моделей

Навигация Главная Скачать Turbo Pascal Скачать справочник Turbo Pascal Онлайн Форум \| Группа ВК \| Чат Лекции Алфавитный указатель Содержание справки Язык Turbo Pascal Стандартные модули Функции и процедуры Директивы компилятора Примеры программ Меню Turbo Pascal Ада-2020. Современный Паскаль Адское программирование Статьи по Ада-2020 Отзывы и идеи Об этом сайте Чат Войти Форум Загрузка...	Somatic Pascal — это идея создания нового языка на платформе Somatic Runtime (тоже существует в виде идеи, но отдельные части уже реализованы). Идея сформировалась как результат неудовлетворённости всеми другими решениями, а также как результат того, что некоторые ниши до сих пор пустуют. Основные положения Язык программирования должен опираться на платформу, крайне желательно, доступную и для других языков. Для Somatic Pascal это будет Somatic Runtime. В качестве примера можно посмотреть на Objective-C и Objective-C runtime. Objective-C runtime можно изпользовать не только в языке Objective-C, в отличие от Delphi, где на других языках создавать классы (официально, без хаков) невозможно, можно только подключать пакеты, скомпилированные Delphi. И в том же Delphi существует язык в языке, всё, что связано с COM и не завязано на конкретную версию компилятора, и именно эта часть нередко изпользуется для взаимодействия между компонентами, когда нужно отвязаться от версии компилятора или сделать межъязыковое взаимодействие. Однако, COM, в отличие от Objective-C runtime и Somatic Runtime, не поддерживает наследование реализаций, поэтому не может заменить родные языковые средства, а может лишь дополнить. Somatic Runtime, идейный наследник IBM SOM, именно эту роль и выполнит в языке Somatic Pascal. IBM SOM лучше, чем Objective-C по ряду причин¹, поэтому за основу берётся именно он, но в общем и целом подходы, применённые в экосистеме Objective-C верны, так что многое имеет смысл перенимать именно оттуда, а не из OS/2, откуда родом IBM SOM. Может быть, в OS/2 действительно есть другие интересные решения, но они относительно устарели, а библиотеки экосистемы Objective-C относительно свежи, надо только натянуть на них объектную модель IBM SOM. Например, есть Core Foundation для C и Foundation для Objective-C. Их открытые реализации существуют по отдельности, а в экосистеме Apple они сдвоены, но у этой двойной реализации коды закрыты. Можно было бы взять OpenCFLite и превратить в сдвоенную реализацию для C и для SOM, и то, что получится, назвать Somatic Foundation. Pascal в названии языка должен быть только для рекламы, как в Component Pascal, а на самом деле быть потомком, например, Modula-2+. Это решение основано по результатам массового игнорирования среди паскалистов языка Ада, что особенно удивительно для создателей Free Pascal. Компилятор написать смогли, а по сторонам посмотреть не смогли. Удивительно, как ловко сюда примазался Oxygene, назвавшись Object Pascal, но это уж очень своеобразный Object Pascal. Если где–то в wiki про Паскаль в «См. также» добавляется Oxygene, эта правка остаётся, а совершенно аналогичную правку про язык Ада убирают. Это свинство нужно иметь в виду, и только ради этого в названии будет Pascal, и якобы Somatic Pascal будет реализовывать Object Pascal, точно так же якобы, как якобы это делает Oxygene, вне зависимости от реального положения дел. Ну, подумаешь, вместо TObject SOMObject, а вместо TClass — SOMClass. Вылитый Object Pascal. Взаимодействие со старым кодом предполагается через компиляторы Delphi и Free Pascal с помощью IBM SOM Compiler (sc.exe). IBM SOM по замыслу многоязыковая, вот как раз и пригодится это качество. В то время, как Delphi или, более вероятно, Free Pascal, могут теоретически вобрать в свой синтаксис средства для упрощённой работы с SOM, так же, как это сделано с COM, в Somatic Pascal должны быть изначально некоторые ограничения IBM SOM, которые не могут, не ломая преемственности, вобрать в себя эти языки. IBM SOM даёт большую гибкость (добавить метод, мигрировать метод, изменить структуру наследования классов) в том, чтобы, не ломая совместимость, производить изменения. В языках Delphi, Ada, C++ и многих других, допускающих разбиение на разделяемые библиотеки (.bpl), возникает проблема хрупкого базового класса и многие другие проблемы, которые призван решить IBM SOM. Somatic Pascal, в отличие от гипотетического Free Pascal with Somatic Extensions, должен с самого начала проектироваться, опираясь на SOM. Как и в Delphi.NET или Oxygene, это может привести к тому, что unit будет компилироваться в класс или вместо unit будет что–то другое. Результатом такого подхода должно быть отсутствие какого–то местечкого формата .bpl, жёстко привязанного к версии компилятора и чувствительного к малейшим изменениям interface своих зависимостей, а вместо этого должны быть .dll или другой формат для соответствующей операционной системы. Разумеется, тоже чувствительный к изменениям, но степень этой чувствительности в SOM ниже, чем где–либо. На уровне синтаксиса лёгкий способ создавать коллекции Somatic Foundation и манипулировать ими. Читать и писать из/в property lists, JSON, YAML, другие форматы. В подавляющем большинстве языков нормальной практикой при компиляции зависимого проекта является установить все зависимости и после этого компилировать. При этом то, что было скомпилировано, получается привязано к конкретным установленным версиям зависимостей, а при запуске версия зависимости может быть ниже, что приведёт к ошибке. В Somatic Pascal должно быть легко собрать компонент без всяких там установок зависимостей. Зависимость должна быть только от SDK, которые могут быть гораздо старше, чем установленные пакеты. При сборке сложных проектов должна быть нормальной ситуация, когда разные компоненты собираются с разными версиями SDK. Желательно, чтобы версии SDK зависимостей мог указывать тот же человек, что и пишет код компонента. Если SDK небольших размеров, то можно целиком включать .idl в свой проект. На основании документа Object-Oriented Programming Versus Abstract Data Types родилась мысль, что модулям правильно быть классами, а экземпляры ADT должны быть виртуально представлены двойным указателем, первый указатель — на модуль–класс, реализующий все действия с этим ADT, второй указатель — на экземпляр этого ADT. Действия над ADT разрешены только если у них одинаковый модуль–класс. Практически, большую часть времени в оперативной памяти будут только указатели на ADT, а первый указатель будет как бы «в уме», в метаинформации компилятора. Надо над этим ещё подумать. Потенциальная компиляция в JavaScript, но, желательно, не 1:1, как во многих других языках, а, преодолевая некоторые проблемы. В JavaScript есть проблема, что нужно возвращать выполнение на самый верх время от времени, при этом нет нормальных продолжений, а если применять генераторы, то всё равно пробрасывать через все генераторы выполнение на самый верх проблематично, и браузеры код с генераторами медленно изполняют. Одна из реализаций Turbo Pascal для web реализует виртуальную машину, которая возвращает управление после превышения числа итераций, либо при вызове Delay. Этот подход можно развить до компиляции фрагментов кода в JavaScript так, чтобы в циклах и вызовах функций проверялся отведённый предел итераций. Реализовать иллюзию многопоточности. Даже в натив компиляция, возможно, будет только через C. За основу может быть взят проект вроде http://adatoccpptranslator.free.fr/ . В противном случае тяжело работать с платформами типа FlasCC, NativeClient, asm.js, OpenRISC, Zylon CPU и прочими постоянно плодящимися, под которые нет других компиляторов, кроме C и C++, и эту гонку, как сейчас видно, не выиграть. Снизить негативное влияние постоянных шоков всё же можно. Принципы Somatic Runtime В качестве основы взять somFree. Какие–то фрагменты, возможно, подойдут от NOM. Вторым важным компонентом является Wine, конкретно, такая возможность, как Winelib. Многое может быть вырезано, так как хорошая эмуляция Windows не нужна. Для таких архитектур, как MIPS (ТВ–приставки, роутеры), допустимо примемение родных для этой платформы форматов. Однако, для x86 и x86-64 крайне желательно в качестве основного формата изпользовать .exe (PE COFF), компилируемых один раз для каждой архитектуры. При запуске определяется, на какой платформе сейчас запущена программа и в зависимости от этого загружаются библиотеки для соответствующей платформы: для работы с сетью, для GUI, для остального. Для GUI, вполне возможно, будет выбран wxWidgets. В текущих обстоятельствах wxWidgets требует компиляции под каждую OS: FreeBSD, Solaris, Mac OS X, Darwin, Windows, а в составе Somatic Runtime единый .exe с вашей программой, будучи запущенным на любой из этих OS, подключит и начнёт изпользовать версию для соответствующей OS. Получается бинарный аналог Java. Хочется надеяться, этот бинарный аналог положит конец засилью Windows и сделает интересным изпользование не только Linux, но и других OS. UTF-32 и UTF-8 как основные форматы строк. На будущее (подумать): взаимодействие с Erlang. Или, лучше http://www.parasail-lang.org/ , когда он созреет. Или https://awelonblue.wordpress.com/ ? Видео Сноски ^ См. статью Сравнение объектных моделей
	Тэги: