Почему запросы к базе данных являются хорошим местом для использования стрелок?

Question

Я читал это , в котором говорилось:

Ну, суть в том, что обозначение стрелками запрещает некоторые вычисления, которые позволяют обозначения. В частности, все «действия стрелы» должны быть «статически» известны «.

и это объясняет:

Статически известный "означает, что если у нас есть пара строк обозначений стрелок

> -- y <- action1 -< x

> -- z <- action2 -< y

тогда выражение action2 не может зависеть от x или вообще от чего-либо, связанного с левой стороны строки обозначения стрелки.

Насколько я понимаю, это ограничение - то, что делает стрелки стоящими.

Теперь я пытался выучить Opaleye и заметил, что он использует стрелки для объединения вещей.

Почему Опалий использует стрелки? Почему стрелы хорошо подходят для этой работы? Что такого в базах данных / запросах, которые делают это ограничение полезным?

Answer 1

При объединении агрегирования и монадного связывания в языках запросов возникает проблема с областью действия переменных. Я никогда не придумал особенно удовлетворительного объяснения, но вы можете увидеть мой исторический пост в Reddit и (исправлено) с реляционной записью для некоторых деталей.

Answer 2

Параметризованные запросы к базе данных выглядят как стрелки:

• каждый имеет вход и выход
• они составляют
• мы хотим трактовать их иначе, чем функции Haskell

Композиция (.) (или (<<<)) выглядит как подзапрос SQL. (&&&) выглядит как соединение SQL.

Я считаю, что «статически известное» ограничение относится к вещам, которые вы могли бы разумно преобразовать в SQL. Как только вы разрешите fmap / lmap / rmap с произвольными функциями Haskell, это невозможно (по крайней мере, без расширений языка SQL и плагинов компилятора GHC). Я не проработал детали.

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