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

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

Для ФП, IMHO, интенсивная работа с динамическими структурами -- достоинство. Но они же являются и его недостатком (узким местом). Следовательно, для выбора приемлемости ФЯ к решению конкретной задачи, где подразумевается активная работа с динамическими структурами, необходимо иметь инструмент анализа (оценки/прогноза) "прожорливости" ресурсов. Было бы интересно узнать, какими возможностями располагает программист, приподнятый ФП над реальностью железа, для адекватной оценки и прогноза "просадки" -- возможностей масштабирования задачи. Нет ничего хуже, чем получив быстро красивый результат и пустив его в дело через некоторое время выяснить, что при м асштабировании просадка станет таковой, что потребует кардинальной переработки. "Автопилот" ФП в этом плане не может не настораживать. Или мои опасения напрасны?

Когда грамотный программист работает на ИП (Delphi, Оберон, КП), он в состоянии понять, во что превратится его текст после трансляции (как будет отображен на железо и где появяться точки "просадки"). Для ФП (из-за оторванности от императива и конкретики железа) этот момент затруднителен. Понимаю, что можно заниматься дизассемблированием и анализировать схему работы транслятора, но сомневаюсь, что этим озадачиваются даже грамотные ФП-программисты.

Вопрос: какие подходы мировое ФП-сообщество выработало в отношении оценки потребности ресурсов/"просадки" с перспективой возможностей последующего масштабирования (быстро) полученного решения? Это не укол, а желание разобраться. Плюсы ФП (сокрытие деталей) здесь превращаются в минусы. Их, видимо, можно нивелировать. Осталось выяснить как.

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


Вам обязательно нужен строгий квалифицирующий импорт? Пожалуйста

Он не мне нужен, а Вам нужен, если предполагаете использование строго стиля программирования, а также отчуждать свое творение (пресловутое readability и clearity). Без qualified-импорта нельзя локализовать точки импорта сущностей (надо знать, что было в импортируемом модуле -- иметь к нему доступ или документацию, которая имеет тенденцию рассинхронизироваться с действительностью). Хочу обратить Ваше внимание, что неквалифицирующий импорт в Хаскеле сделан не как в Модуле-2 -- в Модуле-2 явно прямо в списке импорта (т.е. у нас перед глазами) перечисляются импортируемые идентификаторы, а в Хаскеле -- только имя импортируемого модуля. Это худший вариант. То, что он в этом языке сосуществует с лучшим вариантом -- квалифицирующим импортом -- дает возможность выбора (чего давать нельзя). И Вы, разумеется, выбрали худший, поскольку руководствовались "Бейсик-критерием" вместо надежности и сопровождаемости. Экономия на использовании лишних "буковок" -- IMHO, Бейсик-мания. Об уроках Оберона я не зря говорил. Делайте выводы, учитесь на чужом опыте тех, кто на этом не одну собаку съел, а не отмахивайтесь, как от назойливой мухи. Уж слава Богу, в сфере нюансов модульного программирования Вирт и его коллеги дадут 100 очков вперед Хаскель-сообществу.

Как видите, это вполне возможно в Хаскелле.

Жаль, что Вы не видите, о чем я писал: "Справедливости ради следует сказать, что в Хаскеле поддерживается дуальность квалифицирующего и неквалифицирующего импорта". Вынужден трактовать это либо как Вашу невнимательность к словам оппонента, либо как работу на публику.

Впрочем, вопрос вкусов и приоритетов...

Не уверен, что строгость программирования -- дело вкуса. Это больше напоминает принцип "и так сойдет".

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

В отношении части B: на примере Хаскеля хорошо видно, что импорт IO не показывает точки использования импортируемых сущностей внутри исходного текста (типичная ситуация в случае т.н. неквалифицирующего импорта).

Вам обязательно нужен строгий квалифицирующий импорт? Пожалуйста:

module ACM_2007_A where

import qualified IO
import qualified List

{-------------------------------------------------------------------------------
--                    Гр.кр.  Гр.кр.  Гр.кр.
--                    родит.  родит.  ребёнка
-}
type TestCaseStr    = (String, String, String)
type TestCaseResult = (SetABO, SetABO, SetABO)

type SetABO        = [String]

--------------------------------------------------------------------------------

main = do
    fileIn          <- IO.openFile "blood.in" IO.ReadMode
    contents        <- IO.hGetContents fileIn
    putTestCases $ process $ parse $ lines contents
    IO.hClose fileIn
...
...
...                               

Как видите, это вполне возможно в Хаскелле.

Вот только это создаёт лишнюю писанину и код может выглядеть весьма неестественно и некрасиво. Например:

module Complex_Test where

import qualified Array
import qualified Complex

main = do let n = 1.0 Complex.:+ 2.0
              m = 5.0 Complex.:+ (-12.3)
          print (m / n)
          print (fib 1000)

