2.0.2

What's Changed

• Remove the default engine behavior in internal applicative eval functions in #41

Full Changelog: 2.0.1...2.0.2

2.0.1

What's Changed

• Allow to include namespaced symbols in the implicit arg symbols in #40

Full Changelog: 2.0.0...2.0.1

2.0.0

What's Changed

• Prune dependencies by @sovelten in #38
• Breaking release: Fully source compatible, but several transitive dependencies have been removed.
  ** Interaction with these transitive dependencies is still supported, but clients must include them explicitly or through some other library now.

Full Changelog: 1.19.1...2.0.0

1.19.1

What's Changed

• [FIX] Adapting inference context operation to accept nil cases by @phbomfim in #37

New Contributors

• @phbomfim made their first contribution in #37

Full Changelog: 1.19.0...1.19.1

1.19.0

What's Changed

• remove dependency from cats to play nice with protocols by @sovelten in #36

Full Changelog: 1.18.1...1.19.0

1.18.1

What's Changed

• Provide helpful error message when an invalid engine is specified by @aredington in #32
• Add SECURITY.md file by @pemtajo in #34
• Exceptions propagate along dependencies in most engines by @sovelten in #33

New Contributors

• @pemtajo made their first contribution in #34

Full Changelog: 1.18.0...1.18.1

1.18.0

What's Changed

• Virtual Future Applicative Engine by @aredington in #31

Full Changelog: 1.17.0...1.18.0

1.17.0

What's Changed

• avoid clojure warning by @jtrunick in #25
• Update clojure.yml to include test on java21 by @sovelten in #29
• Make missing key error messages consistent across engines by @aredington in #27
• New engine with support for Virtual threads by @aredington in #30

New Contributors

• @jtrunick made their first contribution in #25

Full Changelog: 1.16.0...1.17.0

Closure Sequences

Sequences present a good opportunity: one can map a function over a collection that is the value of some node, and the mapping will be done consistent with the semantics of the engine selected. e.g. the lazy synchronous engine will map the provided function over all elements serially, while the core.async engine will use clojure.core.async/pipeline to run the mapped function over all of the elements in parallel.

However, it had a major drawback: the function was strictly of one element and must be described at the time the environment is defined; the values of other nodes resolved in the environment could not make their way into the function.

Version 1.16.0 of Nodely introduces support for closing over any named node in the mapped function of a sequence node. This can allow for combining every value of a sequence with some other value in the environment (e.g. generate multiple requests based on a single retrieved customer id). This support is tested in every engine, and, Nodely will be backwards compatible with all prior defined environments.

Note: the internal structure of sequence nodes has changed; all syntactic and data functions are fully backwards compatible, but the function to map over the sequence has moved from being a bare function at the :nodely.data/fn key of a sequence node to being either a Leaf or Value Node at the :nodely.data/process-node key

Synchronous channel return

Allows passing :sync.lazy to nodely.api.v0/eval-key-channel so that the synchronous engine runs and returns its result over a core.async channel.

The evaluation will occur in the core.async "Thread" group to prevent any possible blocking operations from impacting the dispatch thread pool.