Re: what does (seq) in zipmap do?
I can't answer for the author, but the answer you gave would be a good
sufficient reason to call seq in those places, yes?
If you create a function zipmap2 that is identical to zipmap, except it
does not have any calls to seq, you get these results:
user=> (zipmap [] [1])
{}
user=> (zipmap2 [] [1])
{nil 1}
I definitely think the former result makes more sense than the latter does.
If you are thinking that it would be better to have the calls to seq in the
if condition, that would be at least a little bit slower than the current
implementation, as it would have 2 additional calls to seq for every
iteration through the loop.
Andy
On Tue, Nov 29, 2016 at 7:42 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:
> I apologize for this question, because I think it has been asked before,
> and yet I can not find the answer.
>
> In the definition of zipmap, what do these 2 lines do?
>
> ks (seq keys)
> vs (seq vals)
>
> In particular, what is (seq) doing? Is this to ensure that ks is false if
> "keys" is empty? And vs is false if "vals" is empty? Because an empty list
> (or vector) is truthy but we want it to be falsey in this situation?
>
> Is there any other reason to use (seq), other than to set the
> truthy/falsey values of ks and vs?
>
>
> (defn zipmap
> "Returns a map with the keys mapped to the corresponding vals."
> {:added "1.0"
> :static true}
> [keys vals]
> (loop [map {}
> ks (seq keys)
> vs (seq vals)]
> (if (and ks vs)
> (recur (assoc map (first ks) (first vs))
> (next ks)
> (next vs))
> map)))
>
> --
> 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.
what does (seq) in zipmap do?
I apologize for this question, because I think it has been asked before,
and yet I can not find the answer.
In the definition of zipmap, what do these 2 lines do?
ks (seq keys)
vs (seq vals)
In particular, what is (seq) doing? Is this to ensure that ks is false if
"keys" is empty? And vs is false if "vals" is empty? Because an empty list
(or vector) is truthy but we want it to be falsey in this situation?
Is there any other reason to use (seq), other than to set the truthy/falsey
values of ks and vs?
(defn zipmap
"Returns a map with the keys mapped to the corresponding vals."
{:added "1.0"
:static true}
[keys vals]
(loop [map {}
ks (seq keys)
vs (seq vals)]
(if (and ks vs)
(recur (assoc map (first ks) (first vs))
(next ks)
(next vs))
map)))
--
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: s/def: Rationale, tradeoffs? When to emulate this pattern?
Thanks for the responses. One reason might be that with var-bound specs, one could not precisely report the the path to the failing spec. If spec composition is achieved through var resolution, than that name is gone by the time the spec datastructure is composed. On Tue, Nov 29, 2016 at 3:05 PM, Alex Miller wrote: > Answers below are my perspective. I have no doubt that Rich would give you > better ones. :) > > On Tuesday, November 29, 2016 at 1:55:59 PM UTC-6, Leon Grapenthin wrote: >> >> While I can follow "we have namespaced names" I find it difficult to >> follow "too much stuff onto vars and var meta". I feel this is what OP is >> asking for. >> >> - What is meant by "too much"? >> > > More than we have now. > > >> When is var metadata "too much"? >> > > Var meta gets compiled into the bytecode. This affects compiled code size > and more importantly loading time. Also related to load time are vars which > are loaded and initialized when a namespace is loaded. These are real costs > that affect startup and load times. > > >> - What problem can/did result from "too much"? >> > > Load time. Compiled code size. Abusing vars as "the one place to hang > everything". > > >> - Why is this assumed limitation always stated as primary motivation? Are >> there not other reasons like enabling non var-tied specs like for keywords? >> > > I don't understand the question. When you have namespaced names, you can > create many registries for different purposes and stop using vars as The > Registry. There may be other things that could be "registries" as well, > rather than being tied only to vars. > > >> - Have s/fdefs been considered for vars? What is the reason/intended use >> for s/fdefs in the global registry? >> > > Same reasons, same answers. > > >> >> Kind regards, >> Leon >> >> On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote: >>> >>> At the risk of repeating what you already said, we are pushing too much >>> stuff onto vars and var meta. We have namespaced names so there's no reason >>> to push more stuff into vars and we can use an independent registry. >>> >>> >>> On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote: Spec is surprisingly easy to grok given how much it does. s/def jumped out at me as an out-of-the-box choice, that I could not immediately rationalize. So I'm wondering: why not just use standard def? What does one gain/lose? This is not just an academic question. Lots of people like me look at Clojure's APIs as an example to follow, so now I'm wondering when I should make the same choice. I asked Rich about this at the Lisp NYC meetup, the response was to the effect of "vars are already overloaded, lets use a separate database", which makes sense but the implications of that are not clicking. -- > 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.
Re: s/def: Rationale, tradeoffs? When to emulate this pattern?
Answers below are my perspective. I have no doubt that Rich would give you better ones. :) On Tuesday, November 29, 2016 at 1:55:59 PM UTC-6, Leon Grapenthin wrote: > > While I can follow "we have namespaced names" I find it difficult to > follow "too much stuff onto vars and var meta". I feel this is what OP is > asking for. > > - What is meant by "too much"? > More than we have now. > When is var metadata "too much"? > Var meta gets compiled into the bytecode. This affects compiled code size and more importantly loading time. Also related to load time are vars which are loaded and initialized when a namespace is loaded. These are real costs that affect startup and load times. > - What problem can/did result from "too much"? > Load time. Compiled code size. Abusing vars as "the one place to hang everything". > - Why is this assumed limitation always stated as primary motivation? Are > there not other reasons like enabling non var-tied specs like for keywords? > I don't understand the question. When you have namespaced names, you can create many registries for different purposes and stop using vars as The Registry. There may be other things that could be "registries" as well, rather than being tied only to vars. > - Have s/fdefs been considered for vars? What is the reason/intended use > for s/fdefs in the global registry? > Same reasons, same answers. > > Kind regards, > Leon > > On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote: >> >> At the risk of repeating what you already said, we are pushing too much >> stuff onto vars and var meta. We have namespaced names so there's no reason >> to push more stuff into vars and we can use an independent registry. >> >> >> On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote: >>> >>> Spec is surprisingly easy to grok given how much it does. >>> >>> s/def jumped out at me as an out-of-the-box choice, that I could not >>> immediately rationalize. >>> >>> So I'm wondering: why not just use standard def? What does one gain/lose? >>> >>> This is not just an academic question. Lots of people like me look at >>> Clojure's APIs as an example to follow, so now I'm wondering when I should >>> make the same choice. >>> >>> I asked Rich about this at the Lisp NYC meetup, the response was to the >>> effect of "vars are already overloaded, lets use a separate database", >>> which makes sense but the implications of that are not clicking. >>> >>> >>> >>> >>> -- 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: s/def: Rationale, tradeoffs? When to emulate this pattern?
While I can follow "we have namespaced names" I find it difficult to follow "too much stuff onto vars and var meta". I feel this is what OP is asking for. - What is meant by "too much"? When is var metadata "too much"? - What problem can/did result from "too much"? - Why is this assumed limitation always stated as primary motivation? Are there not other reasons like enabling non var-tied specs like for keywords? - Have s/fdefs been considered for vars? What is the reason/intended use for s/fdefs in the global registry? Kind regards, Leon On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote: > > At the risk of repeating what you already said, we are pushing too much > stuff onto vars and var meta. We have namespaced names so there's no reason > to push more stuff into vars and we can use an independent registry. > > > On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote: >> >> Spec is surprisingly easy to grok given how much it does. >> >> s/def jumped out at me as an out-of-the-box choice, that I could not >> immediately rationalize. >> >> So I'm wondering: why not just use standard def? What does one gain/lose? >> >> This is not just an academic question. Lots of people like me look at >> Clojure's APIs as an example to follow, so now I'm wondering when I should >> make the same choice. >> >> I asked Rich about this at the Lisp NYC meetup, the response was to the >> effect of "vars are already overloaded, lets use a separate database", >> which makes sense but the implications of that are not clicking. >> >> >> >> >> -- 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: s/def: Rationale, tradeoffs? When to emulate this pattern?
The registry is stored in a global atom which is usually considered an anti-pattern in library code. It makes sense here though, based on the idea that global conflicts are avoided by namespaced keywords. What bothers me though is reloadability. When I hit clojure.tools.namespace.repl/reload-all, I potentially end up with zombie specs which can have unexpected effects (note s/keys allows undefed kws). Not wanting to hijack this thread, but is this gonna be resolved in ctn or somehow? Kind regards, Leon. On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote: > > At the risk of repeating what you already said, we are pushing too much > stuff onto vars and var meta. We have namespaced names so there's no reason > to push more stuff into vars and we can use an independent registry. > > > On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote: >> >> Spec is surprisingly easy to grok given how much it does. >> >> s/def jumped out at me as an out-of-the-box choice, that I could not >> immediately rationalize. >> >> So I'm wondering: why not just use standard def? What does one gain/lose? >> >> This is not just an academic question. Lots of people like me look at >> Clojure's APIs as an example to follow, so now I'm wondering when I should >> make the same choice. >> >> I asked Rich about this at the Lisp NYC meetup, the response was to the >> effect of "vars are already overloaded, lets use a separate database", >> which makes sense but the implications of that are not clicking. >> >> >> >> >> -- 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: s/def: Rationale, tradeoffs? When to emulate this pattern?
At the risk of repeating what you already said, we are pushing too much stuff onto vars and var meta. We have namespaced names so there's no reason to push more stuff into vars and we can use an independent registry. On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote: > > Spec is surprisingly easy to grok given how much it does. > > s/def jumped out at me as an out-of-the-box choice, that I could not > immediately rationalize. > > So I'm wondering: why not just use standard def? What does one gain/lose? > > This is not just an academic question. Lots of people like me look at > Clojure's APIs as an example to follow, so now I'm wondering when I should > make the same choice. > > I asked Rich about this at the Lisp NYC meetup, the response was to the > effect of "vars are already overloaded, lets use a separate database", > which makes sense but the implications of that are not clicking. > > > > > -- 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.
s/def: Rationale, tradeoffs? When to emulate this pattern?
Spec is surprisingly easy to grok given how much it does. s/def jumped out at me as an out-of-the-box choice, that I could not immediately rationalize. So I'm wondering: why not just use standard def? What does one gain/lose? This is not just an academic question. Lots of people like me look at Clojure's APIs as an example to follow, so now I'm wondering when I should make the same choice. I asked Rich about this at the Lisp NYC meetup, the response was to the effect of "vars are already overloaded, lets use a separate database", which makes sense but the implications of that are not clicking. -- 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.