fib n = fa Array.! n
  where
    fa = Array.array (1,n) ([(1, 1), (2, 1)] ++
                            [(i, fa Array.! (i-2) + fa Array.! (i-1)) | i <- [3..n]])

вместо аналогичного

module Complex_Test where

import Array
import Complex

main = do let n = 1.0 :+ 2.0
              m = 5.0 :+ (-12.3)
          print (m / n)
          print (fib 1000)

fib n = fa ! n
  where
    fa = array (1,n) ([(1, 1), (2, 1)] ++
                      [(i, fa ! (i-2) + fa ! (i-1)) | i <- [3..n]])

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

Впрочем, вопрос вкусов и приоритетов...

Ответ на »сообщение 2602« (Trurl)
Ответ на »сообщение 2603« (Trurl)
Ответ на »сообщение 2606« (Geniepro)

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

К прямой оценке эффективности того или иного языка мой вопрос о взаимном написании компиляторов вполне возможно и не приведет. В этом случае таковая м.б. получена только на более высоком уровне математической абстракции - с использованием метаметаязыка (во загнул :)). Но смысл в том, что на каком-то уровне математической абстракции можно получить объективную оценку выразительных возможностей того или иного языка.

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

ЗЫ. А если сделать Оберон-систему целиком в машинных кодах, то она будет гораздо эффективнее, чем на Обероне. И почему большинству людей такая идея кажется бредом?

Простите за нескромный вопрос, а Вы в этом плане себя причисляете к большинству или к меньшинству?

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

Вот Руслан Богатырёв уже несколько лет предлагает российскому сообществу блэкбоксёров вставить в Блэкбокс компилятор первого Оберона. Но почему-то эта идея никого, кроме него, так и не заинтересовала, хотя казалось бы - чего уж сложного взять несколько модулей из ETH-Oberon, чуть-чуть их подшаманить - и вуаля! Ан нет...

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

В КП можно работать на уровне классического Оберона, при этом опускаться на бесклассово-шинный уровень или подниматься на уровень модификаторов ООП (для придания большей жесткости ОО-конструкциям). На мой взгляд, гораздо акутальнее сейчас задача легко отчуждаемых практических программ/систем-примеров (совсем даже не компонент), которые полезны потребителям как с точки зрения функционала, так и использования для "клепания" собственных вещей (и изучения Оберон-технологий). Подача этого с подробным разъяснением (почти как Вы Geniepro делали, разжевывая свое решение на Хаскеле). В этом большая ценность -- открытый продуманный код, открытая документация, возможность расширять или преобразовывать путем "клепания" расширенных клонов.

Ответ на »сообщение 2597« (Рэйлвэй Каген)
___________________________

Прошу прощения за overload, но я имел ввиду

"написать компилятор, используя только конструкции соответствующего языка, без ассемблерных вставок и т.п."

Иначе теряется чистота эксперимента.

А скажите пожалуйста, считается ли экспериментально чистым вставка машинных команд (даже не ассемблерных вставок, а именно машинных кодов!) в исходники компиляторов таких Оберон-систем, как ETH-Oberon и BlackBox?

ЗЫ. А если сделать Оберон-систему целиком в машинных кодах, то она будет гораздо эффективнее, чем на Обероне. И почему большинству людей такая идея кажется бредом?

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

Дежурная задачка: реализуйте на Хаскеле загрузчик модулей Оберона в память для Линукса.

Большое спасибо за интересную идею. Только ответьте, пожалуйста, на один вопрос.

Вот Руслан Богатырёв уже несколько лет предлагает российскому сообществу блэкбоксёров вставить в Блэкбокс компилятор первого Оберона. Но почему-то эта идея никого, кроме него, так и не заинтересовала, хотя казалось бы - чего уж сложного взять несколько модулей из ETH-Oberon, чуть-чуть их подшаманить - и вуаля! Ан нет...

Так вот, вопрос: Почему Вы думаете, что создание транслятора Оберона или хотя бы загрузчика его модулей может заинтересовать необеронщиков, если это неинтересно даже оберонщикам?

Ответ на »сообщение 2559« (Jack Of Shadows)
___________________________

Совсем нетяжело обьяснить. Правда видимо тяжело на это обращать внимание: »сообщение 2512« »сообщение 2514« Это только последние. До этого тоже самое говорил GeniePro и я.

Раз некоторые сторонники ФП ограничиваются общими словами вместо анализа-сравнения, то предпочту сильно не углубляться в детали. Напомню, две с лишним недели назад я предложил взяться за сравнение подходов-языков на примере пробного камня (задач из набора финала последнего чемпионата мира ACM по программированию) -- http://www.delphikingdom.com/asp/talktopic.asp?ID=368&ref=msg&msg=3271#msg3271

Была выбрана первая задача (кстати, одна из самых простых).

