Здравствуйте, eao197, Вы писали:
E>Я привел пример, когда по стечению обстоятельств одна часть системы стала зависеть от поведения другой. Проверить работоспособность такой зависимости в моем случае можно только тестами, т.е. организационными мероприятиями. Изменить дизайн слишком дорого. И очевидно, что можно. Но, вопрос не в этом. А в том, что есть такого в ФП, что не позволяет возникать таким ситуациям в принципе? Или же в ФП при возникновении дилемы -- либо переделать дизайн, либо доказывать корректность тестами -- выбор всегда можно будет сделать в пользу переделки дизайна?
Как я понял, произошло следующее. thesz показал, где ФП выигрывает. Затем ты показываешь ситуацию и спрашиваешь — а как здесь ФП выигрывает? Даже не разбираясь в том, что за ситуацию ты предлагаешь, можно сказать, что
1. Возможно здесь никак
2. Это никак не опровергает того, что ФП выигрывает так, как показал thesz.
Если же слова thesz и твоё предложение рассмотреть эту ситуацию никак не связаны, то я извиняюсь — недопонял.
L>>Есть data Mailslot с определённой функцией sendStateNotification :: Mailslot -> Result. Есть data S, содержащая этот мейлслот, необходимо, чтобы функция queryState :: S -> Result (ну хорошо, SInterface s => s -> Result) можно было определить только единственным образом. Ну так оно и есть!
E>Если не сложно, тоже самое, только на русском.
Смысл такой — с помощью системы типов можно ограничить возможные реализации функции для данного типа (существование единственного доказательства для данной теоремы).
Я показал примитивный пример, для подробностей можно посмотреть
Curry-Howard изоморфизм
Theorems for free!
Пример вывода
Djinn — программка, выводящая реализацию функции по её типу.
Практические применения ограничений с помощью системы типов
Lazy Functional State Threads. Наверное, одна из самых лучших статей на тему. Как rank-2 полиморфизм (логика второго порядка) помогает вставлять императивный кусок в функциональный код безопасно.
Beautiful Concurrency. Преимущество этой статьи — необязательно знать синтаксис Хаскеля.