-
Notifications
You must be signed in to change notification settings - Fork 115
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
Add std/misc/walist #744
Add std/misc/walist #744
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please separate the json stuff in different pr?
Or alternatively base this on the json-stdio branch and target that pr?
Merging this as is will create horrendous conflicts that we should avoid.
I would suggest the following hierarchy:
And then you can write a macro that implements the methods and specialize accordingly. |
src/std/misc/walist.ss
Outdated
:std/sugar) | ||
|
||
(export | ||
_walist_ _walist_? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we avoid exporting those two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or at least rename them, these are ugly names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What names would you suggest? They are what std/text/json uses to recognize it's being given a walist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
base-walist ? wrapped-alist ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets call the base walist, thats what the users will be working with.
Also, the accessor should be export renamed to walist->list i think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the base is walist, what is the pure equal one called? The same, and I override the rest? Then it's not final?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why walist->list
rather than walist->alist
?
Pure and stateful wrapped alists, carry with them the equality predicate and, for the stateful ones, correctly handle the case of empty alists.
What do you think of this refactoring? If you like it, I can squash the commits together. |
Refactor the wrapped alist type hierarchy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Feel free to squash merge.
Add a library for wrapped alists: alists in a box, such that the equality predicate is transported with the data, and, when stateful, the empty alist is properly handled.
Use walist to enable user-controled field order when printing json objects.