-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
json->scm ordering default value to true #91
Comments
To me is seems having the default the other way around is what I would expect a library to do (or not to do). When I don't make my intention explicit, to get a sorted output, then the library will not engage in sorting it. When I want a sorted output, I can tell the library just that, making it explicit. No one would need to worry about the library by default doing something not performant, that they have to figure out and then deactivate. |
The original ordering of JSON should be respected by default and I consider this to be "correct". I tried with Ruby and Python JSON libraries and the results support this standpoint. They preserve the JSON ordering by default. It seems strange that non-ordered would be the default for data structures that are by definition ordered (namely vectors and lists). The JSON arrays are ordered by json->scm regardless of the ordering keyword value (looked at the source code, dit not validate). This leads to inconsistent behavior between vector and alist results. A performant and order-preserving implementation would have to use speculative allocations, because the JSON file is read in sequence without the knowledge of the final sizes. One option would be a pre-allocated vector, where a new vector is allocated after previous is filled. This would prevent applying reverse, but would still require data copying to the final data structure, which is returned to the user. In practice I would use the same "reverse!" based approach for both JSON arrays and JSON objects, as is used currently for JSON arrays. |
Ah, I misunderstood what you mean by ordering. I thought you mean sorting (alphanumerically). I understand your point better now. |
If the ordering keyword argument would be #t by default, the resulting scm would be "correct". Users that don't care about the ordering, would explicitly set ordering to #f for getting better performance.
This would break code for some people, but I guess not for that many.
The text was updated successfully, but these errors were encountered: