Skip to content

Conversation

@drkameleon
Copy link
Collaborator

@drkameleon drkameleon commented Oct 18, 2024

Description

Basically, _ cannot be an identifier/word (because it simply isn't) - if it's followed by a space or a different symbol, etc... it has to be considered a standalone symbol.

Also see: #1773 (similar-ish)

Type of change

  • Code cleanup
  • Enhancement (implementation update, or general performance enhancements)

@drkameleon drkameleon added enhancement New feature or request parser Issues related to the evaluator (src/vm/parse.nim) labels Oct 18, 2024
@Eloitor
Copy link
Contributor

Eloitor commented Oct 18, 2024

Could this be a step in the direction to get negative numbers like _1, _2 or _3?

@drkameleon
Copy link
Collaborator Author

drkameleon commented Oct 18, 2024

Could this be a step in the direction to get negative numbers like _1, _2 or _3?

The logic is a bit different... and more for reasons of consistency: simply put, _ is not a "word". Now, considering _1 as "not a word" would be tempting too, but given that these are totally valid identifiers e.g. in JSON, this would start degrading the compatibility between what Arturo supports and different (and common) data formats. In face of the long-awaited (still proof of concept) Arturo-as-Data, we definitely don't want to completely spoil it.

(And one could say why not _ - which is also a valid JS identifier? Because, I guess we'd have to set some limit - even though it might seem arbitrary - and exclude things that go against the very core logic in Arturo: if it looks like a symbol, then it's most definitely not a "word" lol)

A couple of sidenotes:

  • For negative numbers, as a literal, I'm still leaning in favor of your own unary-minus idea...
  • The reason behind this PR - apart from a general effort of cleaning up ambiguously-parsed values - is this: https://discord.com/channels/765519132186640445/829324913097048065/1277266472120619171 (it's not going to be exactly like this, but our case supporting pattern matching could be more feasible and visually-ok than it initially looked 😉 )

@github-actions github-actions bot added the vm Issues related to the Virtual Machine implementation label Oct 19, 2024
@drkameleon drkameleon moved this to In Progress in Prepare for v0.10 🎯 Feb 27, 2025
@github-actions github-actions bot added the values Issues related to the core Value type label Apr 24, 2025
@github-actions github-actions bot added the unit-test Unit tests label Sep 25, 2025
@drkameleon
Copy link
Collaborator Author

Ready to merge! 🚀

@drkameleon drkameleon merged commit b0fa2a2 into master Sep 25, 2025
13 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Prepare for v0.10 🎯 Sep 25, 2025
@drkameleon drkameleon mentioned this pull request Sep 25, 2025
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request parser Issues related to the evaluator (src/vm/parse.nim) unit-test Unit tests values Issues related to the core Value type vm Issues related to the Virtual Machine implementation

Projects

Development

Successfully merging this pull request may close these issues.

3 participants