Re: [core.spec] Stricter map validations?
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 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 ht
Re: [core.spec] Stricter map validations?
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/stuarthalloway/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.
Re: Immutable names of things?
No, this is an excellent idea. Joe Armstrong is probably the most notable modern figure to have written and talked about making code content-addressable, with chunks of code (I forget the granularity he proposed, probably top-levels?) having names as metadata. IIRC, first at https://www.youtube.com/watch?v=lKXe3HUG2l4, then here: https://joearms.github.io/published/2015-03-12-The_web_of_names.html There have been a variety of very niche programming tools that implement some variant of this (a single authoritative identifier for a patch of code or verse or other data structure, with display names being assigned and manipulated separately), but this brings us to the key passage in your message IMO: > The problem is I'm not sure how to do this with a text based programming language And here's the rub: no scheme like this will work or scale in the 80xN grid to which we've confined ourselves. That's IMO of course; I'll save you from opining further, I guess. :-) Projectional / structural editors are absolutely a thing though, so you'll find a lot if you search along those terms. A dedicated (but quiet) subreddit actually popped up on the topic not too long ago: https://www.reddit.com/r/nosyntax/ Have fun, - Chas On Thursday, December 7, 2017 at 12:37:10 AM UTC-5, Didier wrote: > > Warning: This is the spawn of an idea, not very well refined, and that is > little extravagant. > > I've been doing some hammock time, and I've been thinking that names in a > programming language are kind of a complecting of two things, the human > readable form, and the machine identifier. What if a function always had > the same name, which never changed, from the moment the function was > created. This would be fine, until a human finds it didn't like the name > anymore, and thus a refactor of the name would occur, requiring to change > all references to the function. This is also true say of a spec, if you > want to change the name of the spec, its a big refactor to update all usage > of it. So var names and spec names are troubling in that if humans want to > refer to it differently, they also break all machine reference to them. > > So I thought, how awesome would it be if each named things in a > programming language would be given a unique machine name, which can be > used everywhere, and the name you saw was just meta-data for the programmer > to have a more human readable/descriptive name. > > The problem is I'm not sure how to do this with a text based programming > language. I can imagine a language where constructs would be first class, > not based on text, and thus all construct could be assigned a unique id and > a name, and the IDEs could easily hide the unique ids and project a view of > the construct with the human name instead. Code would be stored in a > structured format, and obviously a standard editor would not work, and an > IDE of some form would be required. > > So right now, my idea is that maybe you can compromise. If you added > support for Vars and specs, so that they can have like a doc-name. It would > be like a doc-string a bit, but it expects a name instead. That name could > be the human readable name, you could change it freely. The normal var name > or spec name would continue to be used as normal to refer to this var/spec > from other code. At its most basic it means you can have the normal name be > anything, maybe a name you don't like that much, or you could go further > and make it a guid if you want. Then you could make the doc-name the name > you want to use when talking to other people, or when people read the code. > Now IDEs could support this doc-name, so they could show the doc-name in > place everywhere you have code referring to the normal name. They could > auto-complete from doc-name to normal name, etc. > > So an IDE could still kind of hide this for you, and make it appear like > everything is just doc-name pointing to each other, and refactoring would > not require changing all code that refers to it, but actually its just a > change of the doc-name on the var or spec being pointed to, but the IDE > could quickly replace the new doc-name in place of the normal name > everywhere else. > > Where it would be maybe a bit more confusing, is when using an editor that > would not support doc-names to that extent. In those cases, you can ignore > doc-name, consider it just like one more piece of documentation. > > Doc-name could be optional too, so if you plan on working by yourself, or > just in a simple editor, you can ignore this whole thing and work as normal. > > Now maybe this whole thing is solved by having a powerful renaming > refactoring tool that can hunt for all usage and update the name everywhere > in a sound way, but that's harder to do in Clojure, and still breaks when > its a library for example, as you can't just refactor all consumers without > having both access to their code base, and even if you do, it
[ANN] Clojure/ClojureScript debugging library debux 0.4.0 is out.
* https://github.com/philoskim/debux * https://clojars.org/philoskim/debux -- 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.
Re: Clojure for beginners
On 12/06/2017 02:59 PM, Clojure beginner wrote: Hi all I heard about Clojure a week ago and have a new assignment at work to learn, develope and deploy to production. I haven't developed in 2 years. Programming background is: mainframe and informatica. I have bought 5 books: and Clojure programming, Clojure for brave and true, Clojure in action, programming Clojure, the joy of clojure. I have also been on the main Clojure website. It's been a week and I still don't understand the meat and potatoes. Any recommendations where I can get a walk through of it with real examples. Meat and potatoes and real example, could mean many things. It might be helpful to elaborate a little. Kendall -- 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.
