Error formatting macro: pagetree: java.lang.NullPointerException

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note especially Chas Emerick's detailed analysis of how we arrived at the current state, posted Aug 5, 2012.  Also Mark Engelberg's argumentation on Sep 4, 2012 in favor of reverting to the older pre-exception-throwing behavior, all of which should now be duplicated below.

 

...

RH Feedback Zone

Bugs

  • sorted-set duplicate handling behavior differs from hash-set
    • this is an inarguable bug
    (which throws)
  • sorted-map duplicate handling behavior differs from hash-map (which throws)

Set Problems

  • set literals throw on duplicate keys
    • Is it a user error?
      • open question
      • is there a purpose to writing #{42 42}?
        • must every reader deal with that?
      • if yes, then checking for dupes might be penalizing correct programs (perf-wise)
        • not checking means maybe creating an invalid object
      • if hash-set didn't throw you would have an alternative when unknown entries
    • arguably there should be no problem, since conflict free
    • this behavior is just an artifact of sharing implementation with map
  • hash-set throws on duplicate keys
    • same reasons

Map 'Problems'

  • map literals throw on duplicate keys
    • this is not conflict-free, as values for same key might differ
    • is it a user error?
      • Yes
        • This is an inarguably, and apparently, bad map:
          • {:a 1 :b 2 :a 3}
        • Using keys not known to be unique in a literal is bad form
          • a user reading this:
            • {a 1 b 2 c 3}
          • should expect a map with 3 entries
      • if hash-map did not throw, you would have an alternative when keys unknown
    • auto-resolving implies an order-of-consideration for map literal entries
      • and there should not be one
    • non-resolving alternatives:
      • throw
        • checking for dupes might be penalizing correct programs
      • not checking means maybe creating an invalid object
  • hash-map throws on duplicate keys
    • here there might be an implicit order due to argument order
    • could make repeated assoc promise
      • that's the behavior of sorted-map

end RH Feedback Zone

...


Current behavior of Clojure 1.4.0

...