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> 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> 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> 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 >> 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. > > > -- > 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.
