I'm reading on http://www.lispcast.com/reduce-complexity-with-variants and
have seen Jeanine's talk on her encoding scheme for sum types, but for some
reason, I'm not convinced of the benefit over a tagged record encoding. I
see that the positional vector or hash-map suggested in the lispcast
a
I find the arguments for variants very unconvincing. As you stated with
specs and s/keys you can spec the same sort of data, and in a way that's
much more open-ended.
For example:
[:person {:name "Tim" :grade "B"}]
What is the type of this data? We would probably guess a :person. But what
if we
On 22 August 2017 at 23:04, Timothy Baldridge wrote:
> I find the arguments for variants very unconvincing. As you stated with
> specs and s/keys you can spec the same sort of data, and in a way that's
> much more open-ended.
>
> For example:
>
> [:person {:name "Tim" :grade "B"}]
>
> What is the
Great, so these approaches are suggesting we wrap every value in a vector
or a hash map (as the lisp cast article does). That doesn't really help
much at all. Why is:
[[:image/name "img.png"]
[:encode/width 42]
[:encode/height 33]]
Any better than
{:image/name "img.png"
:encode/width 42
:enc
Right, I see things the way tbc++ does, but I'm wondering if I'm missing
some key insights that make variants better.
I similarly struggle with the difference between (s/or) and (s/multi-spec).
If I were to implement the lispcast example today with spec I'd either use
(s/or):
(s/def ::image-ty
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
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/conf
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
I think part of the issue is that the article dates back to mid-2015 and
`clojure.spec` wasn’t a thing back then, was it?
Variants feel like a solution to a problem for which we have a much better
solution _today_ than we did two years ago. The article talks about using
core.typed and core.matc
I think that's true, but even back in 2015, these were the only two sources
calling for this approach, and it never really caught on. I even did some
experiments with it, but my conclusion was that it was more trouble than it
was worth.
On Tue, Aug 22, 2017 at 7:46 PM, Sean Corfield wrote:
> I t
On 23 August 2017 at 01:18, Timothy Baldridge wrote:
> Great, so these approaches are suggesting we wrap every value in a vector
> or a hash map (as the lisp cast article does).
>
What? No, that's not what I'm saying at all.
If you have an unordered collection of key/value pairs where every key
I can see it be quick and concise for representing events, but that's also
exactly the use case example for
multi-spec: https://clojure.org/guides/spec#_multi_spec
What happens if your event needs more data? Maybe draw needs 2 attributes,
the card and the deck? Now you have implicit encoding, w
Put let's take that and look at it under a engineering lens a bit:
>> For example, a series of events that represent a player's moves in a
card game:
>>
>> [:card/draw :9h]
You have an ad-hoc encoding of data here now. Expand it out a bit, and make
it machine readable instead of preferring ease
On 23 August 2017 at 03:48, Didier wrote:
> I can see it be quick and concise for representing events, but that's also
> exactly the use case example for multi-spec: https://clojure.
> org/guides/spec#_multi_spec
>
> What happens if your event needs more data? Maybe draw needs 2 attributes,
> the
But Datomic has E in [e a v] which links multiple [a v] pairs into an
entity...which is basically a map. So I don't think that applies here.
GET /example HTTP/1.1
Host: www.example.com
[:request/method :get]
[:request/uri "/example"]
[:request/protocol "HTTP/1.1"]
[:request/header ["h
On 23 August 2017 at 03:58, Timothy Baldridge wrote:
> Put let's take that and look at it under a engineering lens a bit:
>
> >> For example, a series of events that represent a player's moves in a
> card game:
> >>
> >> [:card/draw :9h]
>
> You have an ad-hoc encoding of data here now. Expand i
Simple: because failing to put it in a map constrains future growth.
Putting things into a set restricts you to unique values. Putting values
into a vector constrains you to a specific ordering. And quite frankly one
little mistake like this can cause tons of refactoring down the road.
Better to w
Thanks. I hadn't thought of (apply > ...) - nice!
On Sunday, August 20, 2017 at 5:55:01 PM UTC-7, Ghadi Shayban wrote:
>
> You have the right idea with s/and. I would name & defn the predicate to
> something meaningful like increasing?. Defining and thus naming it is
> essential so that you c
On 23 August 2017 at 04:27, Timothy Baldridge wrote:
> But Datomic has E in [e a v] which links multiple [a v] pairs into an
> entity...which is basically a map. So I don't think that applies here.
>
Except that [e a v t] facts in Datomic are ordered and not necessarily
unique, and that's my par
On 23 August 2017 at 05:15, Timothy Baldridge wrote:
> Simple: because failing to put it in a map constrains future growth.
>
Sometimes that's what you want. A constrained function is a simple function.
Should (find {:a 1} :a) produce {:key :a, :val 1} instead of [:a 1]? No,
because it doesn't
20 matches
Mail list logo
