-
Notifications
You must be signed in to change notification settings - Fork 12
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
[RFC]PPL Extension Mechanism #27
Comments
Extending ANTLR grammerTo dynamically extend a language defined using ANTLR without introducing new code, we can consider a modular grammar design. ANTLR allows to create a grammar in parts and merge these parts dynamically by including external grammar files at runtime.
Workflow for Extension ImplementorsDefine Grammar Rules: Validate Grammar: Grammar correctness.
Main ANTLR Grammar (Root Folder)The main grammar should include: grammar MainGrammar;
query: command+; // Queries are composed of commands.
command
: standard_command
| extensible_command
;
standard_command
: ...
| ...
;
extensible_command
: EXTENSIBLE_COMMAND // Placeholder for extension commands.
;
EXTENSIBLE_COMMAND
: .+? // Match unknown commands dynamically (overridden by extensions).
;
Hook for Future Rules: Extension Grammar Compatibility: The Example Extension Grammar (/extensions/grammar/extensionParser1.g4) grammar ProjectView;
extensible_command
: PROJECT_VIEW_COMMAND
;
PROJECT_VIEW_COMMAND
: 'PROJECT' 'VIEW' 'AS' 'SELECT' '*' 'FROM' IDENTIFIER
; How This Works
The base ANTLR grammar (OpenSearchPPLParser.g4) defines a flexible extensible rule (
Extensions redefine or extend the
The ANTLR runtime combines the base grammar with extension grammars at runtime.
When the |
[Catch All Triage - 1, 2, 3] |
Is your feature request related to a problem?
PPL is a language which has multiple commands, it has the ability to be used in different engines that have a large variety of use cases and functionality.
In order for PPL to utilize these capacities to their full extent , PPL has to be dynamically extended with specific commands which are either
domain
specific orexecution
specific.For example:
Such vocabulary should not become part of the standard PPL language due to its specific use case or specific domain usage that is not relevant to other use cases.
What solution would you like?
The PPL grammar is to provide extension point to enable other plugin define their command name, paramaters, output schema.
Backend plugins can also extend resulting data types and functions, making them accessible through PPL data types and functions.
Do you have any additional context?
The text was updated successfully, but these errors were encountered: