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

Laziness of parser #39

Open
jgm opened this issue Oct 12, 2019 · 2 comments
Open

Laziness of parser #39

jgm opened this issue Oct 12, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@jgm
Copy link
Contributor

jgm commented Oct 12, 2019

If I do

case decode inp of
  Right (opt :: Opt : _) -> doSomethingWith opt
  Right [] -> oneKindOfError
  Left (pos, err) -> anotherKindOfError

and inp is something like

---
foo: bar
...

baz

then I get an error when it hits baz, even though it can successfully parse the one YAML document I'm asking for. Is this expected? Could the parser be made lazier, so it returns the result after having parsed the first YAML document in the stream, and doesn't worry about the rest unless I ask for it?

Alternatively, could there be an option telling it to ignore non-YAML content after the first YAML document, if you just use decode1?

@jgm
Copy link
Contributor Author

jgm commented Oct 12, 2019

Sorry, my question was ill-posed. I see why it can't be lazy if it's returning an Either value.
I guess the real question is whether another function might be made available that lazily returns a list of YAML documents (with no error return values).

@hvr
Copy link
Collaborator

hvr commented Dec 31, 2019

@jgm that's definitely possible; we could still report errors with a document granularity. i.e. something like (pseudo-code):

decodeDocsLazy :: ByteString -> YamlDocs

where

data YamlDocs = YamlDoc Doc YamlDocs 
                          | YamlError ErrInfo

@hvr hvr added the enhancement New feature or request label Dec 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants