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

"unknown symbol" error when start of label matches start of ruledef #205

Open
PerkyElixir22 opened this issue Jun 14, 2024 · 3 comments
Open
Labels
compromise Indicates that the current behavior is an unfortunate technical compromise

Comments

@PerkyElixir22
Copy link

#subruledef Foo {
    f{i:u7}    => i`7
}

#ruledef Bar {
    [{f:Foo}]  => 0`1 @ f
    [{i:u7}]   => 1`1 @ i`7
}

foo:
bar:

    [f10]
    [bar]
    [foo]    ; unknown symbol `oo`
@hlorenzi hlorenzi added the bug label Jun 23, 2024
@hlorenzi
Copy link
Owner

This is intended behavior, since we always prioritize matches by the amount of non-parametrized tokens.

[f __ ] wins versus [ __ ] since there's an extra non-parametrized f, and then we naturally only continue the resolution process with the winning match, which is parsed as [f oo] and gets us the symbol error.

Do you have a practical use-case in mind where your behavior would be more appropriate? Otherwise, I think it'd be fine if we leave the current behavior as is.

hlorenzi added a commit that referenced this issue Jun 30, 2024
@PerkyElixir22
Copy link
Author

Sometimes when I write code I make a function or variable with a name that starts with r.
My register pattern is r{i:uZ} (I would think I'm not the only one with this pattern).
This makes it so I have to either surround the function/variable name in parenthesis any time I want to access it, or change the name, both of which are somewhat inconvenient.

This is something I would otherwise usually expect to work, so it's slightly annoying when it doesn't.

@hlorenzi
Copy link
Owner

hlorenzi commented Jul 1, 2024

Yeah, that does sound pretty useful. Perhaps I'll have to rethink this behavior, but I'm unsure of its consequences at this point. Let me investigate it further!

@hlorenzi hlorenzi added compromise Indicates that the current behavior is an unfortunate technical compromise and removed bug labels Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compromise Indicates that the current behavior is an unfortunate technical compromise
Projects
None yet
Development

No branches or pull requests

2 participants