Nope, ClojureScript uses nested hash maps (try it for yourself here: http://vps124502.vps.ovh.ca/rage/resources/public/). As does tools.analyer. Instaparse and Hiccup use a variant of variants, but funny enough the first thing I ever do when writing code with instaparse is write a converter from it's vector-based parse trees into a nested hashmap AST.
On Tue, Aug 22, 2017 at 7:13 PM, Didier <didi...@gmail.com> wrote: > Ya, I guess the article says that some DSL uses them, like hiccup, so > maybe its only in the perspective of a DSL you'd need to parse, and not > really for modeling business entities. > > Like this: > (s/def ::temp (s/or :one string? > :two int?)) > > Will conform to a variant: > > => (s/conform ::temp "one-two") > [:one "one-two"] > => (s/conform ::temp 12) > [:two 12] > > And not to a tagged record like: > {:tag :one > :val "one-two"} > > But, I don't know, that seems like a different and uncommon use case, I > don't really see this as using a sum type, just describing data to be > parsed, which I guess the vector form can be easier to work with. I think > the clojurescript AST is actually using tagged records, and most people > find it too verbose because of it. > > Anyways, I'd still like to hear if there's a major benefit I'm overseeing, > or a detail I'm not understanding, if any. > > > > P.S.: I figured the difference between (s/or) and (s/multi-spec) I think. > S/or is like structural-types, my example actually doesn't work, because > :filename and :url have the same structure, both string? So conform will > not be able to tell them apart. So if you need to know any kind of semantic > difference which the shape can not infer, (s/or) won't work, you'll need > (s/multi-spec) instead, which are more like nominal-types. Multi-spec I > guess can also use any function to select the appropriate spec, so they're > more powerful, but often I think the way I'm using it will be most common. > > > On Tuesday, 22 August 2017 18:00:21 UTC-7, tbc++ wrote: >> >> I think the article is a bit misleading. Variants were never that popular >> in Clojure. Infact I've never seen them used in production code or the most >> common Clojure libraries. So I'm a bit perplexed as to why the article >> recommends them so strongly. >> >> So I think the answer is, they are a fun thought experiment in Clojure, >> but are of limited usefulness due to the tools we have available that make >> them unneeded. >> >> It's a bit like recommending that new users use actors in Clojure. Sure, >> you can shoehorn them in, but there's a reason why they aren't the default. >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.