Oh, I thought alt was something else on Mac, is it not?

It is sometimes/often labeled option, but it is aka alt.

This has confused some Mac users, because they do not find the alt key on their keyboards. So it is good to be aware of.

I've been a mac user for ... a while, and to this day I get mixed up with what keys are to be found on which keyboards 😛

It gets especially weird when apps start swapping around control with command

I was actually trying out option+enter (windows equivalent: alt+enter earlier today. I was trying to use that to load the whole comment block, vars and all, into the REPL. There may be a bug, or maybe I don't understand the command fully, but if I try it with this code for example, I get Unable to resolve symbol: hey in this context

(comment
    (def hey "hey")
    (def wat "wat")
    (str hey wat))

Thus requiring me to go through each form, load it into the REPL, and then evaluate (str hey wat) at the end.

So if you actually evaluate the whole comment form it doesn't evaluate any of the forms inside it. That's basically the point of it. When you use a comment form as a playground you need to evaluate each form inside it individually. In Calva, alt+enter if inside a form inside a comment form, will evaluate the top level form inside the comment.

So if you put your cursor in the first def like here: (def |hey "hey") and hit alt-enter the whole def form there will be evaluated, not the outer comment form.

It follows usual evaluation rules from within the comment form.

So if you wanted to eval all those defs at once for some reason, you could put them inside a do

Usually you'd be working with individual forms though. Maybe you want to try some code that has var names in it already - instead of using individual defs you could use one let.

(let [hey "hey"
        wat "wat"]
    (str hey wat))

Just want to add about the top-level evaluation inside comment forms. The way it is designed is that the comment form creates a new top level context. Let’s look at your example, @andyfry01:

(comment
    (def hey "hey")
    (def wat "wat")
    (str hey w|at))

(def hey "hey")
(def wat "wat")
(str hey w|at)

(comment
    (def hey "hey")
    (def wat "wat")
    (str hey w|at))

(def hey "hey")
(def wat "wat")
(str hey w|at)

(comment
  (do
    (def hey "hey")
    (def wat "wat")
    (str hey w|at)))

Ah, that's a really interesting way to think about comment: a new top-level context. Like a namespace inside a namespace, where you can get the advantage of using all of the other vars which are defined in the parent namespace, but you don't have to worry about anything in the comment form interfering with the parent namespace. I can dig that. Block scoped variables in ES6 Javascript is the parallel that springs to mind right away:

const parentNamespace = () => {
    const variable = "Hello from the outer context"

    const richComment = () => {
        const variable = "Hello from the inner context"
        console.log(variable) 
    }
    
    richComment() // -> "Hello from the inner context"
    console.log(variable)
}

parentNamespace() // -> "Hello from the outer context"

And yeah, I can see the benefit of defining and loading individual vars within a comment form as opposed to loading the whole comment form all at once. I'll give that do thing a try when I've got some setup code that I want to run all at once.

You guys have been invaluable this month for my Clojure growing pains 😅 Thanks so much for all of the tips, it's really improving my workflow

You are most welcome, sir!

About namespacing. Note that this is only a structural thing regarding the text in the file. When you evaluate something in the comment block it will both be “from” the same namespace as the file and “to” the same namespace. So hey will be defined in the file’s namespace. Don’t know if you meant anything else, but just in case. 😃

Looking at your ES6 example it seems like my clarification was needed. Haha.

Clojure has global bindings that can be scoped by namespaces, and local bindings that are lexically scoped, much like the ES6 example there.

> the thing is that if we didn’t treat `comment` forms special at all what would be evaluated is the whole `comment` form (not just it’s content) and that would give you `nil`. Just to clarify here, and maybe Peter meant this, but if the whole comment form is evaluated, the result is nil and none of the forms inside it are evaluated.

So if you have defs in there and they haven't been evaluated, and you evaluate the whole comment form, those vars will still not be defined.