Clojure 1.9 by Alex Miller.
From the post:
Clojure 1.9 is now available!
Clojure 1.9 introduces two major new features: integration with spec and command line tools.
spec (rationale, guide) is a library for describing the structure of data and functions with support for:
- Validation
- Error reporting
- Destructuring
- Instrumentation
- Test-data generation
- Generative test generation
- Documentation
Clojure integrates spec via two new libraries (still in alpha):
- spec.alpha – spec implementation
- core.specs.alpha – specifications for Clojure itself
This modularization facilitates refinement of spec separate from the Clojure release cycle.
The command line tools (getting started, guide, reference) provide:
- Quick and easy install
- Clojure REPL and runner
- Use of Maven and local dependencies
- A functional API for classpath management (tools.deps.alpha)
The installer is available for Mac developers in brew, for Linux users in a script, and for more platforms in the future.
Being interested in documentation, I followed the link to spec rationale and found:
…
Map specs should be of keysets onlyMost systems for specifying structures conflate the specification of the key set (e.g. of keys in a map, fields in an object) with the specification of the values designated by those keys. I.e. in such approaches the schema for a map might say :a-key’s type is x-type and :b-key’s type is y-type. This is a major source of rigidity and redundancy.
In Clojure we gain power by dynamically composing, merging and building up maps. We routinely deal with optional and partial data, data produced by unreliable external sources, dynamic queries etc. These maps represent various sets, subsets, intersections and unions of the same keys, and in general ought to have the same semantic for the same key wherever it is used. Defining specifications of every subset/union/intersection, and then redundantly stating the semantic of each key is both an antipattern and unworkable in the most dynamic cases.
…
Decomplect maps/keys/values
Keep map (keyset) specs separate from attribute (key→value) specs. Encourage and support attribute-granularity specs of namespaced keyword to value-spec. Combining keys into sets (to specify maps) becomes orthogonal, and checking becomes possible in the fully-dynamic case, i.e. even when no map spec is present, attributes (key-values) can be checked.
…
Sets (maps) are about membership, that’s it
As per above, maps defining the details of the values at their keys is a fundamental complecting of concerns that will not be supported. Map specs detail required/optional keys (i.e. set membership things) and keyword/attr/value semantics are independent. Map checking is two-phase, required key presence then key/value conformance. The latter can be done even when the (namespace-qualified) keys present at runtime are not in the map spec. This is vital for composition and dynamicity.
…
The idea of checking keys separate from their values strikes me as a valuable idea for processing of topic maps.
Keys not allowed in a topic or proxy, could signal an error, as in authoring, could be silently discarded depending upon your processing goals, or could be maintained while not considered or processed for merging purposes.
Thoughts?