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

Question

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

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

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

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

> -- y <- action1 -< x

> -- z <- action2 -< y

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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