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

Modularizing skript-parser #113

Open
26 tasks
Mwexim opened this issue Jun 3, 2021 · 0 comments
Open
26 tasks

Modularizing skript-parser #113

Mwexim opened this issue Jun 3, 2021 · 0 comments
Labels
future Long-term plans of requests-for-comment about future/desired features.

Comments

@Mwexim
Copy link
Owner

Mwexim commented Jun 3, 2021

Roadmap to modularize skript-parser

1. Lexical modules

  • Lexical structure manipulation
    • Allow addons to hook into this process and change it
    • Possible rework of FileElement and FileSection
    • Rework comment parsing
    • Refactor/restructure this process to be more optimized and user-friendly (StructureParser?)

2. Registration modules

  • Annotation registrations?
    • Remove/rework SkriptRegistration class completely (as it is pure convenience either way)
  • Enum registrations
  • Overriding elements easily

3. Parsing and SyntaxElement modules

  • Control flow improvements
    • Rework of Finishing, SelfRegistrable and Continuable
    • Rework of ArgumentSections and iterative sections
    • Exiting function (perhaps instead of SelfRegistrable?)
  • Native Async support
    • AsyncEffect and AsyncSection, perhaps AsyncExpression
    • Rework all async events and effects to be safe, reliable and optimizable
  • Operators
    • Defined by context and type parameters (nothing else)
    • Overriding system to override certain contexts with other type parameters
    • Somehow link ContextValue and Operator functionality (although this is probably not necessary)
  • Pre- and post-parsing triggers (although this might take it too far)
    • Make a new parsing chain with priority queue (for example, when parsing an expression, first parse as a list, then as a variable, then as registered expression, then as context value)
    • Allow addons to hook into this system
  • Rework tags
    • Rework tag registration, parsing and matching/initialization completely
    • More customizability, while adding some sort of pattern to it.
    • Make them completely independent of VariableString and require a specific call to apply them.
@Mwexim Mwexim added the future Long-term plans of requests-for-comment about future/desired features. label Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future Long-term plans of requests-for-comment about future/desired features.
Projects
None yet
Development

No branches or pull requests

1 participant