Sure - but if I saw a reference (no pun intended) to ‘shopping-cart’ I would expect that to be stateful. Fns which take something and return something else I tend to name `something->something-else`. In other words, I am unlikely to have a var whose name is a lower-case noun that isn’t state.
It is interesting to me, now I think about it that I have seen a few syntactical style guides but no semantic style guides for Clojure. This question suggests we need one…. > On 7 Dec 2015, at 09:41, Mark Engelberg <mark.engelb...@gmail.com> wrote: > > On the contrary, I find that when I have something in my app like a > shopping-cart, there are usually two flavors of functions. On the one hand, > there will be helper functions that take an immutable shopping-cart and > return a new immutable shopping-cart. But on the other hand, there will also > be a few functions that manipulate the actual stateful atom/ref containing > the immutable shopping-cart. > > I can see how some sort of convention might be handy to distinguish, at a > glance, whether a function takes the immutable or stateful version of > shopping-cart by some symbol in the name of the input. > > > On Mon, Dec 7, 2015 at 12:37 AM, Colin Yates <colin.ya...@gmail.com > <mailto:colin.ya...@gmail.com>> wrote: > +1. > > I haven’t done an extensive study, but I am sure all of my atoms’s stand out > from other fns/vars because the name makes it obvious. For example, > ‘shopping-cart’ can _only_ sensibly be state which can only be an atom. > > Having said that, if I had mixed refs and atoms then I might consider > splitting those, but in general I find it obvious and intuitive when looking > through past code which are atoms and which are fns/vars. > > Might just be me though :-). > >> On 7 Dec 2015, at 08:26, Daniel Kersten <dkers...@gmail.com >> <mailto:dkers...@gmail.com>> wrote: >> >> I personally don't like this. >> >> An atom won't suddenly change value without your knowledge because to get >> its value, you must use @ or deref (which should be a big warning that, yes, >> this value might change between calls to deref). >> >> Adding sigils, in my opinion, adds to the noise and makes it harder to read. >> I personally find sigils to be a noisy mistake in other languages (perl, php >> etc) and in my opinion you can get more benefit through a suitable naming >> convention such as a -state prefix, eg: foo-state >> >> I think, mainly my dislike for sigils is on variables and not so much on >> functions as I'm ok with foo? being a predicate and foo! being unsafe in >> STM. I think that's because they tell you useful meta information about what >> the function does, but to use a variable, I already have to know what data >> it's representing in order to call the correct functions on it and >> annotating it with sigils doesn't help much (unless perhaps you go full >> blown Hungarian notation, but even that isn't rich enough to adequately >> describe the nested data structures we use in Clojure - good descriptive >> variable names are much better at conveying content and purpose). >> >> I guess it may largely just be personal taste, although I would also take >> the wider community into account: there's a lot of code out there not using >> this convention - will that become confusing if you rely on symbols to tell >> you that a variable is an atom? >> On Mon 7 Dec 2015 at 00:27 Mars0i <marsh...@logical.net >> <mailto:marsh...@logical.net>> wrote: >> On Sunday, December 6, 2015 at 5:52:02 PM UTC-6, Glen Mailer wrote: >> I saw some sample code that prefixed the atom name with a ! recently, seemed >> to look sensible to me. >> (swap! !state conj :whatever) >> >> And so on. >> >> >> This idea is conceptually elegant, since the marker, !, is the same as the >> related function suffix. >> >> I worry that having two bangs with a space between them, as in the swap! >> example above, is a little bit visually confusing. Also, I wonder whether >> placing @ next two another non-alphanumeric character is visually confusing >> or messy. >> >> As an experiment, I just started using & as a suffix for variables whose >> values are atoms.: >> (def state& (atom 1)) >> (swap! state& inc) >> @state& >> >> Using only a suffix character means that you don't have a punctuation >> character next to @, which I prefer. >> >> (I wouldn't want to use ! as the suffix for variables that are not >> functions, though. (swap! state! inc) potentially very confusing. It's not >> that someone reading it couldn't figure it out, but if I saw that, I'd have >> to think for a second, and then keep remembering that state! is not a >> function.) >> >> It occurred to me that I've seen both & and $ used in some languages to >> suggest pointer dereferencing, so there's some vague harmony to using one of >> them as indicators as markers of statefulness. "Ampersand" sounds vaguely >> like "atom". If one wanted to have separate marker characters for atoms, >> refs, and agents, maybe & is a good choice for atoms. Not sure it's >> necessary to have different conventions for these three distinct uses, >> though. >> >> -- >> 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 >> <mailto: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 >> <mailto:clojure%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> <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 >> <mailto:clojure+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 >> <mailto: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 >> <mailto:clojure+unsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> <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 >> <mailto:clojure+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto: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 > <mailto:clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > <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 > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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 > <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 > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
