when writing variations of an existing spec, such as "order" -> "open order", "closed order", should there be a convention for how to name the namespace part of a spec

right now I tend to define order as ::order and then for the variations I add the variation name after a dot to the end of the namespace, so :my.ns.closed/order

I do this without creating a new namespace, i.e. I just write the full keyword out for the variations

@luxbock Another option would be ::order.closed. That way you can still use the real namespace and thus the auto resolving shortcut syntax.

@dergutemoritz yeah but then I can't use use it as an unqualified key in a map

my use case is basically where there are a series of transformations on this value in a map, and I want to capture some properties about the transformations having done what they were supposed to

Oh okay, if you are specing legacy maps, I wouldn't know what's the best way to go about that

I think using unqualified keywords is the only way to do this type of thing, where I want to capture changes in the value between functions

if I were to use a qualified keyword for the map then the spec has to be static

Note that you can also create and alias a namespace from within another namespace like this: (create-ns 'my.ns.closed) (alias 'closed 'my.ns.closed) which then allows you to require the my.ns.closed namespace from other namespaces and use it in the current namespace via ::closed/

hmm yeah that could be another good option

Re capturing changes in the value between functions: One central idea of spec is to not use the same key for different kinds of values but to attach a global meaning to a key - so different things should use different keys

Maybe you can do that, too

In other words: what's keeping you from using different keys?

yeah I suppose that might be a better a better practice

Worth a try at least 🙂

I was thinking that since all of the values that are changed only live during one pass from a function to another, the use of unqualified keys would capture this transient nature of theirs

Sounds like you have a deep chain of calls which pass a map through each other, each modifying that map? From a maintenance perspective, I think using different keys makes sense here, too. Imagine reading that code for the first time, you'd see the same keys being used in a dozen functions but in each they may have very different values, depending on from where they're called.

yeah I think you are right

Well, it might be easier with un specs but still unnecessarily context sensitive I'd think

@viebel have also looked for easy way to define more local key specs. Did a simple helper on top of spec to define deeply nested map/vector/set specs. But currently pollutes the spec registry with generated keys: https://github.com/metosin/spec-tools#simple-collection-specs. There could be a custom keys in spec-tools supporting local keys..

@dergutemoritz re the earlier suggestion of ::order.closed - per https://clojure.org/reference/reader#_literals, keywords should not contain . in the name. This is not enforced anywhere, but I think you should steer away from it in general.

@alexmiller Ah, thanks for the hint! Yeah it's not enforced anywhere in my experience, I'd rather not rely too heavily on unspecified behavior so the headsup is definitely welcome

I know spec does not check “unspecced" keywords for a number of reasons. But sometimes it would be very handy to check big nested map (eg. re-frame app-db) and get the keys that are not specced so that I can add specs for them. Is there any way of enumerating the registered specs?

@vikeri instrument etc does this - so you can probably look at how those work

@bbloom Ok thanks!

@vikeri you can call s/get-spec to check whether a spec is in the registry

Many Clojure features are based on some past research/books/papers. Is there a list of these for Clojure spec?

I’ve seen http://matt.might.net/papers/might2011derivatives.pdf

from David Nolen @ http://swannodette.github.io/2016/06/03/tools-for-thought

there are a couple of references in https://clojure.org/about/spec

quoted: > clojure.spec takes "Matt Might et. al. Parsing with Derivatives" and really, really runs with it.

RDF and Racket contracts

I’ve seen those too, but I wasn’t sure on which aspects of those and if how it related to the parsing stuff

the parsing stuff is specific to the regex op specs

but thanks for reminding me that those were at the bottom of the about spec page - I forgot

contracts are at a high level similar to what spec is doing

the rdf reference is really about building growable information systems (Datomic steals liberally from this as well)

Rich is being somewhat modest imo in that he’s been thinking about some of the parts for as long as he’s been working on Clojure (like maps as a set of attributes)

Thanks for that added insight Alex.

> the parsing stuff is specific to the regex op specs Does this mean that "Matt Might et. al. Parsing with Derivatives” is not really relevant to an understanding?

only about understanding that very specific part of the code

I do intend to dig into the parsing of spec some out of interest in what it is doing. I was just wondering if reading that paper would have any relationship. I’ve read a bit of it so far.

I know spec has more to it than parsing of course. I can understand how the RDF is about the growable systems and Racket contracts as a similar lang feature.

there’s very little “parsing” - the only part doing anything you’d call parsing is the regex stuff

everything in spec works on Clojure data, not strings

Yeah, I have seen that much.

we looked at a lot of other existing libs in the research for this (I built a couple versions prior to Rich’s work that were thrown away)

of those, I would point most at Christophe’s seqexp lib, which is really quite lovely

https://github.com/cgrand/seqexp

and Ghadi’s pex is similarly interesting https://github.com/ghadishayban/pex

spec does not take either of those approaches, but they were helpful as points in the design space

I’d say the ideas of a) starting from predicates and b) automatically generative from the start are also things that Rich insisted on from the very first conversation

Thanks for all the details. That’s good background info. It’s always good to get to hear some of the thought process behind these sorts of things to understand the design process some.

If I were to rewrite pex, I'd globally register match patterns like spec does.

@ghadi still happy with the bytecode interpreter approach?

i’ve tried to do some parsing with derivatives and have had pretty poor luck

i find the derivative of a grammar to make sense, but the derivative of a parser makes my brain hurt

bytecode interpreter is super fast and I love it

but -- I didn't implement a stack overflow guard

¯\(ツ)/¯

I am not 100% sold on registers vs locals though. @cgrand did registers in segexp

https://github.com/cgrand/seqexp/blob/master/src/net/cgrand/seqexp.clj#L178-L198 I don't fully understand it 😃

am i reading that right? only two registers?

No N registers of two slots

what are the slots?

Each end of a sub match.

ah - gotcha

parsing is fun/terrible 🙂

The goal was to avoid head retention

like for streaming parsing? assuming you don’t have unbounded backtracking in your grammar?

Yup

I use it to query live healthcare data streams.