anchor.diff:  
   If reads were included by default, then STM would be slower (as more transactions would require serializability). However, in many cases, reads do not need to be included. Thus, users can choose to accept the performance penalty when it is necessary and get faster performance when it is not.
   
  -=== Namespaces
  +== Namespaces
   
   [[ns_as_fn]]
   **Do namespaces work like regular functions?**
  
positive.code: 
  While ns is typically placed at the top of a clj file, it is actually just a normal macro and can be invoked at the repl just the same. It could also be used more than once in a single file (although this would be surprising to most clj programmers and would likely not work as desired in AOT).
  
  === Compiler
  
  [[direct_linking_repl]]
  **How does direct linking affect the REPL experience?**
  
  Anything that has been direct linked will not see redefinitions to vars. For example, if you redefine something in clojure.core, other parts of core that use that var will not see the redefinition (however anything that you newly compile at the REPL will). In practice, this is not typically a problem.
  
  For parts of your own app, you may wish to only enable direct linking when you build and deploy for production, rather than using it when you developing at the REPL. Or you may need to mark parts of your app with ^:redef if you want to always allow redefinition or ^:dynamic for dynamic vars.
negative.code: 
  These questions and answers are adapted from mailing lists and other Clojure community forums.
  
  == Reader and Syntax
  
  [[why_keywords]]
  **What's the advantage of representing text tokens as keywords (instead of as strings)?**
  
  Keywords are cached and interned. This means that a keyword is reused (reducing memory) everywhere in your program and that checks for equality really become checks for identity (which are fast).
  
  [[reader_macros]]
  **Why does Clojure not have user-extensible reader macros?**
  
  The reader takes text (Clojure source) and returns Clojure data, which is subsequently compiled and evaluated. Reader macros tell the Clojure reader how to read something that is not a typical s-expression (examples are things like quoting `'` and anonymous functions `#()`. Clojure does not allow the user to extend this set of reader macros (as is possible in Lisp). Reader macros can be used to define entirely new syntaxes read by the reader (for example: JSON, XML, or other formats) - this is a more powerful syntactic capability than regular macros (which come into play later at compile time).
  
  Clojure intentionally limits the user's power by not making reader macros user-extensible. This avoids the possibility of creating code that another user cannot read. Clojure gives back some of the power of reader macros with tagged literals, allowing you to create generically readable _data_, that is still extensible.
  
  == Collections, Sequences, and Transducers
  
  [[seqs_vs_colls]]
  **I keep forgetting that after calling sequence functions on vectors/sets, the return value no longer is no longer has vector or set semantics.**
  
  Generally you should divide the Clojure core functions into these two categories:
  
  - Data structure functions - take a data structure and return a modified versions of that data structure (conj, disj, assoc, dissoc, etc). These functions always take the data structure _first_.
  - Sequence functions - take a "seqable" and return a seqable. [Generally we try to avoid committing to the return values actually being an instance of ISeq - this allows for performance optimizations in some cases.] Examples are map, filter, remove, etc. All of these functions take the seqable _last_.
  
  It sounds like you are using the latter but expecting the semantics of the former (which is a common issue for new Clojurists!). If you want to apply sequence functions but have more control over the output data structure, there are a number of ways to do that.
  
  