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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

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

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

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


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

Добавить свое сообщение

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

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 2056—2047 | 2046—2037 | 2036—2027 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 422


№ 2046   21-01-2007 08:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2045« (Geniepro)
___________________________

Если Оберон не будет развиваться, то он безнадёжно устареет и потеряет актуальность...

Ради Бога, не надо развивать Оберон. Оставьте этот язык в покое! Если много нерастраченной энергии, лучше создавайте для него инфраструктуру. Или совершенствуйте тот же КП. Для него стабильность менее важна.


№ 2045   21-01-2007 07:02 Ответить на это сообщение Ответить на это сообщение с цитированием
Снегурочка пишет:

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


AVC пишет:

Бедный Оберон!
Одни от него хотят, чтобы он непременно контролировал перечислимые типы и диапазоны, другие - чтобы он, напротив, сам выводил типы...

Как было сказано в "Алисе в Стране Чудес": Что бы удержаться на месте, нужно бежать вперёд изо всех сил! А иначе неизбежно отстанешь!

Если Оберон не будет развиваться, то он безнадёжно устареет и потеряет актуальность...


№ 2044   21-01-2007 05:53 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2042« (Илья Ермаков)
___________________________

Также, мне кажется, для образования идеальна пара Оберон-Хаскель.

Очень разумная идея. И не только для задач education. Могла бы и несколько сплотить всех, кто активно участвует в обсуждении ФП и Оберона. Вместо того, чтобы попусту тратить время на бесконечные уколы, имело бы смысл заняться конструктивом.

Тем более, что уже есть полезный опыт. В Оксфордском университете, в вычислительной лаборатории (The Computing Laboratory), вотчине проф. Тони Хоара, Haskell является первым языком, с помощью которого студентам преподаются основы computer science. Вторым - Oberon-2 в OCaml-реализации.

* http://web.comlab.ox.ac.uk/oucl/prospective/ugrad/csatox/why_oxford.htm
* http://spivey.oriel.ox.ac.uk/mike/obc/


№ 2043   21-01-2007 04:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2041« (Jack Of Shadows)
___________________________

В виртовском Паскале никогда не было слова class.
А сборщика мусора не было по чисто техническим причинам (наличие вариантных записей и отсутствие расширения типа). Уже в Algol-W сборка мусора предполагалась (не знаю точно, была ли она там реализована).
Так что Оберон воспринимается как вполне логичное развитие Паскаля.
 AVC


№ 2042   21-01-2007 04:15 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2037« (Geniepro)
___________________________
Как раз такой полиморфизм - с введением базового типа - в Обероне есть. Чего нет - так это принципа "пользовательские типы не отличаются от элементарных". Написать полиморфную процедуру для типов-записей ничего не стоит. Однако сделать ее полиморфной и для записей, и для элементарных типов нельзя, как нельзя перегрузить +. На практике это и требуется нечасто.

А вот дженерики - полиморфизм без общего базового типа - как раз-таки и интересны.

Спасибо за высокое доверие :-)
Развитие КП/ББ в России действительно во многом в руках нашей команды, "Метасистем", но с нами вместе над развитием ББ работают люди из русскоязычного сообщества из самых разных концов страны. А самым старожилом в ББ, без сомнения, является Info21.

По поводу ФП и КП - я периодически размышляю над этим вопросом. Я склоняюсь к тому, что стоило бы отработать интеграцию ББ- и Хаскель-приложений, лучше всего на каком-то конкретном проекте, где найдутся эффективные точки приложения и для того, и для другого. Также, мне кажется, для образования идеальна пара Оберон-Хаскель.




№ 2041   21-01-2007 04:09 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2040« (AVC)
___________________________
Бедный паскаль. Одни хотят удалить из него слово класс. Другие - засунуть в него сбощик мусора :))


№ 2040   21-01-2007 04:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2037« (Geniepro)
___________________________

Бедный Оберон!
Одни от него хотят, чтобы он непременно контролировал перечислимые типы и диапазоны, другие - чтобы он, напротив, сам выводил типы...
 AVC


№ 2039   21-01-2007 04:06 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2036« (Geniepro)
___________________________
В неё добавлены классы типов - своего рода абстрактные классы или интерфейсы.
Не совсем верно. Функции классов типов реализовываются в отличии от абстрактных классов и интерфейсов.
Скорее это ближе к traits.


№ 2038   21-01-2007 04:06 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2036« (Geniepro)
___________________________

Да, эти механизмы потребуют изменения системы типов Оберона.

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


№ 2037   21-01-2007 03:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2030« (Geniepro)
___________________________

Мой предыдущий пример (с map) не совсем ясно показывает мою мысль.
Что бы лучше представить себе полиморфизм в Хаскелле, разберём лучше такие функции, как inc и dec:

module Test where

import Complex

inc :: (Num a) => a -> a
dec :: (Num a) => a -> a

inc x = x + 1
dec x = x - 1

main = do print (inc  1)      -- целочисленная единица
          print (inc  1.0)    -- вещественная  единица
          print (inc (1 :+ 1)) -- комплексное число 1 + 1i
{-
Результат:

2          -- целочисленная двойка
2.0        -- вещественная  двойка
2.0 :+ 1.0  -- комплексное число 2 + 1i

-}


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

Таким образом, эти функции можно использовать с любыми аргументами, типы которых являются потомками или экземплярами класса Num, будь то Int, Integer, Float, Double, да хоть Complex или пользовательские типы, включающие интерфейс класса Num, например вещественные числа с учётом погрешности расчётов...

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

Такой полиморфизм, я думаю, не отказался бы иметь ни один оберонщик...

И этот полиморфизм, имхо, нисколько не навязывает функциональный стиль, ведь он соответствует и настоящему ООП.


<<<... | 2056—2047 | 2046—2037 | 2036—2027 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 422


Добавить свое сообщение

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

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

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

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

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