On Tue, Feb 2, 2016 at 3:45 PM, Herwig Hochleitner <[email protected]>
wrote:
>
> basically attributes, and child elements
>
In general yes, but there are endless specific ways to do this. Do you
represent a kv-pair as a single element? Do you have <key> and <value> as
elements? Or do you use the name of the key as the name of the element? And
then multiply that times the opportunities to use attributes rather than
elements. I've seen all these variations and more.
but this is also the case in clojure:
>
> {:key "value" ...} vs [:key "value" ...] vs [[:key "value"] ...]
>
In EDN (and JSON) there is a *specific* literal that represents a Map, with
*defined interfaces and runtime semantics* corresponding to the notion of a
Map. That there are additional ways to encode the information contents of a
Map (but losing its runtime semantics) is obviously true and irrelevant.
Of course, its also a disaster from an efficiency point of view, since
>> there is basically only 1 datastructure.
>>
>
> That's the same as saying: "Dynamic typing is an efficiency disaster,
> because everything derives from the root class". True in a lot of cases,
> but mostly irrelevant + mitigable by PICs and other
> sufficiently-smart-compiler things.
>
Huh? Is there an optimizing XML reader that automagically detects all the
possible variation of a Map encoding and generates an optimized backing
datastructure?
Well, show me an evaluator that directly operates on ascii-serialized EDN
> (or even binary-serialized fressian) and I'll agree on this.
>
I'm talking about the programmatic API.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
