Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 3656 06-04-2007 16:03 | |
Ответ на »сообщение 3652« (Geniepro)
___________________________
Все эти map, foldr, reverse, show, read, lines, unlines, Int, Integer, String, Char - всё это такая же часть языка в Хаскелле. как и INC, DEC, EVEN, ODD, CHAR, REAL, INTEGER и т.д. в Обероне.
Верно. Открываем книгу Душкина, смотрим приложение C "Описание стандартного модуля Prelude", считаем количество стандартных функций -- насчитал 176 (думаю, если и сбился со счета, то не сильно). Впечатляет.
Открываем описание языка Оберон -- 9 предопределенных функций (ABS, ODD, ...), 5 функций преобразования типов (ORD, CHR, ...), 9 процедур (INC, DEC, ...). Все.
Мда, когда я всё-таки указал квалифицирующий импорт в той своей программке, то оказалось. что большой выгоды вроде бы и нет совсем...
А какую выгоду Вы ожидали получить/увидеть? Просто интересно...
Основные функции из автозагружающегося модуля Prelude я не стал квалифицировать
Думаю, их и не надо квалифицировать. Стандарт есть стандарт. Это часть языка, которую должен знать каждый хаскелист, как таблицу умножения.
Ну что ж, посмотрим, что Руслан Богатырёв скажет - дало ли ему это хоть что-то... ;о)
Мне стало гораздо понятнее. А Вы сами разницы не видите? У меня похоже плохая привычка -- искать первым делом в чужой программе зоны, отвечающие за ввод-вывод (чтобы посмотреть точки "вброса-выброса" данных) и отсекать их (мысленно) от остального. Хотя бы даже для этого уже польза. Но Вы же сами прекрасно должны понимать, что это дает основной полезный эффект не на "игрушечном" коде в сотню строк.
№ 3655 06-04-2007 15:54 | |
Ответ на »сообщение 3652« (Geniepro)
___________________________
Все эти map, foldr, reverse, show, read, lines, unlines, Int, Integer, String, Char - всё это такая же часть языка в Хаскелле. как и INC, DEC, EVEN, ODD, CHAR, REAL, INTEGER и т.д. в Обероне.
Просто в Хаскелле принято считать, что они определены в псевдомодуле Prelude, а в Обероне принято считать, что они находятся в некоем безымянном псевдомодуле, с которым даже ограничения импорта нельзя сделать...
Насчет Хаскеля ясно.
Кажется, что-то подобное было в Турбо Паскале (если ничего не путаю, для меня дело уже давнее), там часть языка была в псевдомодуле System (не путать с обероновским :) ).
Для Оберона же это в лучшем случае метафора.
№ 3654 06-04-2007 15:45 | |
Ответ на »сообщение 3651« (Jack Of Shadows)
___________________________
Учитывая специфику модулей в хаскеле (отсутствие хранимого в них состояния) это ничего вообще не дает.
Вы никогда не задумывались над тем, что многие модули вообще не имеют никаких состояний, если они не имеют нелокальных (глобальных) переменных и экспортируют константы, типы, процедуры и функции? Я этим сказал для Вас что-то новое, сверхестественное?
Какая корреляция между заимствованием сервиса, предоставляемым конкретным модулем, и состоянием? Будьте добры, поясните свою мысль.
№ 3653 06-04-2007 15:28 | |
Ответ на »сообщение 3651« (Jack Of Shadows)
___________________________
Вот любопытно, эти шесть мест с квалифицированными именами дают что-нибудь реальное в плане повышения понятности? :о))
Учитывая специфику модулей в хаскеле (отсутствие хранимого в них состояния) это ничего вообще не дает.
Ну что ж, посмотрим, что Руслан Богатырёв скажет - дало ли ему это хоть что-то... ;о)
№ 3652 06-04-2007 15:28 | |
Ответ на »сообщение 3650« (AVC)
___________________________
Основные функции из автозагружающегося модуля Prelude я не стал квалифицировать - хотя это в принципе возможно, но совершенно не принято среди хаскеллеров. В конце концов, в Оберонах же тоже INC и DEC, CHAR и INTEGER не квалифицируют... :о)
Ну так они и не относятся к какому-либо модулю, а являются частью языка.
Сравнение понятно, но не совсем корректно, IMHO.
Почему же не корректно?
Все эти map, foldr, reverse, show, read, lines, unlines, Int, Integer, String, Char - всё это такая же часть языка в Хаскелле. как и INC, DEC, EVEN, ODD, CHAR, REAL, INTEGER и т.д. в Обероне.
Просто в Хаскелле принято считать, что они определены в псевдомодуле Prelude, а в Обероне принято считать, что они находятся в некоем безымянном псевдомодуле, с которым даже ограничения импорта нельзя сделать...
№ 3651 06-04-2007 15:17 | |
Ответ на »сообщение 3649« (Geniepro)
___________________________
Вот любопытно, эти шесть мест с квалифицированными именами дают что-нибудь реальное в плане повышения понятности? :о))
Учитывая специфику модулей в хаскеле (отсутствие хранимого в них состояния) это ничего вообще не дает.
№ 3650 06-04-2007 15:06 | |
Ответ на »сообщение 3649« (Geniepro)
___________________________
Основные функции из автозагружающегося модуля Prelude я не стал квалифицировать - хотя это в принципе возможно, но совершенно не принято среди хаскеллеров. В конце концов, в Оберонах же тоже INC и DEC, CHAR и INTEGER не квалифицируют... :о)
Ну так они и не относятся к какому-либо модулю, а являются частью языка.
Сравнение понятно, но не совсем корректно, IMHO.
№ 3649 06-04-2007 14:58 | |
Ответ на »сообщение 3646« (Jack Of Shadows)
___________________________
В какой-то среде обязательный квалифицирующий импорт может важен, может полезен. В какой-то другой среде - неудобен и незначителен.
Мда, когда я всё-таки указал квалифицирующий импорт в той своей программке, то оказалось. что большой выгоды вроде бы и нет совсем...
Из модулей IO и List я импортировал в сумме всего 4 функции и 1 конструктор типа (в принципе функция, но в данном случае всего лишь константа), и использовал их в пяти строчках из 60 с лишним. List.nub два раза в одной функции (2 строки) и функции из IO в главной функции main в трёх строчках - весь ввод-вывод...
Основные функции из автозагружающегося модуля Prelude я не стал квалифицировать - хотя это в принципе возможно, но совершенно не принято среди хаскеллеров. В конце концов, в Оберонах же тоже INC и DEC, CHAR и INTEGER не квалифицируют... :о)
Вот любопытно, эти шесть мест с квалифицированными именами дают что-нибудь реальное в плане повышения понятности? :о))
№ 3648 06-04-2007 14:28 | |
Ответ на »сообщение 3647« (AVC)
___________________________
А разве кто то говорил что он не отличается ?
Мы говорили о том что ближе и что дальше, а не что отличается и что нет.
В том сообщении на которое вы намекаете, я сказал что оберон является ПРОДОЛЖЕНИЕМ императивного мейнстрима, а не его КОПИЕЙ. То есть отличается конечно.
Но поскольку является продолжением, то основная масса программистов будут себя в нем чувствовать совершенно комфортно. Их только надо втащить в оберон. Но это уже ваши проблемы.
Мне никого втаскивать в ФП не нужно, просто потому что я понимаю, что это невозможно в принципе.
А вот вам как идейным продолжателям и улучшателям мейнстрим программирования - сам бог велел.
Дельфисты - это ваша паства, не моя.
№ 3647 06-04-2007 14:22 | |
Ответ на »сообщение 3646« (Jack Of Shadows)
___________________________
Я так понимаю, это косвенное признание того, что Оберон все же отличается от мейнстрима (хотя бы в лице Delphi)? :)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|