Ответ на »сообщение 3480« (Булат Зиганшин)
___________________________

не совсем так. процедуру, имеющую побочные эффекты, можно считать чистой функцией

Отвечу Вашими же словами: "можно" не означает "нужно".

Для полноты фона в отношении мнимой чистоты ФП я приведу лишь несколько выдержек из Ваших недавних сообщений в соседней ветке по ФП:
* #2194: функция - это описание зависимости выходных данных от входных. а в эрланге "функции" - это набор операций, которые должны быть выполнены в определённом порядке, и результат последней из них - это значение функции в целом. это чисто императивный подход
* #2159: у меня в программе половина состояния - в глобальных переменных, половина - в больщой структуре, передаваемой во множество процедур. это дилемма, которая встаёт в любом другом языке - с глобалами проще работать, но невозможно их использовать в мультредовой системе.

Для чистоты производства интеллектуальных вещей нужны:
1. чистые руки
2. чистые инструменты
3. чистые комплектующие
4. чистое помещение
5. чистые помыслы

:) Этого добиться в реальной жизни трудновато. Вот и приходится опускаться с небес на землю.

Насчет местечковости -- упрек не по адресу. В отличие от других сторонников ФП я за ИП держаться до победного никогда не буду. Моя цель -- выснение плюсов и минусов, а не попытка вытащить тот же Оберон на горбу "славы ФП". Я не утопист. Уж если и вытаскивать на чьем-то горбу, то уж никак не на ФП. Не поленитесь посмотреть многомегабайтную Си-реализацию системы поддержки (run-time) уже упоминавшегося здесь свехнадежного Erlang. Лично мне многое стало понятно после изучения этого фундамента.

Ответ на »сообщение 3457« (Руслан Богатырев)
___________________________

Ответ на »сообщение 3442« (Булат Зиганшин)
___________________________

кстати, вам возможно будет интересно http://rsdn.ru/Forum/Message.aspx?mid=2339757&only=1 где я анализирую причину победы в 80-х годах C/C++ как наиболее популярного языка прграммирования

в 80-х было три конкурирующих языка процедурного программирования — С, паскаль, модула-2. для прикладного программирования наилучшим, имхо, была модула.

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

На самом деле Паскаль Виртом создавался с прицелом совсем не на образование (это приятное следствие), а  на другую область, где он долгое время был вне конкуренции -- на разработку трансляторов (как компиляторов, так и интерпретаторов). При этом Паскаль опережал Си в классе мэйнфреймов и на микропроцессорах, взлетев на волне ПК-революции на крыльях сначала UCSD Pascal, а затем и передранного с него Turbo Pascal. Взлетел не столько благодаря своему технологическому совершенству (по меркам того времени), сколько из-за неуемной энергии многих расторопных американцев сделать на нем деньги (что и было сделано). А Си господствовал сначала в классе микрокомпьютеров (епархии DEC), где и появился на свет. Лишь потом он распространил свое влияние (во многом через интерес к UNIX) на уйму платформ, а вслед за этим и в сферу прикладного программирования и образования.

Что касается Модулы-2, то у нее был более популярный и могущественный конкурент в лице Ады. Модула-2 успела рвануть в сфере телекоммуникаций (на какой-то момент став там стандартом де-факто) и в области разработки встроенных систем (то, что оставалось от всепожирающей Ады). Для Ады долго было проблемой попасть на ПК, но когда проблема разрешилась, на фоне ISO-стандартизации Модулы-2 в период покорения "Нового Света" в лице ООП виртовская Модула-2 была по сути похоронена.

в области ООП были представлены Эйфель, С++ и Objective C.

Эйфель (1986) тогда знал сам автор и пара его коллег. ООП в научном мире был известен по Симуле-67. А в мире разработчиков ООП известно по раскрутке Smalltalk (1972-1980), на которую решились выходцы из Xerox PARC, глядя на наплевательское отношение компании Xerox и на миграцию ценнейших кадров в Microsoft, Apple, а затем в NeXT. Система Smalltalk-72 претерпела несколько эволюций вплоть до самой известной — Smalltalk-80 и после ряда публикаций (прежде всего, в BYTE) стала восприниматься не просто как игрушка с пользовательским интерфейсом, а как самостоятельное направление в конструировании программ разного уровня сложности. Реальный старт ООП в массовом сознании состоялся с выходом C++ (1983; C with Classes -- 1980), Objective C (1984) и Object Pascal (1985, версии Apple, а не Borland с тем же названием годы спустя!). Про историю C++ можно посмотреть, например, в одной из моих статей: http://www.osp.ru/pcworld/2003/01/164806/
Но с момента ее написания и публикации много воды утекло и для меня много новой информации появилось. Если вкратце: язык C++ было выгодно раскручивать на волне новой панацеи -- ООП. Главным мотором, вовремя подгоношившимся и сумевшим быстро сократить здесь отставание от других и возглавить "пелетон", был Microsoft. Без этого C++ не был бы на той вершине, на которую его вознесли сильные мира сего. Это важно понимать.


прошу пощения, Руслан, но я говорю не понаслышке. во сторой половине 80-х было по 5-10 компиляторов си, паскаля и модулы-2. ада и другие языки не были так хорошо представлены. у С был лишь небольшой перевес в популярности; я говорю только о прикладном программировании, хотя в те годы ограниченных ресурсов ПК и слабооптимизирующих компиляторов прикладжное программирвование было более низкоурвневым, чем сейчас

популярность C++ предопределил выход Turbo C++ в 90-м году, если до этого у другх языков какие-то шансы были, то появление столь мощной среды и библиотек для С++ окончательно похоронило другие варианты :)  впрочем, в next и сейчас macos успещшно используется objC - как-рах таки язык компонентного программирования с динамичсеким связыванием, выбранный именно за эти черты

интерепретируемые же языки вызвали интерес к теме ООП, но никак не претендовали на использование прикладными программистами ввиду своей низкой скорости. ещё раз подчеркну - даже сейчас многие программисты считают, что интерпетируемые языки слишком медленны для их порграмм, тогда же это было общепринятая точка зрения. симула-67 породила смолток, но сама в 80-х годах как практический инструмент не воспринималась и никем не предлагалась. насчёт эйфеля очень советую - посмотрите http://www.haskell.org/bz/bmefcpp

MS реализовала C++ где-то только в 93-м, когда он уже не нуждался в полпуляризации. а вот в конце 80-х была некоторое время такая эпоха, когда все уже хотели ООП, но реально применимых инструментов ещё не было - тормозной и неудобный cfront не в счёт. затем пошёл zortech, turbo...

главная идея того постинга - в том, что C и C++ прошли именно своей связкой. если бы такая же связка была вместо этого скажем для паскаля+эйфеля - то весьма вероятно, что победили бы они

Ответ на »сообщение 3478«
С 9 по 10 июня 2007 г. в Сан-Диего (США) будет проходить 3-я Международная конференция по истории языков программирования (History of Programming Language Conference, HOPL-III). На ней с докладом "История языков Модула-2 и Оберон" выступит Никлаус Вирт. Будет крайне интересно узнать, каковы нынешние оценки Вирта в отношении разработок Модулы-2 и Оберона./Quote]

Там еще и Страустуб будет выступать, сразу после Вирта (и как ему не стыдно?!).
А также истории Erlang'а и Haskell'а.

http://research.ihost.com/hopl

Ответ на »сообщение 3471« (Антон)
___________________________

А ещё не пойму, о каком таком менеджере памяти идёт речь, что его можно заменить. Если я правильно понял, в обероне есть сборка мусора, а значит, управление памятью не отдаётся на откуп любым библиотекам, которые этого захотят, а встроено в рантайм. В общем, то ли я чего-то не понял, то ли вы не договариваете.
Не договариваю :-)
В ББ в виде от Оминк менеджер памяти не заменить - он вшит в ядро. А вот загрузчик модулей подменяется/расширяется очень легко, он соединяется с ядром через разъем.
Это пример уже из сферы своих экспериментов по разрезанию ядра ББ на отдельные модули - переход к "микроядерной", так сказать, архитектуре. Казалось бы - что там делить, и так ядро всего около 2 тыс. строк? А оказалось, что технология разъемов позволяет вынести различные "сектора ответственности" в отдельные модули их реализации. Они, правда, не загружаются динамически, а линкуются статически в EXE, но разъемы все равно соединяются динамически при инициализации. Итог - ядро предоставляет минимум сервисов по тегам типов и метаданным, про реализацию всего остального и слыхом не слыхивает. В результате ядро не содержит платформенно-зависимого кода вообще, он вынесен в "боковые" модули, которые никем не импортируются. При линковке пускача ББ можно легко выбрать конкретную реализацию тех или иных ядерных сервисов - просто указав имя требуемого модуля с этой реализацией.

А про замену "на горячую" - технически это тоже можно реализовать, но с менеджером памяти пользы мало... А вот для других сервисов может быть очень полезно. Мы ранее в этой ветке с Русланом уже обсуждали проблему динамической перезагрузки модулей и ее решение, которое годится для самых общих и плотно-связанных случаев - через протокол из нескольких шагов: экстернализации состояния модуля A1 в фиксированный формат, затем ее выгрузке, загрузке A2, интернализации его состояния из сохранненого формата, а затем - проходу по памяти, изъятию экземпляров объектов типов A1, созданию соотв. экземпляров типов A2 и подмене указателей.
Я назвал этой механизм "отзыв-замена", т.е. старые объекты отзываются и подменяются на новые. Для всех клиентов подмена совершенно прозрачна. Главное, чтобы A1 и A2 "договорились" о корректной "сдаче всех дел".

