This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-28
Channels
- # aws (7)
- # beginners (69)
- # boot (67)
- # cider (9)
- # cljs-dev (159)
- # cljsrn (2)
- # clojars (25)
- # clojure (345)
- # clojure-austin (9)
- # clojure-berlin (1)
- # clojure-dusseldorf (10)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (73)
- # clojure-uk (59)
- # clojurescript (163)
- # clojurewerkz (1)
- # component (26)
- # core-matrix (2)
- # cursive (20)
- # datascript (32)
- # datomic (15)
- # dirac (16)
- # emacs (3)
- # hoplon (35)
- # jobs-discuss (87)
- # jobs-rus (95)
- # luminus (15)
- # om (135)
- # om-next (3)
- # onyx (47)
- # pedestal (67)
- # perun (74)
- # play-clj (4)
- # portland-or (1)
- # proton (4)
- # re-frame (13)
- # reagent (18)
- # remote-jobs (17)
- # rum (20)
- # specter (11)
- # untangled (101)
- # yada (18)
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
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/
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?
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.
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 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?
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.
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)
> 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
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
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.
i find the derivative of a grammar to make sense, but the derivative of a parser makes my brain hurt
https://github.com/cgrand/seqexp/blob/master/src/net/cgrand/seqexp.clj#L178-L198 I don't fully understand it š