4 ms·

> simply because there is absolutely no ambiguity between a > function named LIST and a variable named LIST. To a machine, correct. To a human, this is no

> simply because there is absolutely no ambiguity between a > function named LIST and a variable named LIST. To a machine, correct. To a human, this is not always the case. > But then you can't access p:foo anymore. That's why > "Anytime you use a shadowed symbol, qualify it with a > namespace" is a strange thing to say under the CL notion > of shadowing symbols, because by definition the symbol > that was shadowed is uninterned and not accessible > anymore, except if you manage to keep a reference to it > or store a value that was bound to it in some namespace. Of course the machine knows what you mean. I never denied this. But when you're in a massive file fixing a 15 year old bug this information becomes less clear and you're going to appreciate a fully-qualified name. If you have two namespaces providing the same symbol, qualify which one you mean. This is true in just about any language. The meaning of the code is painfully obvious to the human who has to maintain it. Even if you can keep track of it without any issues, assume the maintainer is totally inept and can't. Names are important, take the time to get them right. EDIT: Also adding I was using the term `shadowing` somewhat sloppily. Names are important enough that anytime one is being used in more than one way we should take great precaution.

junke 10y ago
I don't object using fully qualified symbols to distinguish packages for the benefits of human readers. I care about human readers as much as you, don't worry about that. I am not talking about different symbols which happen to share the same name (in different packages), but about the different meanings of a single symbol in different contexts. In the example of (CL:LIST LIST), I said that a reader would infer that both symbols are different, whereas you are saying that we should prefix them even if they are, in fact, the same symbol. I am using the CL definition of namespace, by the way: namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.'' That means that even though packages define namespaces, not all namespaces are tied to packages. In particular, you cannot distinguish the function namespace from the value namespace with a package prefix. That's why in Lisp I can clear any confusion by writing either LIST or #'LIST, and that's why I like FUNCALL. Within standard evaluation rules (LIST X) does not use the value of a variable named LIST. In all your comments above you use words which have both verb and noun meanings, but you did not need to explain it to me. Did I seem confused? Did I say: "Hey, you wrote 'to shadow ...' but that's wrong, a 'shadow' is the thing I see on the ground when its sunny". What words look like is very distinct from their "role" in a sentence, and this is so much a natural thing to do for humans that most mainstream programming languages enable this. static void foo (int foo) { System.out.println(foo); } So, in the extreme case of: (defmethod foo ((foo foo)) (funcall foo)) ... how would you disambiguate things using package prefixes? (defmethod fun:foo ((var:foo class:foo)) (funcall var:foo)) Anybody who introduces made-up packages like this in CL to "clean-up the mess" will lose the right to commit code ;-) > Also adding I was using the term `shadowing` somewhat sloppily. Names are important enough that anytime one is being used in more than one way we should take great precaution. Yeah, right. I am talking about lisp:namespaces instead of clojure:namespaces. But I can "name things" and "have a name" without having to distinguish both usages.

junke 10y ago

I don't object using fully qualified symbols to distinguish packages for the benefits of human readers. I care about human readers as much as you, don't worry about that. I am not talking about different symbols which happen to share the same name (in different packages), but about the different meanings of a single symbol in different contexts. In the example of (CL:LIST LIST), I said that a reader would infer that both symbols are different, whereas you are saying that we should prefix them even if they are, in fact, the same symbol. I am using the CL definition of namespace, by the way: namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.'' That means that even though packages define namespaces, not all namespaces are tied to packages. In particular, you cannot distinguish the function namespace from the value namespace with a package prefix. That's why in Lisp I can clear any confusion by writing either LIST or #'LIST, and that's why I like FUNCALL. Within standard evaluation rules (LIST X) does not use the value of a variable named LIST. In all your comments above you use words which have both verb and noun meanings, but you did not need to explain it to me. Did I seem confused? Did I say: "Hey, you wrote 'to shadow ...' but that's wrong, a 'shadow' is the thing I see on the ground when its sunny". What words look like is very distinct from their "role" in a sentence, and this is so much a natural thing to do for humans that most mainstream programming languages enable this. static void foo (int foo) { System.out.println(foo); } So, in the extreme case of: (defmethod foo ((foo foo)) (funcall foo)) ... how would you disambiguate things using package prefixes? (defmethod fun:foo ((var:foo class:foo)) (funcall var:foo)) Anybody who introduces made-up packages like this in CL to "clean-up the mess" will lose the right to commit code ;-) > Also adding I was using the term `shadowing` somewhat sloppily. Names are important enough that anytime one is being used in more than one way we should take great precaution. Yeah, right. I am talking about lisp:namespaces instead of clojure:namespaces. But I can "name things" and "have a name" without having to distinguish both usages.