8000 Discussion for a possible RREL extension · Issue #361 · textX/textX · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Discussion for a possible RREL extension #361

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.

Sign up for GitHub

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

Jump to bottom
Open
goto40 opened this issue Jan 11, 2022 · 1 comment
Open

Discussion for a possible RREL extension #361

goto40 opened this issue Jan 11, 2022 · 1 comment
Labels
discussion feature

Comments

@goto40
Copy link
Member
goto40 commented Jan 11, 2022

RREL is a quite flexible way to define complex lookup rules.

I found a case, where I needed some extra Python code for a custom scope provider. --> I would like to discuss a possible extension of the RREL language (in order not to program a custom scope provider for these cases).

Use case: I want to follow the model without consuming parts of my name (like ~attribute) - but instead of following all possible paths I want to select a specific fixed name for that step (like ~attribute='myname' or 'myname'~attribute: this means
follow attribute if it is named 'myname').

A possible model could be:

        Model: types_collection*=TypesCollection ('activeTypes' '=' active_types=[TypesCollection])? usings*=Using;
        Using: 'using' name=ID "=" type=[Type|ID|
                ~active_types.types,                // "regular lookup"
                'builtin'~types_collection.types    // "default lookup" - name "builtin" hard coded in grammar
            ];
        TypesCollection: 'types' name=ID "{" types*=Type "}";
        Type: 'type' name=ID;
        Comment: /#.*?$/;

Here we fixate a default lookup path to a TypesCollection with name builtin. This could be provided by a builtin model:

        types builtin {
            type i32
            type i64
            type f32
            type f64
        }

A demo model (for a possible implementation/unittest) could be

        types MyTypes {
            type Int
            type Double
        }
        types OtherTypes {
            type Foo
            type Bar
        }
        activeTypes=MyTypes
        using myDouble = Double
        using myInt = Int    # found via "regular lookup"
        using myi32 = i32    # found via "default lookup"
        # using myFoo = Foo  # --> not found

@igordejanovic I hope the idea/use case is clear? I would be happy to discuss this. If we agree on a concrete syntax (e.g. 'name'~attribute) the implementation should be quite simple and I could provide it (+ a RREL description update).
@igordejanovic
Copy link
Member

@goto40 It is a great idea. I think the explanation is clear and the extension to the language is justified. I also like the proposed syntax.

@goto40 goto40 mentioned this issue Jan 18, 2022
Merged
7 tasks
igordejanovic pushed a commit that referenced this issue Jan 21, 2022
@goto40 @igordejanovic
Added fixed-string RREL navigation + docs/tests #361
5deb74c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discussion feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@igordejanovic @goto40
0