3 ms·

wow much high horse, so snippy, much snark Given you find the lack of "standard in-memory representation for tagged literals" [1] a problem, I'm wondering why

wow much high horse, so snippy, much snark Given you find the lack of "standard in-memory representation for tagged literals" [1] a problem, I'm wondering why you are so set on adding yet another feature with the same problem and don't understand why some might also be looking for an alternative. [1] http://dev.clojure.org/display/design/Representing+EDN http://dev.clojure.org/display/design/Representing+EDN

brandonbloom 12y ago
I didn't intend to be snippy or snarky, and I don't really think I was. I was simply pointing out the problems with this proposal, which has been proposed numerous times by numerous folks, but such proposals never addresses the tradeoffs. If you're willing to chat off-list about my communication style, I'm happy to make tone corrections in the future. As for the "Representing EDN" design doc that I wrote. You're right to note similarity between tagged literals and feature expressions, however, I don't believe that they warrant the same tradeoff. One stated design goal of EDN is for intermediate processors to be able to handle self-describing data. They can already do that by defining a default tagged reader function. All I'm proposing there is that there be a single standard "uninterpreted" type, so that multiple intermediate processors can cooperate in handling self-describing data in the absence of special purpose tagged readers. Otherwise, each reader would need to perform an eager walk of each object to replace unknown types, and, by that point, they have no way of knowing what types they need to look for to replace in general. By contrast, Clojure's reader already loses information necessary to represent Clojure source code as opposed to EDN data. The EDN data model is not rich enough on its own to represent code.
- michaniskin 12y ago
  So are there still things that "simply will not work as macros"? If so it would be interesting to see examples.
- clojurian 12y ago
  I didn't intend to be snippy or snarky ... Fair enough; some of your comments here appeared to me to be dismissive and my perception was wrong. I should also say I want Niskin and Dipert's efforts here to be taken seriously and I don't want my comment to distract, and for that I apologize to them.

brandonbloom 12y ago

I didn't intend to be snippy or snarky, and I don't really think I was. I was simply pointing out the problems with this proposal, which has been proposed numerous times by numerous folks, but such proposals never addresses the tradeoffs. If you're willing to chat off-list about my communication style, I'm happy to make tone corrections in the future. As for the "Representing EDN" design doc that I wrote. You're right to note similarity between tagged literals and feature expressions, however, I don't believe that they warrant the same tradeoff. One stated design goal of EDN is for intermediate processors to be able to handle self-describing data. They can already do that by defining a default tagged reader function. All I'm proposing there is that there be a single standard "uninterpreted" type, so that multiple intermediate processors can cooperate in handling self-describing data in the absence of special purpose tagged readers. Otherwise, each reader would need to perform an eager walk of each object to replace unknown types, and, by that point, they have no way of knowing what types they need to look for to replace in general. By contrast, Clojure's reader already loses information necessary to represent Clojure source code as opposed to EDN data. The EDN data model is not rich enough on its own to represent code.

michaniskin 12y ago
So are there still things that "simply will not work as macros"? If so it would be interesting to see examples.
clojurian 12y ago
I didn't intend to be snippy or snarky ... Fair enough; some of your comments here appeared to me to be dismissive and my perception was wrong. I should also say I want Niskin and Dipert's efforts here to be taken seriously and I don't want my comment to distract, and for that I apologize to them.