Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  14:26[Войти] | [Зарегистрироваться]
Обсуждение темы:
Мысли об Обероне

На базарной площади довольно часто можно слышать высказывания об Обероне. Мне кажется, что на базарной площади пора появиться ветке об этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы этой системы, что полезного можно извлечь из него для программирования на Дельфи (например) и др.

Ivan

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 4531 сообщение


Ссылки по теме "Оберон" и "Компонентный паскаль"



Отслеживать это обсуждение


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Разработка препроцессора gpre для delphi\freepascal.
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • <<<... | 2601—2592 | 2591—2582 | 2581—2572 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 195


    № 2591   09-08-2005 08:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2590« (Иван Горячев)
    ___________________________

    У меня вот вопрос - как быть с зоопарком типов? C вещественными типами, например.

    Не такой уж это зоопарк. :o) Разве что есть небольшие расхождения, но они вполне разумно могут быть снивелированы. Кстати говоря, неплохо было бы иметь на руках для обсуждения сравнительные таблицы расхождений для трех языков, а также для соотв. IDE. Что-то такого документа я нигде не встречал...

    Далее, касательно строк вообще и юникода в частности (потому как они мне сейчас ближе всего) - в XDS и ETH двубайтового символьного типа нет, насколько я помню.

    Насчет Unicode: а что хотелось бы поддерживать -- UTF-8, UTF-16, UTF-32 и почему?


    По поводу процедурных типов. Возможность их применения зависит от того, собирается ли OM дальше работать над Блэкбоксом, ибо в документации они грозились процедурные типы убрать...

    Процедурные типы закреплены в языке. Они решили поменять язык? И назвать его по-другому? Вот Вам и налицо произвол компании-монополиста :o) А мы тут планируем сделать на них ставку...

    Кстати, а пробовал ли кто-нибудь переносить в обе стороны модули одного и того же языка Component Pascal в двух реализациях BlackBox и GPCP? Тут случаем зоопарка не наблюдается?


    1. К списку модулей я бы добавил OberonCoroutines или что-то подобное.

    В отношении его необходимости на базовом уровне библиотеки есть большие сомнения.

    Базовый уровень для интерфейсной библиотеки в моем понимании -- это не то, на чем будет строиться все остальное, а то, что (гарантированно) обеспечивает переносимость в рамках Оберонов (языков, IDE и платформ). Эту библиотеку можно рассчитать для той же задачи унификации.

    2. Модули OberonConsole, OberonFiles и OberonInOut естественным образом сводятся к одному головному модулю OberonIO и нескольким модулям-плагинам (с возможностью добавления своих, естественно).

    Здесь можно поспорить. У каждого из этих подходов есть свои плюсы и минусы.

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



    № 2590   09-08-2005 07:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2587« (Руслан Богатырев)
    ___________________________
    У меня вот вопрос - как быть с зоопарком типов? C вещественными типами, например.

    Далее, касательно строк вообще и юникода в частности (потому как они мне сейчас ближе всего) - в XDS и ETH двубайтового символьного типа нет, насколько я помню.
    Или вот ситуация - в модуле OberonStrings имеют место быть процедуры перекодировки символов, и соответственно таблицы перекодировки (что в принципе логично):

    TYPE
      CharTable = POINTER TO ABSTRACT RECORD
        (t : CharTable) FromUnicode(ch : CHAR) : CHAR, NEW, ABSTRACT;
        (t : CharTable) ToUnicode(ch : CHAR) : CHAR, NEW, ABSTRACT;
      END;

    PROCEDURE FromUnicode(t : CharTable; VAR s : ARRAY OF CHAR);
    PROCEDURE ToUnicode(t : CharTable; VAR s : ARRAY OF CHAR);


    Преобразование ToUnicode можно оформить массивом из 256 позиций, а вот обратное - нет, ибо в юникоде символы одной кодовой таблицы разбросаны будь здоров. Можно было бы сделать на основе процедурных переменных, но тоже ненадёжно (об этом ниже). Никакого приемлемого переносимого решения в голову не приходит.

    По поводу процедурных типов. Возможность их применения зависит от того, собирается ли OM дальше работать над Блэкбоксом, ибо в документации они грозились процедурные типы убрать...

    -------------
    Теперь по существу :)

    1. К списку модулей я бы добавил OberonCoroutines или что-то подобное.

    2. Модули OberonConsole, OberonFiles и OberonInOut естественным образом сводятся к одному головному модулю OberonIO и нескольким модулям-плагинам (с возможностью добавления своих, естественно).

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


    № 2589   09-08-2005 07:22 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2587« (Руслан Богатырев)
    ___________________________

    При этом не должно быть дискриминации в отношении выбора пользователем парадигмы программирования (не затаскивать его принудительно в component-oriented programming). Иными словами, поддерживать три основных подхода:
    1. Структурное программирование (Oberon) c поддержкой расширяемости ПО.
    2. Объектно-ориентированное программирование (Oberon-2).
    3. Компонентное программирование (Component Pascal).


    В смысле, одновременно писать три разных (но в чем-то похожих) framework-ов?


    № 2588   09-08-2005 07:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Оберон и экспериментальное программирование

    Интересно, а кому-нибудь доводилось изучать созданный на базе Oberon-2 язык O2M (Д.А.Швец, А.И.Легалов, Красноярский ГТУ), а также соответствующую систему программирования?

    http://www.softcraft.ru/index.shtml
    http://www.softcraft.ru/ppp/o2m/cmd/index.shtml
    http://www.softcraft.ru/ppp/download.shtml#src

    Каковы впечатления?


    № 2587   09-08-2005 05:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Размышления в продолжение темы единой эталонной библиотеки для Oberon, Oberon-2 и Component Pascal.

    Если следовать лаконичному стилю Оберона, в базовом уровне должен быть заложен минимум средств, который понадобится большинству программ (не завязанных на GUI, DB, Communication и т.п.).

    При этом не должно быть дискриминации в отношении выбора пользователем парадигмы программирования (не затаскивать его принудительно в component-oriented programming). Иными словами, поддерживать три основных подхода:

    1. Структурное программирование (Oberon) c поддержкой расширяемости ПО.
    2. Объектно-ориентированное программирование (Oberon-2).
    3. Компонентное программирование (Component Pascal).

    Для каждого из указанной тройки языков в отношении операционной платформы Win32 на сегодня есть соответствующая некоммерческая система программирования:

    1. ETH (Plug-In ETH Oberon for Windows)
    2. XDS (Excelsior Native XDS)
    3. BlackBox, GPCP

    В качестве объединяющей идеи предлагается выбрать концепцию ADT (abstract data type), опирающуюся на понятие модуля, и за счет нее на базовом уровне эталонной библиотеки исключить использование методов и классов (где языки начинают отличаться).

    Если взглянуть на библиотеки ISO Modula-2 и Oakwood Oberon-2, а также вспомнить истоки самого Оберона (статья Вирта "Проектирование системы с нуля"), то видятся такие библиотечные модули.

    0. OberonSystem (системно- и языково-зависимые средства, операции над битами, а также возможно exceptions)
    1. OberonString (работа со строками, включая Unicode)
    2. OberonConsole (ввод-вывод для консольных приложений, аналог Log-окон с поддержкой клавиатурного ввода)
    3. OberonFile (файловый ввод-вывод)
    4. OberonInOut (обобщение Console и File в понятие потока ввода-вывода, stream)
    5. OberonMath32 (математические функции, SHORTREAL для CP)
    6. OberonMath64 (математические функции, REAL для CP)
    7. Oberon2D (примитивы 2D-графики)

    В качестве ADT-модулей могут быть выполнены OberonConsole, OberonFile, OberonInOut, Oberon2D. При необходимости и OberonString.

    Поскольку в Обероне по сравнению с Modula-2 произошел отказ от неквалифицирующего импорта (т.е. убрано FROM… IMPORT), то в ADT-модулях удобно фиксировать имя главного абстрактного типа -- T, т.е. использовать "объекты" типа OberonFile.T (как это активно применялось в Modula-3).

    Что касается контроля использования избыточных языковых средств (возможность миграции внутри тройки Oberon/Oberon-2/CP), то можно сделать для BlackBox (как объединяющей IDE) два верификатора (language validator) -- т.е. вырожденные front-end компиляторов Oberon и Oberon-2 без генерации кода.

    Таким образом, BlackBox может использоваться для сборки разнородных блоков (Oberon, Oberon-2, Component Pascal) и включения на максимум потенциала ООП и КОП.

    Компилятор XDS — как оптимизатор кода и как инструмент для создания real-time systems.

    ETH -- как учебная система для computer science, где возможностей языка Oberon более чем достаточно.

    Ну а семейтсво GPCP -- для тех, кто хотел бы шагать в ногу с модой и не отставать от новаций мира Java и .NET.


    № 2586   08-08-2005 09:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2583« (Trurl)
    ___________________________

    Рассматривать Компонентный Паскаль как надмножество Оберона-2 не получится. Разве что в простейших случаях. Да и без привязки к базовым библиотекам и даже к компилятору очень трудно обойтись.
    Вот, казалось бы, численные методы - область, где зависимость от среды минимальна. Но даже здесь придется иметь дело с такими частностями, как exp и Exp. Что уж говорить о строках и файлах.


    Унификация библиотек для Оберонов более чем желательна. На мой взгляд, если этого не сделать, то придется замыкаться на конкретной реализации (BlackBox) со всеми вытекающими отсюда проблемами.

    Еще в языке Modula-2 Вирт применил хороший подход, позволяющий отделить переносимые (высокоуровневые) модули от непереносимых (низкоуровневых). Достаточно было осуществлять импорт псевдомодуля SYSTEM.

    Даже в тех случаях, когда можно было напрямую использовать типы и процедуры из этого модуля (импортирование осуществлялось неявно, благо это прямая связь с компилятором и RTS), все равно для подчеркивания низкоуровневого характера модуля желательно было импортировать SYSTEM. В языке Modula-3 эта идея нашла еще большее развитие.

    Унификация библиотек -- развитие этой идеи: все, что использует только эталонную библиотеку, переносимо, остальное -- намертво завязано на конкретную среду программирования.

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

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

    Что касается языковых средств, то, вообще говоря, языки Oberon, Oberon-2 и Component Pascal различаются между собой куда меньше разных версий Turbo Pascal, Borland Pascal и Delphi.


    № 2585   Удалено модератором


    № 2584   08-08-2005 08:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2583« (Trurl)
    ___________________________


    Рассматривать Компонентный Паскаль как надмножество Оберона-2 не получится. Разве что в простейших случаях. Да и без привязки к базовым библиотекам и даже к компилятору очень трудно обойтись.

    Я, собственно, к этому и веду. Хотя бы минимальный набор библиотек стандартизировать...
    Сообщение не подписано


    № 2583   08-08-2005 07:28 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2574« (RBV)
    ___________________________
    >>>Да и прямого смысла нет привязываться к компилятору. Речь идет о привязке к языку... вот только к какому? Можно ориентироваться на Оберон-2 и рассматривать Компонентный Паскаль (грубо), как его надмножество.

    Рассматривать Компонентный Паскаль как надмножество Оберона-2 не получится. Разве что в простейших случаях. Да и без привязки к базовым библиотекам и даже к компилятору очень трудно обойтись.
    Вот, казалось бы, численные методы - область, где зависимость от среды минимальна. Но даже здесь придется иметь дело с такими частностями, как exp и Exp. Что уж говорить о строках и файлах.


    № 2582   06-08-2005 02:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    К вопросу о компиляции - добавил в подсистему Rad тулзовину, позволяющую просто скомпилировать модуль на Oberon-2.
    Правда при стыковке с модулями на Компонентном Паскале имеются нюансы (что-то про области видимости и расширения типов, сейчас не помню)


    <<<... | 2601—2592 | 2591—2582 | 2581—2572 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 195




    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

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

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования