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.

Reply via email to