Ответ на »сообщение 3479« (Geniepro)
___________________________

Вообще-то я имел в виду многократное присваивание разных значений одной переменной (multiple assignment) в противовес однократному (single assignment).
Представляете, насколько нагляднее текст программы, в которой все присваивания однократны! :о)) referencial transparency во всей красе!

За все надо платить. Императивное программирование спокойно может использовать достоинства ФП-подхода, что касается ФП, то для "императивщины" там приходится стоять на ушах. Думаю, давно уже многие поняли, что однократное присваивание и композиция функций (возвращающих не только значения, но и другие функции) -- краеугольный камень ФП-подхода. Однократное присваивание (как и автопилот) повышает надежность. В императивном программировании single assignment (SA) давно взяли на вооружение разработчики оптимизирующих компиляторов. То есть если в ФП SA находится на поверхности, а императив -- глубоко в шахтах (состояния, порядок исполнения и т.п.), то в ИП -- наоборот.

Рекомендую в этом отношении обратить внимание на работы Микаэля Франца (того самого, кто работал в команде Вирта, реализовывал Oberon System для Mac и защищал диссертацию по кодогенерации на лету на основе slim binaries). Уехав в Америку, он создал свою исследовательскую группу, которая финансируется по линии Минобороны США и Научного фонда США, доводя до ума столь денежно-конъюнктурную Java. Мобильный Java-код, реализация надежности в Java-машине и дальнейшее развитие идей проекта Oberon в среде Java -- вот его направление работ.

Приведу выдержку из одной из его работ по SA (J. von Ronne, N. Wang, and M. Franz “Interpreting Programs in Static Single Assignment Form”, Proceedings of the ACM SIGPLAN 2004 Workshop on Interpreters, Virtual Machines and Emulators (IVME’04), Washington, D.C., pp. 23-30; June 2004.). Ее текст в открытом виде недоступен.

The approach taken with SafeTSA is radically different from Java's stack-based virtual machine. The SafeTSA representation is a genuine static single assignment variant in that it differentiates not between variables of the original program, but only between unique values of these variables. SafeTSA contains no explicit assignments to local and temporary variables, but encodes the equivalent information in phi-instructions that model dataflow. Unlike straightforward SSA representations, however, SafeTSA provides intrinsic and tamper-proof referential integrity as a wellformedness property of the encoding itself. Another key idea of SafeTSA is "type separation": values of different types are kept separate in such a manner that even a hand-crafted malicious program cannot undermine type safety and concomitant memory integrity. Interestingly enough, type separation also enables the elimination of type and range checks on the code producer's side in a manner that cannot be falsified. <...>
We have been building a system consisting of a compiler that takes Java source flies and translates them to the SafeTSA representation, and a dynamic class loader that takes SafeTSA code distribution units and executes them using on-the-fly code generation. Currently our compiler can process programs written in
the Java language and produce SafeTSA intermediate code. Work is progressing on JIT compilers targeting the SPARC and Intel platforms, and we are confident that our approach will yield a competitive runtime system. Our front-end is
based on the Pizza compiler. The front-end of the compiler takes as input either Java classes or packages in source form and for each class in the input, produces a file containing a compressed version of the SafeTSA representation of that class. The transformation of a Java class to its SafeTSA representation is performed in three main steps. After successful syntactic and semantic analysis, the program is transformed into a Unified Abstract Syntax Tree (UAST). Next, an SSA generator transforms the UAST into a SafeTSA graph, which is finally encoded into a binary stream and written to a file. <...>
Unlike SafeTSA, Slim Binaries are based on encoding the source-level abstract
syntax tree of a program. As a consequence of being so far removed from the internal representations typically used in compilers, Slim Binaries cannot communicate the results of program analyses and target machine independent optimizations as well as SafeTSA can.

Ответ на »сообщение 3454« (Илья Ермаков)
___________________________

Ответ на »сообщение 3442« (Булат Зиганшин)
___________________________

Ответ на »сообщение 3440« (Руслан Богатырев)
с другой стороны, это и не свойство языка, а компилятора, верно? на основании спецификации типов экспортируемых модулем единиц для любого языка можно создать такую компонентную систему

