t
нет, не селективы. я про Codensity
Size: a a a
2021 April 03
t
не понял ни слова из написанного, увы
KV
Это не релевантно поставленной задаче, если что
KV
Как это единственное, ещё чёрч же есть
Но это неважно, вопрос был про другие оптимизации
Но это неважно, вопрос был про другие оптимизации
к
ну ведь это (цитата из любой статьи про монады) "просто как будто AST для вашего кода!"
в общем буллшит это все, это как сериализация фримонад
KV
В приложении к фримонадам это типа то же самое, что кодировка списков "bla" -> Endo ("bla" ++) чтобы бинды вправо ассоциировать
KV
У чёрчевого нет интроспекции, а в коденсити модно
Free-ветку матчитьwat
K
Результат
Control.Monad.Codensity.improve - это Free. Её можно матчить послойно. Control.Monad.Free.Church.F же сворачивается всегда разом.KV
А. Ну да
KV
Ну то есть нет, но я понял, о чём речь
t
Это единственное, что позволяет оптимизировать
Control.Monad.Freeа если вас не затруднит, то вы могли бы привести хотя бы небольшой пример того, как это могло бы происходить? это очень помогло бы построить интуицию насчет того, что это такое и как этим пользоваться
K
У меня небольшой теоретический и, скорее всего, глупый вопрос. Если вдруг что, смело гоните меня, насмехайтесь надо мной, и я пойду обратно в haskell start.
Так вот... Есть у меня экземпляр фримонады, пусть будет поверх какой-то простой структуры с конструкторами-операциями. Я хочу написать эдакий "оптимизатор" для экземпляра такой монады, который мог бы, пользуясь знаниями о семантике вот этих вот операций, поверх которых она построена, выполнять изменения, затрагивающие много узлов низлежащей структуры — например, сворачивать несколько операций в одну, или менять их относительный порядок, или анализировать взаимозависимости для того, чтобы отмаркировать какие-то узлы, как пригодные для параллелизации и т.д. и т.п.
Сложность в том, что я не до конца понимаю, как это должно выглядеть. Если бы это была чистая структура данных аля дерево, то тут все просто — я описываю предикаты для групп узлов, матчу узлы по этим предикатам, скармливаю выбранные узлы в функцию, которая порождает новые узлы, и заменяю поддеревье и итеративно продолжаю этот процесс до полного просветления, пока не перестанет что-то матчиться.
Но в случае с монадой то, что происходит внутри коллбэка бинда (кстати, у "коллбэка бинда" есть официальное название?..) для меня полностью непрозрачно. По сути, когда я выполняю монадическую функцию, возвращающую экземпляр этой моей специфицированной фримонады, я разворачиваю только "первый коллбэк бинда", а все остальные лишь ждут своей очереди, и я не имею видения всей структуры до того, как вычислю остальные коллбэки.
Окей, пусть я отказываюсь от идеи видеть "все дерево" целиком, и пишу некий "оптимизирующий интерпретатор", который на самом деле выполняет аргументы биндов, чтобы получить дальнейшие ветки, но я сталкиваюсь с тем, что аргументы биндов мало того, что нетотальны, я еще и не знаю наперед, если у них какие-то "особые точки". Т.е. для того, чтобы выполнить следующий коллбэк бинда, мне нужно передать ему фактическое "значение внутри контекста", а у меня-то его и нет. Что ж мне, табулировать все возможные значения? Звучит глупо и невозможно.
Я пытаюсь изобрести какую-то странную чухню, или у этой задачи есть решение?
Так вот... Есть у меня экземпляр фримонады, пусть будет поверх какой-то простой структуры с конструкторами-операциями. Я хочу написать эдакий "оптимизатор" для экземпляра такой монады, который мог бы, пользуясь знаниями о семантике вот этих вот операций, поверх которых она построена, выполнять изменения, затрагивающие много узлов низлежащей структуры — например, сворачивать несколько операций в одну, или менять их относительный порядок, или анализировать взаимозависимости для того, чтобы отмаркировать какие-то узлы, как пригодные для параллелизации и т.д. и т.п.
Сложность в том, что я не до конца понимаю, как это должно выглядеть. Если бы это была чистая структура данных аля дерево, то тут все просто — я описываю предикаты для групп узлов, матчу узлы по этим предикатам, скармливаю выбранные узлы в функцию, которая порождает новые узлы, и заменяю поддеревье и итеративно продолжаю этот процесс до полного просветления, пока не перестанет что-то матчиться.
Но в случае с монадой то, что происходит внутри коллбэка бинда (кстати, у "коллбэка бинда" есть официальное название?..) для меня полностью непрозрачно. По сути, когда я выполняю монадическую функцию, возвращающую экземпляр этой моей специфицированной фримонады, я разворачиваю только "первый коллбэк бинда", а все остальные лишь ждут своей очереди, и я не имею видения всей структуры до того, как вычислю остальные коллбэки.
Окей, пусть я отказываюсь от идеи видеть "все дерево" целиком, и пишу некий "оптимизирующий интерпретатор", который на самом деле выполняет аргументы биндов, чтобы получить дальнейшие ветки, но я сталкиваюсь с тем, что аргументы биндов мало того, что нетотальны, я еще и не знаю наперед, если у них какие-то "особые точки". Т.е. для того, чтобы выполнить следующий коллбэк бинда, мне нужно передать ему фактическое "значение внутри контекста", а у меня-то его и нет. Что ж мне, табулировать все возможные значения? Звучит глупо и невозможно.
Я пытаюсь изобрести какую-то странную чухню, или у этой задачи есть решение?
Рекомендую ограничить всё аппликативом (или сделать монаду DSL-ем для кодогенератора, но тогда "результаты" байндов окажутся какими-нибудь "переменными"). Для аппликатива можно сделать внутреннюю структуру, которая позволит автопараллелизацию. Правда, операции не смогут зависеть от результатов друг друга, комбинировать их будет можно только чистыми функциями. Насчёт
Selective я ничего сказать не могу, я в них не тыкал.KV
В селективах есть бинд как в монаде. Они более выразительные, чем аппликативы. Но можно перечислить все возможные AST, которые могут возникнуть в рантайме, и соответственно менять их как хочется