Hi Leif, thanks for the feedback!
The use for regex ops is primarily expected to be syntax where greedy is
typically a fine default (and where the sequence length is typically not
long with exact quantification).
You can use the & operator though to add arbitrary predicates around
another regex operator:
;; i1 is greedy here
(def nn (s/cat :i1 (s/+ integer?) :i2 (s/+ integer?)))
(s/conform nn [1 2 3 4 5])
=> {:i1 [1 2 3 4], :i2 [5]}
;; use s/& to bound i1 to length < 3
(def nn' (s/cat :i1 (s/& (s/+ integer?) #(< (count %) 3)) :i2 (s/+
integer?)))
(s/conform nn' [1 2 3 4 5])
=> {:i1 [1 2], :i2 [3 4 5]}
that predicate is arbitrary so could set any occurence operator needed
there. In practice I have been using spec every day for weeks and I have
only occasionally needed anything like this though.
Re the test.check dependency - this will be made more explicit in docs to
come. But fair point.
I have written a lengthy guide with more examples which we'll release
tomorrow. The rationale was not meant to serve as either tutorial docs or
reference material but rather as ... the rationale. :)
On namespaced keywords, there are a couple language changes also on the way
to provide namespaced literal maps (for reading and printing) and
namespaced key destructuring. I expect these will also help in reducing the
typing burden of namespaced keys. See CLJ-1910
<http://dev.clojure.org/jira/browse/CLJ-1910> and CLJ-1919
<http://dev.clojure.org/jira/browse/CLJ-1919>. It's likely these will be
included in alpha2.
On Monday, May 23, 2016 at 10:42:27 PM UTC-5, Leif wrote:
>
> Feedback:
>
> The regex quantifiers seem to be greedy. I suppose that is the standard
> choice, but it would be nice if the docs explicitly said that.
>
> Maybe have a 'rep' macro for exact quantification? My use cases for this
> are short sequences that would be handled just fine by 'cat', so I don't
> really need it. But if someone else needs to specify long-ish but
> fixed-size sequences, or sequences with a specific length range, they
> should speak up now.
>
> The docs should mention that you need to provide your own test.check
> dependency. They do obliquely, but being explicit never hurts.
>
> An example or two under the "Features > Overview > Maps" section would be
> nice. The text makes many good points about the design decisions made for
> map specs, I'd like to see them in action. (I am skeptical that a short
> example would convince me to namespace all my damn map keywords, though
> perhaps you'll lead me down the virtuous path.)
>
> All that said, it looks good and I think I'll have fun trying it out.
> --Leif
>
> On Monday, May 23, 2016 at 10:12:29 AM UTC-4, Rich Hickey wrote:
>>
>> Introducing clojure.spec
>>
>> I'm happy to introduce today clojure.spec, a new core library and support
>> for data and function specifications in Clojure.
>>
>> Better communication
>>
>> Clojure is a dynamic language, and thus far we have relied on
>> documentation or external libraries to explain the use and behavior of
>> functions and libraries. But documentation is difficult to produce, is
>> frequently not maintained, cannot be automatically checked and varies
>> greatly in quality. Specs are expressive and precise. Including spec in
>> Clojure creates a lingua franca with which we can state how our programs
>> work and how to use them.
>>
>> More leverage and power
>>
>> A key advantage of specifications over documentation is the leverage they
>> provide. In particular, specs can be utilized by programs in ways that docs
>> cannot. Defining specs takes effort, and spec aims to maximize the return
>> you get from making that effort. spec gives you tools for leveraging specs
>> in documentation, validation, error reporting, destructuring,
>> instrumentation, test-data generation and generative testing.
>>
>> Improved developer experience
>>
>> Error messages from macros are a perennial challenge for new (and
>> experienced) users of Clojure. specs can be used to conform data in macros
>> instead of using a custom parser. And Clojure's macro expansion will
>> automatically use specs, when present, to explain errors to users. This
>> should result in a greatly improved experience for users when errors occur.
>>
>> More robust software
>>
>> Clojure has always been about simplifying the development of robust
>> software. In all languages, dynamic or not, tests are essential to quality
>> - too many critical properties are not captured by common type systems.
>> spec has been designed from the ground up to directly support generative
>> testing via test.check https://github.com/clojure/test.check. When you
>> use spec you get generative tests for free.
>>
>> Taken together, I think the features of spec demonstrate the ongoing
>> advantages of a powerful dynamic language like Clojure for building robust
>> software - superior expressivity, instrumentation-enhanced REPL-driven
>> development, sophisticated testing and more flexible systems. I encourage
>> you to read the spec rationale and overview
>> http://clojure.org/about/spec. Look for spec's inclusion in the next
>> alpha release of Clojure, within a day or so.
>>
>> Note that spec is still alpha, and some details are likely to change.
>> Feedback welcome.
>>
>> I hope you find spec useful and powerful!
>>
>> Rich
>>
>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
