Skip to content
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

Open
tisannai opened this issue Aug 18, 2024 · 3 comments
Open

json->scm ordering default value to true #91

tisannai opened this issue Aug 18, 2024 · 3 comments

Comments

@tisannai
Copy link

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.

@ZelphirKaltstahl
Copy link
Contributor

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.

@tisannai
Copy link
Author

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.

@ZelphirKaltstahl
Copy link
Contributor

Ah, I misunderstood what you mean by ordering. I thought you mean sorting (alphanumerically). I understand your point better now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants