Разве core.async не противоречит принципам Clojure?

Первая проблема - да, основные операции - это побочные эффекты. Однако у каналов нет проблем, обычно связанных с изменяемыми ссылками, поскольку они не представляют «место» - каналы непрозрачны, вы не можете их проверить, фактически вы даже не можете запросить, закрыт ли канал или нет, кроме чтения. ноль.

Вторая проблема - выполнение чего-либо большего, чем неглубокий выход, означало бы трансформацию всей программы. Это компромисс, и я считаю его разумным. Уровень композиции - это каналы, а не блоки, и они прекрасно сочетаются.

И последнее: вы можете легко выполнять операции map / filter / reduce в стиле Rx по каналам, и люди уже сделали это.

Ограничение макроса go (его локальность) также является особенностью: он обеспечивает локальность исходного кода для операций с отслеживанием состояния.

1. это несколько наоборот, Core.async можно использовать только в системах, где неизменяемость является нормой. Итак, принципы Clojure позволяют использовать core.async, а не наоборот.

2. Это ограничение, встречается и в другом месте в clojure, ограничение анонимных функций, не составляющих символ %, похоже, по крайней мере, представляет ту же идею. Не то чтобы обнаружение другого случая ограничения, конечно, улучшило бы ситуацию.

3. Я не видел этого сам, хотя это было бы шагом назад, если бы вы пытались взять код, который был простым и чистым, когда он выражался одним способом, а затем выражал его таким образом ... не таким .. .

Рич Хики сказал в одной из лекций на blip.tv, что Clojure "на 85% функциональна". Мне нравится видеть core.async как часть остальных 15%. Core.async отлично подходит для прочного взаимодействия с пользователем, среди прочего, что могло бы быть сделано с помощью обещаний, задержек и других вещей, вероятно, более беспорядочным способом.

Каждая программа состоит из двух частей: одна часть, которая всегда не содержит данных о функциях, выводит их и так далее. В этой части мы знаем, что есть core.async, конечно, в core.async есть изменяемые вещи, но обратите внимание на две вещи. Состояние каналов в основном управляется библиотекой. То, что вы на него надеваете, можно назвать flowstate. Это означает, что когда вы помещаете что-то вроде канала, вы не ожидаете, что вернетесь к нему или даже измените его.

Core.async отлично подходит для управления этой частью вашей программы. В остальном, включая все преобразования и вычисления ваших данных, clojure изо всех сил старается предоставить вам хорошие инструменты для функциональной реализации.

Мне кажется, что это мешает простоте и компоновке. Почему это не проблема?

Есть два мира: синхронный и асинхронный. Вы можете помещать данные или извлекать их из асинхронной среды с помощью команды put! и возьми! но кроме этого (и, возможно, какой-то другой функции) эти миры отделены друг от друга. Clojure не хочет становиться полностью асинхронным языком. Функции и преобразование данных должны быть составными.

Возможно, как следствие двух предыдущих проблем, большая часть кода с core.async использует конструкции более низкого уровня, такие как loop / recur вместо map / filter / reduce. Разве это не шаг назад

Подобная работа по каналам будет возможна. Core.async еще молод, и еще не все возможные конструкции и функции написаны.

Но в целом, если у вас есть большие преобразования данных, вы действительно не хотите делать их в асинхронном мире, вы хотите иметь их в коллекции, а затем использовать что-то вроде структуры reducres.

Главное понять, core.async - это не новый стандарт, это еще одна вещь, которая помогает вам программировать. Иногда вам нужен STM, иногда агенты, иногда - это зависит от CSP, и clojure хочет предоставить вам все возможности.

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

возможно, возможное решение использовать (<! c) вне макроса go могло бы быть выполнено с макросом и его временем расширения макроса:

Это мой пример:

(ns fourclojure.asynco
      (require [clojure.core.async :as async :refer :all]))

(defmacro runtime--fn [the-fn the-value]
  `(~the-fn ~the-value)
  )
(defmacro call-fn [ the-fn]
  `(runtime--fn ~the-fn (<! my-chan))
  )

(def my-chan (chan))

(defn  read-channel [the-fn]
  (go
  (loop []
    (call-fn the-fn)
    (recur)
    )
  ))

(defn paint []
  (put! my-chan "paint!")
  )

И чтобы проверить это:

(read-channel print)
(repeatedly 50 paint)

Я пробовал это решение во вложенном режиме, и он тоже работает. Но я не уверен, что это правильный путь