Какая концептуальная разница между машинами и проводниками (или другими подобными библиотеками)?

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

Я пытался следить за Rúnar Bjarnason на машинах, но информации слишком мало, в основном просто куча типов данных. Я даже не могу понять, что k находится в

newtype Machine k o = Step k o (Machine k o)
data Step k o r = Stop
                | Yield o r
                | forall t . Await (t -> r) (k t) r

или что t и почему оно количественно. Или, какова концептуальная разница между библиотеками и машинами, подобными кабелепроводу?

Ответ 1

conduit и pipes являются гораздо более зрелыми, чем machines, но - сказанное - machines пытается использовать другой путь, чем conduit и pipes.

С machines, я пытаюсь использовать относительно простой API в терминах аргументов типа. И conduit, и pipes решили объединить все свои понятия, используя 5-6 переменных переменных типа.

Машины используют другой подход к параметризации машины (или Plan) на своем "языке ввода", который ставит всю нагрузку на один дополнительный аргумент (или два в случае Plan). Кроме того, выбирая возможность параметризации входного языка таким образом, он открывает возможности использования машин, которые могут принимать входные (не) детерминированные из нескольких источников входных данных. Результат - это просто бесплатная монада с дополнительной инструкцией "emit"!

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

Тем не менее, pipes и conduit имели много реального использования в мире, а machines - это более или менее игровая площадка для меня, Рунар Бьярнасон и Пол Чиусано.

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

Теперь об этом кванторе!

t фактически существует количественное определение. Поступая таким образом, мы можем сделать Monad для машин не заботясь о функториальности параметра k. Это важно из-за реализации метода Source. Если мне не понадобилось работать Source, мы могли бы использовать более простой

data Step k o r = Stop
                | Yield o r
                | Await (k r) r

У этого был бы неудачный побочный эффект, который, когда вы пошли, чтобы составить Машину с Source, что компилятор не знал бы, какой экземпляр Functor выбрать, и вы будете купаться в ненужных аннотациях типа.

Экзистенциальная квантификация - это трюк, который я подхватил при работе с пакетом kan-extensions. Это обобщение одного из типов Yoneda.