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

in can't be both a keyword and an identifier #728

Open
purpleidea opened this issue Jan 12, 2024 · 1 comment
Open

in can't be both a keyword and an identifier #728

purpleidea opened this issue Jan 12, 2024 · 1 comment

Comments

@purpleidea
Copy link
Owner

I seem to have forgotten to add the following txtar test:

-- main.mcl --
$s = if 42 in [13, -5, 42, 0] {	# make sure the `in` operator works
	"pass"
} else {
	"fail"
}

test $s {}
-- OUTPUT --
Vertex: test[pass]

Woops---

In commit 233625d

lang: parser: Lexer should allow in keyword as a variable name

It turns out I actually broke this. I didn't test properly, sorry!

Is it possible to have both? I don't think most languages allow this, but since we have a $ prefix, it should be easier to disambiguate things.

If so, fixup, if not, make that test failing and add the above test.

@purpleidea
Copy link
Owner Author

I've patched this in f92f34d but if there is a better solution I'd love to have it.

ffrank added a commit to ffrank/mgmt that referenced this issue Mar 12, 2024
This is inelegant, but I stronly believe that allowing dollar signs and their
variable name suffixes to both be first class citizens, is a bad idea.
The dollar sign should initiate a token that is exempt from any other
processing.

Note that it would be possible to construct a regex similar to the one for
IDENTIFIER, that only matches valid variable names. But it will be complex.
It seems more maintainable to just consume all allowed characters, and then
check validity with some simple golang in the parser actions.

Fixes purpleidea#728
ffrank added a commit to ffrank/mgmt that referenced this issue Mar 12, 2024
This is inelegant, but I stronly believe that allowing dollar signs and their
variable name suffixes to both be first class citizens, is a bad idea.
The dollar sign should initiate a token that is exempt from any other
processing.

Note that it would be possible to construct a regex similar to the one for
IDENTIFIER, that only matches valid variable names. But it will be complex.
It seems more maintainable to just consume all allowed characters, and then
check validity with some simple golang in the parser actions.

Fixes purpleidea#728
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant