Size: a a a

2021 April 03

K

Kir in Haskell
В прологе я бы просто оставил переменные, а унифицировал бы с размерами их потом
источник

к

кана in Haskell
кана
какое-то наивное решение выглядит так

unlabel :: [Instr] -> [UnlabledInstr]
unlabel instrs =
 let (labels, unlabeled) = go labels 0 instrs []
  in unlabeled
 where
   go labels i [] result =
     (labels, reverse result)
   go labels i (Label label : xs) result =
     go ((label, i) : labels) i xs result
   go labels i (Push x : xs) result =
     go labels (i + 1) xs (UPush x : result)
   go labels i (Jump l : xs) result =
     go labels (i + 1) xs (UJump (fromJust (lookup l labels)) : result)
а хм, это же буквально стейт
источник

K

Kir in Haskell
Я бы просто хранил обратные ссылки на forward pointers
источник

K

Kir in Haskell
Потому что

jump x
 add a b
 x:
 sub b a
источник

к

кана in Haskell
Kir
В прологе я бы просто оставил переменные, а унифицировал бы с размерами их потом
ну да, достаточно красиво
источник

t

toriningen in Haskell
У меня небольшой теоретический и, скорее всего, глупый вопрос. Если вдруг что, смело гоните меня, насмехайтесь надо мной, и я пойду обратно в haskell start.

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

Сложность в том, что я не до конца понимаю, как это должно выглядеть. Если бы это была чистая структура данных аля дерево, то тут все просто — я описываю предикаты для групп узлов, матчу узлы по этим предикатам, скармливаю выбранные узлы в функцию, которая порождает новые узлы, и заменяю поддеревье и итеративно продолжаю этот процесс до полного просветления, пока не перестанет что-то матчиться.

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

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

Я пытаюсь изобрести какую-то странную чухню, или у этой задачи есть решение?
источник

t

toriningen in Haskell
если вдруг я не смог до конца объяснить, что я хочу, то уточните, пожалуйста, попробую еще раз объяснить...
источник

MK

Maxim Koltsov in Haskell
Я бы тоже послушал ответ
источник

к

кана in Haskell
> кстати, у "коллбэка бинда" есть официальное название?..
можно продолжением назвать

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

полагаю что фриаппликативы (и даже селективы) можно заранее оптимизировать, а фримонады нет
источник

t

toriningen in Haskell
кана
> кстати, у "коллбэка бинда" есть официальное название?..
можно продолжением назвать

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

полагаю что фриаппликативы (и даже селективы) можно заранее оптимизировать, а фримонады нет
ну ведь это (цитата из любой статьи про монады) "просто как будто AST для вашего кода!"
источник

MK

Maxim Koltsov in Haskell
Да не, накрутить частичное выполнение на ФМ можно
источник

MK

Maxim Koltsov in Haskell
Но зачем
источник

к

кана in Haskell
так что я думаю что если хочется оптимизировать - придется брать селектив, ограничив тем самым возвращаемые значения до енама
источник

MK

Maxim Koltsov in Haskell
В смысле даже в языках с эффектами можно делать PE
источник

к

кана in Haskell
можно схлопывать какие-то действия, которые на одном уровне продолжения
источник

к

кана in Haskell
то есть условно для FreeIO с getLine и print можно схлопывать в один все принты между getLine
источник

t

toriningen in Haskell
Maxim Koltsov
Да не, накрутить частичное выполнение на ФМ можно
а что такое "частичное выполнение" в конкретно этом случае?
источник

к

кана in Haskell
ну полагаю как раз сворачивание нескольких фри-команд в одну, которая будет иметь такое же поведение
источник

к

кана in Haskell
например Add (Pure 1) (Pure 2) в Pure 3
источник

t

toriningen in Haskell
кана
ну полагаю как раз сворачивание нескольких фри-команд в одну, которая будет иметь такое же поведение
ну, кстати, необязательно "такое же поведение"... скорее даже нет
источник