Не совсем. Один из примеров: для компонентности, как я уже упоминал, нужно автоматическое управление памятью. Для автоматического управления памятью нужна а) поддержка метаинформации о типах б) герметичность системы типов. В языках С-семейства нет ни а) ни б). При этом а) еще можно ввести. Но б)... Никто не может запретить в С/С++ программисту засувать указатель в int-переменную. После чего диспетчер памяти мгновенно сядет в лужу, и пройзойдет фатальный сбой системы... О какой надежности и интегрируемости компонент при таком "дырявом решете" в типизации языка может идти речь?

можно - не означает "нужно", эта возможность используется только тогда, когда сборкка мусора совершенно не нужна. для C++ есть сборщики мусора. в java/c# это свойство языка. выбирать для сравнения те языки, где GC ещё не было - не самый лучший способ убедить оппонентов :D

Ответ на »сообщение 3474« (Руслан Богатырев)
___________________________

Осталось только придумать, как реализовать динамическое расширение функциональности в чистом функциональном виде...

А Вы никогда не задумывались, зачем нужна эта пресловутая чистота? В ФП чистота мнимая (давайте не будем убеждать себя и других, что это не так). Так зачем пытаться прикрутить красивый элегантный дирижабль ФП к велосипеду ИП? Рожденный летать, ползать не может :) Может лучше -- каждому то, что у него лучше получается?

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

что касается замены реализации чистыхз функций на лету - реализовать её несложно, unsafePerformIO к вашим услугам, вот только ничего хорошего из этого не выйдет (если новая функция может возращать иные результаты). такие вещи нужно записывать как императивные процедуры, ну а дальше всё дело техники. oberon в этом отношении выдаётся именно как среда, где это всё уже реализовано

кстати, советую на rsdn почитать статьи по erlang'у, чтобы избавиться от местечкового провинциализма ;)

Ответ на »сообщение 3474« (Руслан Богатырев)
___________________________

Что касается множественного присваивания (сразу нескольких значений), то Вирт от него вроде бы и не отказывался. Он просто его никогда и не использовал. Для него всегда readability (наглядность, удобство анализа) было более важно, чем writeability (компактность кодирования, удобство синтеза).

Вообще-то я имел в виду многократное присваивание разных значений одной переменной (multiple assignment) в противовес однократному (single assignment).
Представляете, насколько нагляднее текст программы, в которой все присваивания однократны! :о)) referencial transparency во всей красе!


А Вы никогда не задумывались, зачем нужна эта пресловутая чистота? В ФП чистота мнимая (давайте не будем убеждать себя и других, что это не так). Так зачем пытаться прикрутить красивый элегантный дирижабль ФП к велосипеду ИП? Рожденный летать, ползать не может :) Может лучше -- каждому то, что у него лучше получается?

Тьюринг как-то доказал, что его машина эквивалентна лямбда-исчислению.
Вот я и думаю, каким образом можно реализовать такие механизмы расширяемости в рамках чистого ФП без всяких хаков...

Ответ на »сообщение 3476« (slava)
___________________________

Так значит Вирт с Модулой не успел... :(
Эх, какой язык загубили...

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

Кстати, в 1993 г., выступая в американском Кембридже на конференции ACM по истории языков программирования (HOPL-II) с докладом об истории работ по Паскалю, Вирт затронул и тему Модулы-2 (при ответе на вопросы из зала). Напомню, что в 1993 г. уже были доведены до кондиции язык Оберон и ОС Oberon, причем подготовлены к экспорту за пределы ETH (на другие платформы, отличные от Ceres). Так вот, на вопрос Мартина Кембелла-Келли о том, что если проектирование Фортрана заслуживает оценки 2, а Паскаля -- "пятерки", то какую оценку Вирт выставил бы Модуле-2, Вирт ответил лаконично: "6". (Это наивысший балл в швейцарской системе школьного образования.) Текст выступления Вирта на HOPL-II (без ответов на вопросы -- их там не публиковали) можно найти здесь: http://www.europrog.ru/paper/nw1993-01e.pdf

Martin Campbell-Kelly: If, on a scale of excellence in programming language design, FORTRAN was awarded two, and Pascal was awarded five, what score would Modula-2 deserve?
Niklaus Wirth: Six. (In the Swiss school system, one is the worst and six is the best grade.)

С 9 по 10 июня 2007 г. в Сан-Диего (США) будет проходить 3-я Международная конференция по истории языков программирования (History of Programming Language Conference, HOPL-III). На ней с докладом "История языков Модула-2 и Оберон" выступит Никлаус Вирт. Будет крайне интересно узнать, каковы нынешние оценки Вирта в отношении разработок Модулы-2 и Оберона.

Ответ на »сообщение 3476« (slava)
___________________________

Так значит Вирт с Модулой не успел... :(
Эх, какой язык загубили...

Не так. Там были требования Минобороны, которым нужно было удовлетворить. Сами понимаете. А Вирт сделал по-своему.