I don't know if this is a fruitful avenue to pursue, but the Eastwood lint tool [1] uses tools.reader to read Clojure code, and the tools.analyzer library to analyze it, while expanding all macros.
If someone can figure out a way to scan through the Abstract Syntax Tree output of tools.analyzer to detect that such a missing spec seems to be occurring, this is the kind of check that fits right in with Eastwood's goals. Very often, such checks simply involve walking the AST looking for certain types of nodes, or sometimes pairs of parent-child node pairs of particular types, and checking certain properties on those, and/or building up maps of info about names or things of interest. I have never experienced writing a linter where it required understanding all of the possible AST data structures to get the job done. Most of the time is in learning enough about the AST to experiment with some approaches, and then run your linter on as many live examples of code that might use code that can trigger the warning, to 'tune' it in case it creates warnings in cases you don't expect it to. There is currently an issue on Eastwood suggesting using Stuart Halloway's approach to implement a check in Eastwood for what Stuart's code already checks for. I haven't been spending much time on Eastwood development for the last year or so, but if someone gets the itch to want to look into it, let me know and I may be able to give advice. Andy [1] https://github.com/jonase/eastwood [2] https://github.com/jonase/eastwood/issues/237 On Thu, Dec 7, 2017 at 12:28 PM, Ben Brinckerhoff <bhbrinckerh...@gmail.com> wrote: > I ran into a case today where I mistyped the keyword in a `keys` spec and > was surprised that validation was not catching invalid data. For my > purposes, it would be sufficient to have a automated test that looks at my > specs and identifies typos in the spirit of https://gist.github.com/stuart > halloway/f4c4297d344651c99827769e1c3d34e9 > > However, I ran into a problem because my `keys` specs are often generated > by the various multi-methods in a multi-spec. I took a stab at implementing > a version of a "spec linter" that would catch typos in multi-specs, but I > couldn't get anything that worked (at least in Clojurescript, I haven't > tried implementing it in Clojure). > > Is it possible to write a CLJS linter that will catch the missing spec in > the example below? If so, great! If not, I worry that the recommended > approach of adding a linter on top of spec may not be sufficient in this > case. > > (s/def ::name string?) > (defmulti msg :msg-type) > (defmethod msg :greeting [x] > (s/keys :req-un [::name])) > (defmethod msg :count [x] > (s/keys :req-un [::num])) > (s/def ::msg (s/multi-spec msg :msg-type)) > > (I suppose it's always going to be possible to write a linter that walks the > Clojure code and understands the semantics of the above macros, but I was > hoping I could write one using the data contained in the spec registry > instead) > > > Ben > > > On Thursday, November 23, 2017 at 7:09:15 AM UTC-7, Nico Schneider wrote: >> >> Hello everyone, >> >> On Thursday, 16 November 2017 23:29:56 UTC+1, John Newman wrote: >>> >>> [...] when we constrain maps in that closed way, aren't we creating some >>> new subtype of a map, with fundamentally different semantics? If you are >>> going to fully close a map, you might as well use a deftype and make a >>> custom object and not call it a map, right? >>> >> >> Just to add my two cents, I've been following the discussion and this has >> been my thinking for quite some time. Is it not a valid argument? Having a >> validation mechanism pick only certain keys, or ensuring that keys in a map >> are specced, look as trivial to me than other data wrangling we do in >> Clojure. My (preliminary) conclusion in cases like this is to build >> validation tooling around spec, instead of using it directly. >> > -- > 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. > -- 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.
