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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

Ivan

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

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

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


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


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



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


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

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


    № 2601   10-08-2005 08:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2598« (Сергей Губанов)
    ___________________________

    Позиция понятна. Не особо конструктивно, зато прямо.


    № 2600   10-08-2005 08:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2599« (Сергей Губанов)
    ___________________________

    Речь идет о возможности ослабления контроля языка на уровне передачи параметров. Есть ли средства-заменители ARRAY OF BYTE в Component Pascal?


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

    ...совместимость всех типов с ARRAY OF BYTE на уровне формальных параметров?

    Это невозможно из-за различного порядка следования байтов в представлении чисел на машинах с разными архитектурами little-endian и big-endian.


    № 2598   10-08-2005 07:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2596« (Иван Горячев)
    ___________________________

    И вообще, чаво остальные молчат?

    А потому что:
    1) Единый фреймворк для Оберона, Оберона-2 и Компонентного Паскаля невозможен.
    2) Математические библиотеки пишут/переписывают только те кому они самим нужны.

    Короче, ерунда это всё...


    № 2597   10-08-2005 07:39 Ответить на это сообщение Ответить на это сообщение с цитированием
    Информации о предпочтениях пользователей, имеющих возможность выбирать разные Оберон-языки и IDE, маловато.

    Но кое-что появляется. Вот полезный срез (на лето 2005 г.) по Вологодскому педагогическому университету от С.Свердлова: http://www.inr.ac.ru/~info21/texts/2005-06-27-MGU/welcome.html


    № 2596   10-08-2005 07:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Вопрос несоответствия типов решается таким модулем:

    MODULE OberonBase;
    TYPE
      Boolean* = BOOLEAN;
      Set* = SET;
      Byte* = BYTE или SYSTEM.BYTE;
      Shortint* = 2 байта;
      Integer* = 4 байта;
      Longint* = 8 байт; (*если компилятор не поддерживает = Integer*)
      Hugeint* = 16 байт; (*а вот хочу я на своём Athlon-64 иметь 128-битные целые! но пока нет = Integer*)
      Shortreal* = 4 байта;
      Real* = 8 байт;
      Longreal* = 10 байт; (*не понимаю, зачем упорно игнорировать Интеловский Extended. но пока = Real*)
      Shortchar* = 1 байт; (* в КП = SHORTCHAR, в остальных = CHAR*)
      Char* = 2 байта; (* в КП = CHAR, в остальных = Shortint*)
      Longchar* = Integer; (*UCS-4*);
    END OberonBase.


    и тотальным использованием в переносимой части программы этих типов. Из минусов такого подхода - тяжело работать со встроенными процедурами. Правда их переносимые аналоги можно поместить в этот же модуль.

    А по поводу переносимости - ну это очевидно, что базой будет служить простой Оберон(-1), потому как основные расхождения всех языков как раз в области ООП.

    Но мы несколько с разных позиций подходим к задаче. Я хочу, чтобы модуль, реализующий некоторый алгоритм, без переделок работал на всех трёх (а лучше и большем числе) платформах. И модуль Threads я толкаю потому, что множество чисто вычислительных алгоритмов прекрасно работают в многозадачном режиме, и я хочу переносимости этих алгоритмов.

    Кстати, XDS отнюдь не является хорошим выбором. Пусть меня поправят старшие товарищи, но у него кажись вообще нет 8-байтного целого и двубайтовое целое реализуется только через SYSTEM.

    И вообще, чаво остальные молчат?

    PS. А Блэкбокс ARRAY OF BYTE не пропускает :(


    № 2595   10-08-2005 06:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Несколько уточнений к вопросу о переносимости внутри Оберонов.

    Прежде чем строить эталонную библиотеку, стоит понять, зачем вообще нужна такая переносимость.

    На мой взгляд, имеет смысл преимущественно поддерживать переносимость "снизу вверх" (т.е. от Oberon к Oberon-2 к Component Pascal). Это связано не только с тем, что языки построены по принципу расширения предшественника (что заведомо осложняет обратную совместимость), но и сами ориентированы на несколько разные сферы программирования.

    Если требуется реализовать/отладить алгоритм из области численных методов, работы с динамическими структурами (списками, деревьями, графами), нет большого смысла сразу окунаться в Component Pascal. Для большинства задач computer science достаточен Oberon и соответственно реализация ETH, где удобно писать и экспериментировать как раз-таки без отладчика.

    Если нужно обобщение алгоритмов (задействование ООП), написание автономных несложных программ, устойчивая работа с ОС на уровне системных вызовов, использование внешних библиотек на других языках, перенос на другие платформы через C/C++, эффективная реализация (оптимальный объектный код), то подходит Oberon-2 в исполнении XDS.

    Если требуется строить расширяемую систему с использованием компонентно-ориентированного программирования, подходов программной инженерии, иметь прямой выход на современные наработки для Win32, .NET и Java Platform, то нужен Component Pascal в реализациях BlackBox и GPCP. Иными словами, имеет смысл задействовать новые возможности Component Pascal, когда требуется опустить мысль/алгоритм с небес на грешную землю -- в основном для компоновки и обвязки наработанных алгоритмов (насаживание их на каркас и вращивание в единую компонентную среду).

    В своей работе "Научные основы доказательного программирования" А.П. Ершов выделял три вида программирования:

    1) синтезирующее (автоматическое, автоматизированное или ручное манипулирование знанием о задаче с синтезом соответствующей программы);
    2) сборочное (построение программы из уже существующих и корректных фрагментов);
    3) конкретизирующее (построение специализированных программ из универсальных заготовок).

    Oberon (на уровне АТД) и Oberon-2 (на уровне ООП) больше подходят для синтезирующего программирования и в определенной мере для конкретизирующего, а вот Component Pascal –- преимущественно для сборочного и конкретизирующего программирования.

    Не вижу большого смысла выстраивать сложную библиотеку там, где нужны будут преимущественно средства консольного ввода-вывода.

    Тем, кто выбирает Oberon-2 для реализации своих программ масштаба shareware унификация вряд ли нужна. Унифицированную поддержку современного UI (а тем паче поддержку threads) выстраивать там смысла тоже нет. Кому требуется, поэксплуатирует внешние библиотеки поддержки UI (и другие средства).

    Окончательную привязку средних и больших развивающихся проектов к программной архитектуре и "агрессивному" внешнему миру надо делать все же в Component Pascal, сохраняя возможность плавной миграции между BlackBox и GPCP.

    Стоит упомянуть еще две области (специализации языков), которые Component Pascal затронуть не может (по крайней мере, в нынешней реализации), а вот Oberon и Oberon-2 –- вполне. Это клиентские интернет-приложения (изощренный тонкий клиент, Juice-Oberon) и приложения для мобильных устройств (сфера Java 2 Micro Edition) –- "карманный" компилятор JOB Сергея Свердлова (Oberon-2) с оптимизатором JVM-кода.


    № 2594   10-08-2005 06:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2593« (Иван Горячев)
    ___________________________

    К вопросу о базовых типах для Oberon, Oberon-2 и Component Pascal.

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

    Для изучения брал эталонные спецификации:

    1. Oberon (Niklaus Wirth). "Oberon Language Report" (October1990)
    2. Oberon-2 (Hanspeter Moessenboeck). "The Programming Language Oberon-2" (March 1995)
    3. Component Pascal (Cuno Pfister). "Component Pascal Language Report" (March 2001)

    А также уточняющие документы:

    1. "Differences between Oberon and Oberon-2". H.Moessenboeck (July 1993)
    2. "The Oakwood Guidelines for Oberon-2 Compiler Developers" (October 1995)
    3. "What's New in Component Pascal". C.Pfister (March 2001)

    Что в результате имеем: в спецификациях языков Oberon и Oberon-2 размеры базовых типов не регламентируются (для CP это указано). Это означает, что смотреть надо на конкретные реализации -– ETH (для Oberon) и XDS (для Oberon-2). XDS, что радует, опирается на конкретный регламентирующий документ Oakwood Guidelines, из которого некоторые детали проясняются.

    Базовые типы для Oberon и Oberon-2 различий не имеют (не уверен в отношении SET для Oberon, ибо нет под рукой ETH-компилятора, но думаю, что все-таки 4 байта, как и в Oberon-2). Таким образом, можно сравнивать в этом аспекте Oakwood с CP Report.

    1. SET и BOOLEAN расхождений не имеют.

    2. Тип BYTE есть во всех трех языках (в Oberon и Oberon-2 размещен в псевдомодуле SYSTEM). Кстати, а поддерживает ли Component Pascal (как Oberon и Oberon-2) совместимость всех типов с ARRAY OF BYTE на уровне формальных параметров?

    3. CHAR. Разница в названиях типов. Простое переименование CHAR (для Oberon/Oberon-2) в SHORTCHAR (для CP) частично решает проблему. Использование UTF-16 для CHAR в CP -- отдельная проблема.

    4. INTEGER. Разница в названиях типов. При переходе к CP решается аналогичным переименованием INTEGER в SHORTINT. Но это требуется только в случае специфических вычислений, когда строго нужен диапазон -32768..+32767, а не -2147483648..+2147483647. Вывод: по возможности надо работать только в INTEGER во всех языках, не привязываясь к внутреннему представлению.

    5. REAL. Аналогично пункту 4. REAL --> SHORTREAL. В основе надо использовать преимущественно REAL.

    Совместимость, преобразование типов, операции над ними (включая предопределенные процедуры) -- предмет отдельного исследования.


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

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

    Для XDS сейчас не дам, а так размеры основных типов:

                Bluebottle  BlackBox
    BOOLEAN        1          1
    SHORTCHAR      -          1
    CHAR            1          2
    SET            4          4
    BYTE            -          1
    SHORTINT        1          2
    INTEGER        2          4
    LONGINT        4          8
    HUGEINT        8          -
    SHORTREAL      -          4
    REAL            4          8
    LONGREAL        8          -



    В ETH Oberon типы как в Bluebottle, только HUGEINT нет. Вот и зоопарк - всего два совпадающих типа (BOOLEAN и SET)!

    Насчет Unicode: а что хотелось бы поддерживать -- UTF-8, UTF-16, UTF-32 и почему?
    Так как в Блэкбоксе CHAR двухбайтовый, то за основу хотелось бы взять UTF-16. Причём для скорости и простоты отрезать все символы, не влезающие в диапазон CHAR. Но конечно оставить и полную поддержку (Хотя иероглифический кусок под названием Hangul желания реализовывать нет - там одни таблицы в зипе больше 6 Мб). Кстати: в один модуль реализацию юникода укладывать неразумно: лучше несколько специализированных.


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

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

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

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


    Ну как мне видится.

    Библиотека должна обеспечивать относительно лёгкую (а в идеале - полную) переносимость в нескольких областях:

    1. "Расчётная" часть - алгоритмы, не взаимодействующие с внешним миром и составляющие суть программы.
        - математические процедуры
        - строковые процедуры (без работы с файлами)
        - поддержка многозадачности
        - работа с типами, памятью, битами и пр.
        - элементарные структуры данных
    2. Коммуникационная часть - обеспечивает поступление данных "расчётной" части. Работа с файлами, сокетами, консольный ввод/вывод
        - ввод/вывод в файлы, консоль, куда-нибудь ещё
    3. Интерфейсная часть - всё, что относится непосредственно к работе с пользователем.
        - двумерная графика
        - OpenGL
        - сообщения и события

    Из первой части следуют модули
      OberonMath
      OberonMathL  - стандартные "дубовые" процедуры, может ещё какие дополнительные
      OberonComplex - дабы каждый не занимался изобретательством велосипеда
      OberonThreads - поддержка параллельных вычислений
      OberonStrings - работа со строками. Можно разбить на несколько модулей со своей специализацией (даже нужно, потому как юникод - штука большая, на каждую задачу свои немаленькие таблицы)
      OberonTypes - работа с метаинформацией, биты, etc.
      OberonADT - списки, деревья
      И прочие модули. Добавляются, если реализация каких-либо алгоритмов постоянно воспроизводится в разных сторонних библиотеках.

    Из второй части -
      OberonIO - абстрактный интерфейс ввода-вывода. К нему прилагаются модули реализации для консоли, файлов, сетевого доступа, доступа к архивам, etc.
      OberonFormatIO - интерфейс структурированного ввода-вывода средствами OberonIO

    Из третьей -
      Oberon2D
      Oberon3D
      На счёт возможности реализации третьей части библиотеки вообще и её состава в частности у меня большие сомнения


    № 2592   09-08-2005 10:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2591« (Руслан Богатырев)
    ___________________________
    >>> Кстати, а пробовал ли кто-нибудь переносить в обе стороны модули одного и того же языка Component Pascal в двух реализациях BlackBox и GPCP? Тут случаем зоопарка не наблюдается?

    Наблюдается. Некоторые расширения языка можно просто игнорировать, но вот модуль OberonString в GPCP будет называться Oberon_String.


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




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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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