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

Tracking: Stable 1.0 #543

Open
8 of 35 tasks
zesterer opened this issue Oct 10, 2023 · 6 comments
Open
8 of 35 tasks

Tracking: Stable 1.0 #543

zesterer opened this issue Oct 10, 2023 · 6 comments
Labels
1.0 Features that should be implemented for the 1.0 release tracking

Comments

@zesterer
Copy link
Owner

zesterer commented Oct 10, 2023

A list of things that need doing before 1.0 can be released as stable. This list will grow as we become aware of more things or remember outstanding issues.

API

General

  • Consider whether ParserSealed is necessary (perhaps doc(hidden) is sufficient for semver? Should we take a 'it's your fault if you don't read the docs' perspective?)
  • The sync feature is broken. When enabled, it adds extra Send/Sync constraints to trait object parsers like recursive, thereby making it non-additive.
  • Consider IterParser API overhaul from Add a way to turn a regular Parser into an IterParser so that chumsky can be used as a stream transformer #425
  • Reconsider inclusion of the lexical crate (apparently it has soundness issues and is unmaintained?)
  • Remove SimpleSpan::new in favour of Span::new, which is more general.

Combinators

Inputs

  • Consider implementation of CopyStream (that copies the iterator instead of caching tokens, more performant for iterators with very little state, like logos iterators)
  • Consider naming of Stream: is IterInput more sensible?
  • Should Input::spanned take a 'full input' span rather than an 'end of input' span? Might be more general.

Errors

Extension API

  • Initial implementation

Documentation

  • Final pass to check correctness of documentation (some of it is from the 0.9 days)
  • Nail down consistent terminology
    • 'token' and not 'character'/'element'
    • 'input' and not 'stream'/'iterator' (except when those terms are correct)
    • 'fatal' and 'recovered' errors, not 'primary' or 'secondary'

Examples

  • Create a new example for pythonic indentation parsing with the new context-sensitive parsers

Guide

  • Finish writing guide sections
  • Final spellchecking/grammar pass
  • Rewrite tutorial, including demonstration of:
    • Lexing
    • Spans
    • Error recovery

Other work

  • Write migration guide (a good way to go about this might be porting a non-trivial parser and noting the major issues).
  • Collect up all changes into the changelog (it's going to be big!)
  • Put text and potentially other things behind a feature flag
@zesterer zesterer added 1.0 Features that should be implemented for the 1.0 release tracking labels Oct 10, 2023
@safasofuoglu
Copy link

Sad to see lexical being unsound and stale. parse_partial(&[u8]) really makes a performance difference. Can https://github.com/aldanor/fast-float-rust be considered as an alternative?

@zesterer
Copy link
Owner Author

I think the parse_partial function from fast-float would work nicely with chumsky, yes (the API is pretty much identical to the one exposed by regex-automata, which we use for the regex parser). As for integer parsing: I'm less certain, although there are less complexities around integer parsing so implementing our own fast integer parser might not be too difficult.

@sshine
Copy link
Contributor

sshine commented Feb 17, 2024

Do I understand correctly that the list of examples not yet ported to 1.0 are those in the examples/ sub-directory that do not have an [[example]] section? Update: My understanding is corrected; for example, foo is updated but does not have an [[example]] section.

@Zij-IT
Copy link
Contributor

Zij-IT commented Sep 16, 2024

Sad to see lexical being unsound and stale. parse_partial(&[u8]) really makes a performance difference. Can https://github.com/aldanor/fast-float-rust be considered as an alternative?

lexical appears to be fixed and the maintainer is back (:

@zesterer
Copy link
Owner Author

That's good to know!

@TheOnlyTails
Copy link

Dynamic linking of parsers can be checked :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.0 Features that should be implemented for the 1.0 release tracking
Projects
None yet
Development

No branches or pull requests

5 participants