Ответ на »сообщение 2801« (AVC)
___________________________
В смысле мотивировки исключения рокировки и взятия на проходе.
Для рокировки имеет значение двигались ли до этого король или ладья.
Для взятия на проходе имеет значение с какой позиции стартовала пешка противника, и был ли после этого пропущен ход.
Как видите обе задачи нетрудные, но нагромождают лишние детали, с точки зрения маленькой учебной программки.
В отличии от вас, у меня нет никаких сомнений в том что автор достаточно квалифицирован, чтобы решить эти задачи, если ему придется за них браться.
В конце концов состояние всей доски он ведь сохраняет между ходами без проблем. Разве сохранять возможность взятия на проходе для КАЖДОЙ пешки (16), и возможность рокировки для короля и обоих ладьей (6) сильно сложнее ?
Нет. Просто работы много и заморачиваться для маленького примера неохота.

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

>>>Бросилось в глаза...
В смысле ? Вы ожидали чего то большего от маленькой учебной программки размером в несчастные 200 строчек ?


В смысле мотивировки исключения рокировки и взятия на проходе.

Ответ на »сообщение 2799« (AVC)
___________________________
Бросилось в глаза...
В смысле ? Вы ожидали чего то большего от маленькой учебной программки размером в несчастные 200 строчек ?

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

За часик можно в принципе составить себе общее представление.
Изучение кода думаю даст ответ на многие вопросы, которые постоянно возникают у императивщиков.

Бросилось в глаза...

* the capturing en passant and castling rules are the worst things from a programmers point of view, because they make moves depending on previous moves, thats why I ignored both rules in my implementation

* a depth of the game tree of 4 is already very, very slow

Я помню Сергей Перовский все пытался здесь выяснить как на хаскеле написать программу, которая оперирут сложным состоянием в течении долгого времени. Например шахматной партией.
Теперь у него такая возможность появилась:
http://www.steffen-mazanek.de/blog/2007/02/haskell-chess.html
Простенькие шахматы на хаскеле. Весь код - 12 kb
За часик можно в принципе составить себе общее представление.
Изучение кода думаю даст ответ на многие вопросы, которые постоянно возникают у императивщиков.

Ответ на »сообщение 2793« (Max Belugin)
___________________________

Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).

Если в языке Оберон использовать модули с контролем импорта на чтение, то многие вопросы снимутся сами собой. Для этого нужно ввести понятие read-only import (точнее, импорт с ограничениями) и его контроль на уровне верификатора (который гарантирует, что импортированные сущности не превышают свои полномочия).

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

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

Руслан, вы говорите об искусственной ситуации, которую нужно еще специально создать.

Джек, я не пытаюсь других убедить, что ФП -- это плохо, а ИП -- супер. Наоборот, стараюсь, чтобы мы совместными усилиями выявили границы применимости и ограничения как ИП, так и ФП.

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

В ФП для реализации обособленного ИП-мира используются монады. В ИП для ФП-мира можно использовать модули. "Искусственность" модулей в этом смысле ровно такая же, как и монад.

Ответ на »сообщение 2791« (Руслан Богатырев)
___________________________
Абсолютно правильно поняли, с той разницей, что прочитать может, а изменить -- нет. Но если нужно, чтобы и прочитать не мог -- это реализуется просто отказом в "визе" (она не будет включена в список импорта). Вроде бы уже объяснял, но повторю.

Руслан, вы говорите об искусственной ситуации, которую нужно еще специально создать.
Я же говорю об обычной ситуации, в которой рабочий модуль импортирует самым обчным образом десятки других модулей и имеет доступ к глобальным переменным в них описанных.
И вот тут, то есть в самой обычной рабочей ситуации, компилятор вам не поможет. А насадить такую иезуитски жесткую дисципину в команде, чтобы ни один модуль ниоткуда не импортировал никакие глобальные переменные, вы не сможете в принципе.

В отличие от этого хаскель позволяет вам совершенно спокойно импортировать любые глобальные переменные, в том числе и mutable, но при этом гарантирует что никто не сможет иметь к ним доступа из чистых функций. ДАЖЕ из тех функций в которых имеется свое внутреннее состояние.

И вот такая гарантия дорого стоит. Дороже любых уговоров грамотно пользоваться модулями.
Уговорам я не верю.

Ответ на »сообщение 2793« (Max Belugin)
___________________________

Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).

Это верно. Внутри модуля гарантий нет. Но есть средства-подходы, позволяющие такую гарантию обеспечить/реализовать.

1. Отделенная от остального мира и "препарированная" функция-модуль (т.е. вырожденный модуль, внутри которого одна функция) гарантирует в определенной мере адекватную проверку подобного воздействия побочных эффектов. Следуя принципу No Paranoia, можно повышать гранулярность такого автономного ФП-модуля другими функциями.

2. Язык Оберон/КП не дает гарантий, но они могут быть обеспечены внеязыковыми средствами (верификатором). Точнее, средствами языка более высокого уровня (языка контроля -- языка для верификатора), который внедряется в базовый язык на уровне маркированных комментариев (подобно прагмам компилятора). Некие идеи в отношении этого описывал пару дней назад в ветке по Оберону. Гарантии -- включая контроль однократного присваивания.

На самом деле, глубинные отличия ФП от ИП довольно неплохо проведены в тьюринговской лекции недавно ушедшего от нас Джона Бэкуса (1977) "Можно ли освободить программирование от стиля фон Неймана? Функциональный стиль и соответствующая алгебра программ". На русском перевод у меня есть только в бумажном виде ("Лекции лауреатов премии Тьюринга. 1966-1985" -- М.: Мир, 1993). В оригинале (2,93 Мбайт) http://www.europrog.ru/paper/jb1977-01e.pdf

Бэкус проводит классификацию моделей:
1. Простые операционные модели (машина Тьюринга, конечные автоматы, сети Петри и т.п.)
2. Аппликативные модели (лямбда-исчисление, система комбинаторов Карри, системы ФП)
3. Модели фон Неймана (традиционные языки)

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

Поэтому, если в ИП имитируется мир ФП, то в этой "песочнице" надо установить повышенный контроль за упомянутыми вещами. Это возможно.

P.S. В рассуждениях относительно Оберона/КП можете спокойно держать в голове Delphi (по ключевым вещам он не шибко отстает, просто много наносного, от которого можно абстрагироваться).

Ответ на »сообщение 2792« (Руслан Богатырев)
___________________________
Насколько я понял, монада ST грубо говоря создает полностью закрытый изолированный мир в котором можно вычислять путем явного задания последовательности состояния этого мира.

Внутри него, например, нельзя явно или неявно изменить состояние ничего другого.

Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).

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

Еще, как мне кажется, джек описался упоминая монаду IO - он имел ввиду монаду ST.