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

Make ! actually optional when reading meta commands #427

Open
wwared opened this issue Feb 18, 2025 · 0 comments
Open

Make ! actually optional when reading meta commands #427

wwared opened this issue Feb 18, 2025 · 0 comments

Comments

@wwared
Copy link
Contributor

wwared commented Feb 18, 2025

Right now, Lurk treats (.lurk.meta.def a 123) and !(.lurk.meta.def a 123) (or !(def a 123), equivalently) differently, and only the latter variant with the explicit ! is understood as a meta command.

Both cases should instead be treated the same way, working as a meta command.

This does mean that (open ...) could be technically ambiguous if both .lurk.builtin and .lurk.meta are imported. The .lurk.builtin.open symbol should shadow the .lurk.meta.open symbol, so open is read as .lurk.builtin.open, and !(open ...) should be a reader shortcut for explicitly naming (.lurk.meta.open ...). This ensures we maintain the current behavior.

Whether this is done by having .lurk-user import .lurk.meta and then .lurk.builtin and having the latter import shadow the first, or by continuing to not import .lurk.meta and requiring the ! syntax on the REPL to name the meta symbols should not matter too much right now. The former is the intended behavior however, and should be preferred unless it causes issues.

Also need to double check that this does not cause issues with any demos or existing meta commands.

@wwared wwared changed the title Make ! optional when reading meta commands Make ! actually optional when reading meta commands Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant