AT
Если обсуждаем реализацию GC, то да, можно обсуждать как он работает со ссылками "внутрь" и откуда они возникают. Но это уже другой разговор и он специфичен для каждого конкретного GC/рантайма.
Size: a a a
2021 February 08
K
Ладно, я понял, о чём он. Он изначально полагает, что union всегда определён для Map, причём единственным способом.
Я вообще считаю каноническим определение моноида для Map из https://hackage.haskell.org/package/monoidal-containers
Обычные контейнеры могут быть получены через
Обычные контейнеры могут быть получены через
Map k (First v)ΑZ
Я вообще считаю каноническим определение моноида для Map из https://hackage.haskell.org/package/monoidal-containers
Обычные контейнеры могут быть получены через
Обычные контейнеры могут быть получены через
Map k (First v)вроде бы в конце статьи к этому и пришли. ВОпрос в том, почему это правильно, без апелляции к "я вообще считаю"
K
вроде бы в конце статьи к этому и пришли. ВОпрос в том, почему это правильно, без апелляции к "я вообще считаю"
Потому что это most general?
ΑZ
а где пруф что нет ничего более general?
ΑZ
это как колимит, для которого доказывается что это достаточная хрень для выражения требуемой концпции и добавление информации не приносит пользы
ΑZ
там же доказывается что меньше информации тоже нельзя иметь иначе нарушается натуральность
M
Контейнеры образуют DAG с двусторонними ссылками между узлами.
Это не DAG. Так как двухсторонние ссылки между узлами образуют циклы. Но вот если постоить узлы из компонентов сильной связности (SCC), тогда можно уже говорить о DAG для таких узлов
M
Вообще это была бы пушка а не язык, надо включил, не надо отключил
Да по-моему почти в любом GC языке там можно. В AssemblyScript например есть аттрибут @unmanaged который ставишь перед объявлением класса и который означает что объект теперь не будет управляться GC и его нкжно освобожать руками (или не освобождать)
M
Я считаю что все проблемы от free
Нет, от free after free (use after free) =)
AT
Нет, от free after free (use after free) =)
Double free... Um... 😊
ДК
Это не DAG. Так как двухсторонние ссылки между узлами образуют циклы. Но вот если постоить узлы из компонентов сильной связности (SCC), тогда можно уже говорить о DAG для таких узлов
Мне как бы виднее даг это или не даг. Там двухуровневый граф. На низком - двусторонние указатели. На высоком - направленные рёбра. Такая структура позволяет ходить по направленному графу в произвольных направлениях.
M
Мне как бы виднее даг это или не даг. Там двухуровневый граф. На низком - двусторонние указатели. На высоком - направленные рёбра. Такая структура позволяет ходить по направленному графу в произвольных направлениях.
Ну так сразу бы так и написали а то получилось «мирная война» и «принуждение в миру»
AT
Ну так сразу бы так и написали а то получилось «мирная война» и «принуждение в миру»
Да "ходить по направленному графу в произвольных направлениях" тоже оксюморон. 🤷♀️
ДК
Да "ходить по направленному графу в произвольных направлениях" тоже оксюморон. 🤷♀️
Я вам по секрету скажу, именно так графовые системы как правило и работают.
M
Я вам по секрету скажу, именно так графовые системы как правило и работают.
Я смотрю ничему хабр не учит. Там каждая ваша статья в минусах, и много людей пытается в комментариях вам рассказать обшепринятые базовые принципы, но вы их слушать не желаете, здесь похоже тоже не желаете.
ДК
Вместо перехода на личности могли бы привести хоть один контр-пример.
s
Да "ходить по направленному графу в произвольных направлениях" тоже оксюморон. 🤷♀️
Забывающий функтор из направленных графов в ненаправленные никто не отменял.
s
Законы страны не запрещают ходить против стрелок.
AT
Забывающий функтор из направленных графов в ненаправленные никто не отменял.
> в ненаправленные
Именно. 😊
Именно. 😊