Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 3846 13-04-2007 01:53 | |
Ответ на »сообщение 3844« (Geniepro)
___________________________
Это значит, что Вы можете в модуле с именем Int определить тип данных или класс типов с именем Int и конструктором Int - они находятся в разных пространствах имён и не пересекаются.
Любимая фича всех лисперов, это тех которые не scheme :))
Ведь так приятно писать (и читать) (list list) вместо (list lst)
№ 3845 13-04-2007 01:51 | |
Ответ на »сообщение 3842« (Stargazer)
___________________________
Э-э, там есть квалифицирующий импорт, поэтому костылей не надо. Плюс по названию модуля легко вытаскивается его интерфейс. Очень удобно.
А как поможет квалифицирующий импорт в приведенном примере ? Вы помните название функции, да и то не уверены в точной его записи (то ли WriteInt, то ли IntWrite)
C apropos лехко.
(apropos "write") даст вам список всех функций, полностью квалифицированных заметьте, в имени которых встречется последовательность символов "write"
№ 3844 13-04-2007 01:49 | |
Ответ на »сообщение 3828« (Руслан Богатырев)
___________________________
These are the only constraints; for example, Int may simultaneously be the name of a module, class, and constructor within a single scope.
Кстати, что бы это значило?
Я об этом упомянул в сообщении 3822 :
Все эти имена (модулей, классов/типов, конструкторов типов) находятся в разных пространствах имён и не пересекаются, а потому могут совместно использоваться. Например:
module Tree (Tree(Leaf, Tree)) where
data Tree a = Leaf a | Tree (Tree a) (Tree a)
deriving (Eq, Show)
где имеются модуль Tree, в котором определён АТД Tree, у которого имеется два конструктора - Leaf и Tree.
Это значит, что Вы можете в модуле с именем Int определить тип данных или класс типов с именем Int и конструктором Int - они находятся в разных пространствах имён и не пересекаются.
И зачем?
Ну как сказать? Для удобства... Опеределяете модуль Tree, логично в нём разместить тип данных Tree, а один из конструкторов этого типа назвать тоже Tree - меньше лишних имён, меньше головной боли.
Хотя с непривычки кажется странным для нехаскеллеров, конечно... ;о)
№ 3843 13-04-2007 01:48 | |
Ответ на »сообщение 3841« (Stargazer)
___________________________
Jack, что вы говорите. На все свои процедуры хелп не напишешь и поиск не сделаешь.
Ну если о недокументированных библиотеках говорить, коих согласен пруд пруди, то я уже упоминал apropos.
Программная среда просто обязана иметь мощные средства поиска.
№ 3842 13-04-2007 01:46 | |
Ответ на »сообщение 3840« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3839« (Димыч)
___________________________
Удивлен что в обероне, который тоже вроде является языком-средой, такой возможности нет.
Э-э, там есть квалифицирующий импорт, поэтому костылей не надо. Плюс по названию модуля легко вытаскивается его интерфейс. Очень удобно.
№ 3841 13-04-2007 01:44 | |
Ответ на »сообщение 3840« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3839« (Димыч)
___________________________
а из какого модуля брать процедуру. Например, я хорошо помню, что процедура называется WriteInt, но хоть убей не помню, из какого модуля она берется.
Не понял, разве help не решает эту проблему ? Там есть поиск.
Далее в языках средах к коим относятся Smalltalk и Lisp, есть возможность поиска обьекта по части его названия.
Скажем в лиспе это функция apropos.
Удивлен что в обероне, который тоже вроде является языком-средой, такой возможности нет.
Jack, что вы говорите. На все свои процедуры хелп не напишешь и поиск не сделаешь. Гораздо проще явно указать, откуда процедура.
Кстати, квалификация позволяет избежать ошибок при дублировании. Человеческий фактор, знаете ли. Старый рабочий модуль, отлаженный и забытый интерфейс. Пишется новый модуль, в интерфейсе которого объявлена процедура (переменная) с тем же именем, что и в старом.
В секции импорта объявляем оба модуля - и новый, и старый. Компилятор не против.
Оп-ля, приехали. Семантика слиплась, две разных сущности названы одинаково. Главное, чтоб никто не заметил, тогда эффект получается красивый.
№ 3840 13-04-2007 01:08 | |
Ответ на »сообщение 3839« (Димыч)
___________________________
а из какого модуля брать процедуру. Например, я хорошо помню, что процедура называется WriteInt, но хоть убей не помню, из какого модуля она берется.
Не понял, разве help не решает эту проблему ? Там есть поиск.
Далее в языках средах к коим относятся Smalltalk и Lisp, есть возможность поиска обьекта по части его названия.
Скажем в лиспе это функция apropos.
Удивлен что в обероне, который тоже вроде является языком-средой, такой возможности нет.
№ 3839 13-04-2007 00:30 | |
Ответ на »сообщение 3810« (Руслан Богатырев)
___________________________
Ответ на »сообщение 3808« (Владимир Лось)
___________________________
Да и, потом, когда-то и работать надо... :о)
Делу -- время, потехе -- час. :)
Если смотреть на дискуссию, как на потеху, то хотелось бы услышать мнение по поводу поднятых/рассмотренных тем (мне монологи нравятся все меньше):
1. Верификатор в Обероне/КП
2. Позиционирование Оберона и КП
3. Передача параметров
4. Обязательный квалифицирующий импорт
Попробую выразить свои дилетантские мысли.
Оберон может (должен) позиционироваться именно как средство модульного программирования, как средство надежного программирования. Действительно, номенклатура слабовата, чтобы сколько-нибудь конкурировать с Delphi. В системных вопросах с C конкурировать сложно, поскольку наработан громадный опыт его использования, да и академическая среда все больше ориентируется на С и иже с ним.
И тем не менее, Оберон дает "глоток свежего воздуха" - возможность очень четкого деления системы на составные части, которые никак не смешиваются; квалифицирующий импорт (сначала отталкивает, а затем появляется ощущение прозрачности всей системы и "сшитости" отдельных частей); высокоскоростная компиляция (это к модульности имеет отношение маленькое, но это большой плюс языка).
Встает во весь рост проблема нехватки знаний по проектированию и опыта декомпозиции. Наблюдая за собой и за другими, могу сказать, что знакомство с Обероном надо сопровождать знакомством с работами Parnas'a, МакКоннела и прочими работами именно по инженерному подходу к разработке программ. Сейчас же наблюдается каша в головах, поэтому отчасти и трудно идет продвижение Оберона.
Мощь и сила языка Оберон (и КП) именно в том, что это язык модульного программирования, и это его основное конкурентное преимущество.
По поводу квалифицирующего импорта.
Из тех немногих работ, что я сделал на Обероне (и Модуле), про квалифицирующий импорт могу сказать, что гораздо важнее не разобраться, что импортировано текущим модулем и где (это вполне можно сделать на манер поиска в FireFox - "подсветить все вхождения"), а из какого модуля брать процедуру. Например, я хорошо помню, что процедура называется WriteInt, но хоть убей не помню, из какого модуля она берется. И было бы неплохо, если бы библиотека была снабжена некоторым средством (комментариями), где что находится. Хотел даже написать процедуру поиска по *.def (XDS), но руки не дошли.
Верификатор.
На мой взгляд, предложенная вами схема в сообщении »сообщение 3788« с интерфейсной частью, это следствие того, что в Обероне при создании модуля я должен указывать то, что хочу открыть, а не (в отличие от Eiffel) то, что должен закрыть. Было бы неплохо, если бы было не так, как сейчас "Все, что не разрешено, запрещено (невидимо вне модуля)", а наоборот, "все, что не запрещено явно, разрешено". Тогда бы, фактически, все объявления в схеме interface-module совпадали бы. Различия были бы как раз в невидимой части.
Что до генерации модуля из интерфейса, так это вообще дело среды готовить каркасы и вставлять заготовки процедур. Незнаю как другие, но практически ни в какой среде я этим не пользовался - неудобно. Исключение - клавиши Ctrl+Shift+C в Delphi.
С уважением,
№ 3838 13-04-2007 00:02 | |
Ответ на »сообщение 3825« (Руслан Богатырев)
___________________________
>>>Как я понял из описания The Haskell 98 Report (Revised), это всего лишь рекомендации.
Это не рекомендации, а синтаксис языка.
№ 3837 12-04-2007 15:50 | |
Ответ на »сообщение 3836« (Руслан Богатырев)
___________________________
Эмоции понятны, но давайте будем хоть немного уважать друг друга. Пользы для дела будет больше.
Exactly my point.
лучше не будем отвлекаться на эти глупости,
Да я бы не отвлекался если бы эти "глупости" не приводили к периодическому закрытию обероновских тем :))
Мне жаль что вы Руслан не придаете этому должного значения. Это не глупости.
Если бы ведущие этой ветки (это кстати вы) обращали на эти глупости свое внимание, то этого не пришлось бы делать остальным принимающим участие в дискуссии.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|