Think about values first, symbols after. Symbols are accessory, not values, values are the only things that exist at runtime.
Symbols are only there for you poor human (I include myself in this statement) to grasp roughly what is going on by tracking intermediate values with names. The names you choose are irrelevant except for your own comprehension. There are no containers per se that you can alter transparently. Some special constructs (atoms, ...) allow you to persist other values, obviously you need to name these constructs but they are not symbols, they are a special kind of value. Your code will need the value they persist, not the construct itself. (swap! is of limited interest if you never refer to the atom value). Top level vars are like the universe of values where your code will operate, a frame. Once set vars do not change. (Ok, some may use alter root but it should be reserved to specific occasions). It's all about values. This is the semantic shift compared to most languages. I do not even think about the underlying objects supporting values in Clojure unless I need to (extending with protocols, type hints, weird stack traces, ...). Implementation details :) As for interop, you enter the mutable world and the familiar rules apply here. The above 'cosmology' sums up how I think when I dive into some Clojure code and it works 99.5% of the time. There's no confusion. Luc P. > On 12/02/2015 01:53, Ben Wolfson wrote: > > The multiple-binding form of let can be recursively transformed into > > nested lets: > > > > (let [name1 value1 name2 value2 ... name value] body) > > ----> > > (let [name1 value1] (let [name2 value2] ... (let [name value] body))) > > > > All you're doing with your let form is shadowing the name; there's no > > mutation. If you had something like this: > > > > (let [x 1] > > (let [x (inc x)] > > (println x)) ;; prints 2 > > (println x)) ;; prints 1 > > > > it would be more obvious; it's less apparent in your case because > > there's no room for the extra forms. > > > > That explains it but I think Clojure's syntax is misleading here. > Without knowledge of this magic the mind doesn't readily translate: > > (let [x 1 > x (inc x) > x (inc x) > x (inc x)] > x) > > > .... into: > > (let [x 1] > (let [x (inc x)] > (let [x (inc x)] > (let [x (inc x)] > x)))) > > The single bracket pair in the original leads the unwitting newcomer to > assume all the x'es are in the same scope. > > gvim > > > > > > > -- > 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. > -- Luc Préfontaine<lprefonta...@softaddicts.ca> sent by ibisMail! -- 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.
