http://hackage.haskell.org/package/dejafu-1.11.0.3/docs/Test-DejaFu-Conc-Internal-STM.html

Похоже на то, что нужно

ты не прав

Я прав

в качестве отделения интерфейса от имплементации они FT и Free ничем не отличаются

Я не говорил, что они сильно отличаются. Где?

ещё и с логикой беда : (

я не говорил, что ты говорил, что они *сильно* отличаются

я говорил, что вопрос покажите мне это бесмысленнен

особенно после предоставления class STM

Вы в чем меня пытаетесь сейчас убедить?

отделение интерфейса от имплементации полезно тем, что облегчает мышление

отделение интерфейса от имплементации полезно тем, что облегчает мышление

кто-то в этом чяте с этим спорит, вот зачем вы это написали?

кто-то в этом чяте с этим спорит, вот зачем вы это написали?

Не понимаю, почему бы благородному дону не написать это

ну видимо это должно как-то относиться к дискуссии и подтверждать какое-то утверждение высказанное ранее

или опровергать что-то

ты не прав

я про это. возможно не так понял

утверждение о том, что Free отделяет интерфейс от имплементации не более, чем module Foo

и там и там есть граница абстракции

и там и там имплементация отделена от реализации

но что дает Free - возможность реализации различных интерпретаторов

module Foo без функторов и сигнатур этого не дает

Ну, в хаскельном сообществе, конечно, еще нужно работать над распространением знаний о подходах

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

отделяет конечно

в модуле может быть любая имплементация, и она тебе как пользователю модуля не важна

и там и там имплементация отделена от реализации

Разница в том, что когда мы говорим про модули, работающие с чистыми данными, то их имплементация тоже будет чистой. Когда мы говорим про Free/FT, имплементация может быть потенциально нечистой, а это значит, что может существовать некая служебная рантаймная информация, и эту информацию _нет никакого смысла_ показывать в интерфейсе языка

это вроде как в 70е было известно

да, но когда я читаю код модуля

Модули бекпековские или старорежимные?

отделение - старорежимные

разные имплементации - бекпек

А что в хаскеле интерфесом считать? Полиморфный тип?

да, но когда я читаю код модуля

а когда ты смотришь реализацию интепретатора Free структуры?

интерфейс тут обобщенно - те типы и функции, с которыми ты можешь работать

я вижу интерфейс отдельно от реализации

когда ты делаешь import Foo ты видишь интерфейс

нет, компилятор видит интерфейс

в модуле может быть любая имплементация, и она тебе как пользователю модуля не важна

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

haddock показывает мне интерфейс

но если я на код смотрю я вижу и то, и другое в мешанину

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

в чем проблема?

А что в хаскеле интерфесом считать? Полиморфный тип?

Интерфейсов в хаскеле очень много всяких, и они могут решать разные задачи. Полиморфный тип - тоже

в чем проблема?

Ты можешь легко привести опровергающий пример, как это сделать, раз тебе это известно.

я почему выше спросил, я не понимаю твою проблему

я не вижу пример чего ты хочешь увидеть

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

Я тоже не понимаю

О чём спор вообще?

я спросил какую проблему должно решать наличие Free/FT для реализации STM

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

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

сейчас спор идёт о том, дает ли Free магические свойства по разделению интерфейса от имплементации, если используется единственный интепретатор

Нет, конечно

Я не понимаю, почему не дает

Что здесь есть "магическость"?

"то, что я не могу объяснить, но оно должно быть"

Как же так, если 2 интерпретатора и больше - такое свойство есть, а если 1 - нет?

Я так думаю, что если _можно_ написать несколь реализаций интерфеса, то разделение есть

"то, что я не могу объяснить, но оно должно быть"

Я уже 10 раз объяснил про рантаймовую инфу, которая должна быть только в имплементации. Хочешь примеров, они у меня в ГитХабе

моё утверждение - Free дает возможность делать разные интерпретаторы, по сравнению,со, скажем, модулями

это его основное свойство

Я и не отрицал этого свойства в такой формулировке

новое по сравнению с module

оно не дает большего отделения, если у тебя 1 интепретатор, то возникает вопрос, а зачем мне Free

и что я должен продемонтрировать если напишу на FT

оно не дает большего отделения, если у тебя 1 интепретатор, то возникает вопрос, а зачем мне Free

Бред же

вот опять

Зачем закрывают интерфейсом ровно 1 имплеметацию в обычных ООП-языках?

Даже зная, что никогда второй имплементации не понадобится

Правильно, чтобы уменьшать сложность путем разделения ответственностей

Ну можно, например, скрыть реализацию, не покзывая её з модулдя

С тем же эффектом

3 варинта: 1. понадобится 2. для множественного наследованя 3. карго-культ

выбирай, тот что удобнее

Ну можно, например, скрыть реализацию, не покзывая её з модулдя

Как мне в эту скрытую часть пропихнуть свои рантаймовые данные? Настройки какие-нибудь. Не через публичный интерфейс функций, само собой

выбирай, тот что удобнее

4) Уменьшение сложности не вариант по какой причине?

НЕТ!

просто использование класса иил модуля дает тот же эффект

Зачем закрывают интерфейсом ровно 1 имплеметацию в обычных ООП-языках?

1) так положено, потому что архитектурка 2) ретроспективно ничего не обобщишь, тайпклассов с модулями-то нету

причем даже не мл-евского модуля

просто использование класса иил модуля дает тот же эффект

Класса типов - да Модуль - нет. Тогда должна быть функция а-ля runThisAllStuff :: SomeRuntime -> ModuleStuff -> IO Result

Класса типов - да Модуль - нет. Тогда должна быть функция а-ля runThisAllStuff :: SomeRuntime -> ModuleStuff -> IO Result

мы про ООП языки

Как мне в эту скрытую часть пропихнуть свои рантаймовые данные? Настройки какие-нибудь. Не через публичный интерфейс функций, само собой

это будут разные реализации т.к. они будут зависеть от рантайм значений

класса в смысле class

Класса типов - да Модуль - нет. Тогда должна быть функция а-ля runThisAllStuff :: SomeRuntime -> ModuleStuff -> IO Result

точно так же как ты бы в интерфейс пропихнул

картинка_с_соломенным_самолётом.jpg

это будут разные реализации т.к. они будут зависеть от рантайм значений

Пусть будут разные, мне все равно. Я хочу: 1. В интерфейсных функциях ничего не знать про эти рантайм данные 2. Иметь возможность передать эти данные 3. По-прежнему использовать интерфейсные функции, которые под капотом обращаются к рантаймным данным

я устал, я мухожук

Это типичная задача, которая решается ОО-интерфейсами. И не потому, что "так принято в архитектурках", а потому что клиенту, где мой интерфейс используется, не полагается знать о рантайм-данных, которые я под него подсунул

если что-то новое и толковое будет - пните пожалуйста

я устал, я мухожук

Ну вот можно что-нибудь из книжек про дизайн и архитектуру в ООП почитать

там шизофазия

Ну вот можно что-нибудь из книжек про дизайн и архитектуру в ООП почитать

советую почитать про Pascal это 69 год

Пусть будут разные, мне все равно. Я хочу: 1. В интерфейсных функциях ничего не знать про эти рантайм данные 2. Иметь возможность передать эти данные 3. По-прежнему использовать интерфейсные функции, которые под капотом обращаются к рантаймным данным

да я только за, правда по-умолчанию тянусь к FT вместо Free ? в FT на тайпклассах рантайм значения не запихнешь, но на словарях норм.

там шизофазия

Там сущности?

Смысл совсем в другом. Что можно абстрагировать и убирать сложность. Эффективно разделять на интерфейс и имплементацию. Менять или не менять интерпретатор - дело десятое. У меня может быть только 1 потенциальный интерпретатор, но если мне нужно разделить мой код на интерфейс и имплементацию, я все равно буду это использовать

хм, ну функция и ее сигнатура - это уже интерфейс, реализация отделена и в другом модуле

да я только за, правда по-умолчанию тянусь к FT вместо Free ? в FT на тайпклассах рантайм значения не запихнешь, но на словарях норм.

Я подозревал, что это так, спасибо

если интерпретатор один, то вроде нет разницы

у FT и Free изоморфны

можно преобразовать одно в другое