Итак, Евгений (Geniepro) представил решение на Хаскеле с подробным описанием: http://geniepro.livejournal.com/1174.html
Илья Ермаков вслед за этим дал свой вариант на Компонентном Паскале: http://forum.oberoncore.ru/viewtopic.php?t=409
VPrin представил вариант на Delphi (отобразив готовое решение на Хаскеле): »сообщение 2243«
Trurl предложил два собственных варианта: на SETL  -- »сообщение 2539« и на J? -- »сообщение 2309«

Последние два, как я понимаю, для иллюстрации того, что есть решение крайне компактное по записи и даже на императивном языке (SETL).

Напомню, что предлагал провести качественное сравнение (подсчет строк и быстродействие оставить за скобками):
A. Выделить алгоритмическую часть кода, отвечающего за функционал решения (без UI-ввода-вывода и инфраструктурной обвязки)
B. Выделить UI (ввод-вывод)
C. Выделить инфраструктурную обвязку (если есть, как-то: спецификации модуля, экспорт-импорт и т.д. и т.п., что поддерживает существование алгоритма в пространстве ОС).

Пойду с конца.

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

В отношении части B: на примере Хаскеля хорошо видно, что импорт IO не показывает точки использования импортируемых сущностей внутри исходного текста (типичная ситуация в случае т.н. неквалифицирующего импорта). В Обероне от неквалифицирующего импорта Вирт после Модулы-2 отказался (в том числе по этой причине). Локализовать области использования ввода-вывода (интерфейс с внешним миром) в Хаскеле для меня было затруднительно (возможно, излишне субъективно). В КП они легко локализуются поиском модульных префиксов (In. и Out.). При этом, правда, в частном решении происходит смешение работы со строками с вводом-выводом (что может, правда, вполне оправдываться на понятийном уровне).  Справедливости ради следует сказать, что в Хаскеле поддерживается дуальность квалифицирующего и неквалифицирующего импорта (по образу и подобию Модулы-2), но то, что средством qualified не воспользовался Geniepro, лишний раз говорит о недооценке такой возможности (ложный стереотип относительно того, что это всего лишь косметическое средство борьбы с конфликтом имен). Уроки и опыт Оберона стоит извлекать. Ахиллесовой пятой в отношении части B для КП является работа со строками, что, кстати, Илья сразу отметил (она занимает больше половины исходного текста). Напрашивается вывод: либо выносить это за скобки (в отдельный модуль, дабы не нарушать целостности восприятия решения), либо даже иметь часть этих средств в штатной библиотеке.

В отношении алгоритмической части (A): задача по своей сути -- задача на преобразование (а не на конструирование/моделирование), поэтому "лобовой" подход через функции/отображения/проекции работает практически без проблем. Как показывает решение на Delphi ("калька" с решения на Хаскеле), идущее от использования функционального подхода, за небольшими моментами нет технических сложностей для Delphi (а, значит, и для КП). В варианте с КП был выбран самостоятельный путь (тоже через отображения), но он оказался в невыгодном свете ("придавлен" работой со строками и детализацией циклической обработки). Компонентный Паскаль практически работал на уровне классического Оберона (разве что кроме конкатенации строк). А точнее даже, в невыгодных для себя условиях -- на уровне едва ли не классического Паскаля образца 1972 г.  Что для задачи на преобразование да еще такого масштаба -- ожидаемая вещь.

Если говорить не о языке, а о сопоставлении подходов в рамках конкретных языков реализации, то следует обратить внимание, что в Хаскеле использовались императивные вещи (do и монады). По словам Р.В.Душкина, "монада является наиболее сложным концептом для понимания, который только есть в языке Haskell". Они в ФП служат окном в императивный мир. Это типы-контейнеры, "которые связывают внутри себя определенные объекты заданных типов для выполнения над ними операций, в которых могут содержаться побочные эффекты, недетерминизм и прочие неприятные для функционального стиля аспекты программирования".

Стоит учитывать тот факт, что интересовал чистый эксперимент "мышления" на языке -- то есть безальтернативное решение в "ритме мысли" (в финале чемпионате ACM нет времени детально анализировать вариативность подходов), без последующего рефакторинга/трансформации. Хотя сам по себе рефакторинг может представлять интерес как предмет для выработки шаблонных приемов к решению подобных задач (на будущее).

P.S. На мой взгляд, задача достаточно хорошо ложится на конечные автоматы (со всеми вытекающими последствиями по компактности, в ущерб определенной наглядности). Но это детали.

Ответ на »сообщение 2598« (Trurl)
___________________________
>>>К тому же реально рантайм все равно будет на си.
Можно предложить и чистую реализацию.

runtime=[0x55,0x8B,0xEC...]

или такой вариант

newBlock = asmdo
  push  EBP
  mov  EBP ESP
  sub  ESP 12
  ...