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 pull parsing API isn't as efficient as it should be #719

Open
yorickpeterse opened this issue Jun 11, 2024 · 0 comments
Open

JSON pull parsing API isn't as efficient as it should be #719

yorickpeterse opened this issue Jun 11, 2024 · 0 comments
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers std Changes related to the standard library

Comments

@yorickpeterse
Copy link
Collaborator

Commit 0e34cc3 adds support for parsing JSON documents without the need to allocate intermediate Json values. Unfortunately this API exposes a new problem: Inko's lack of uninitialized/partially initialized memory means you have to allocate some sort of dummy value, then update that in-place or overwrite it with the parsed data. In other words, you end up with something like this:

let val = Something(
  location: Location.default,
  ...
)

try parser
  .object
  .key('location', fn { Location.parse(parser).map(fn (v) { val.location = v }) })
  .require_all

Here the initial Location is redundant, given require_all requires a value to be parsed from the input stream.

Since closures capture by value (such that they can outlive their stack frames), you can't use a bunch of local variables of type Option[Whatever] either, as the assignment isn't visible outside the closure. Even if it was, you're still creating a bunch of Option values followed by a redundant "is it in fact a Some and not a None?" check after the require_all.

We'll need something better that doesn't suffer from these issues.

@yorickpeterse yorickpeterse added accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers std Changes related to the standard library labels Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers std Changes related to the standard library
Projects
None yet
Development

No branches or pull requests

1 participant