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