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

editor detects and breaks program when reserved words are within variables #14

Open
carloshm opened this issue Jul 27, 2021 · 1 comment
Labels
opinions needed Extra thoughts are needed from community

Comments

@carloshm
Copy link
Contributor

when part of a variable includes a reserved word it breaks:
10 cls
20 radius=10
30 print radius
run
Unexpected = at line 20
Ready

@carloshm carloshm changed the title editor detects and broke program with reserved words editor detects and breaks program with reserved words Jul 27, 2021
@carloshm carloshm changed the title editor detects and breaks program with reserved words editor detects and breaks program when reserved words are within variables Jul 27, 2021
@James-Livesey
Copy link
Member

This is an interesting behaviour of many BASICs, including BBC BASIC (which is one of the main BASICs I was considering when researching the mechanics of atto). See what happens in BBC BASIC:

BBC BASIC Keyword-Variable Conflict

The syntax highlighting of the bbcmic.ro editor demonstrates the conflict:
image

The main rationale behind this behaviour is to enable the ability to collapse spaces in code, making lines shorter (which is particularly useful for fitting code in Tweets to send to our Twitter bot).

I might consider preventing this behavour, though — I agree that it's a bit counter-intuitive in some situations! There might be a few issues with regards to backward compatibility, but to be honest, there aren't going to be many programs that will suffer from this issue.

There are cases in documentation where the reference to conflicting variable names has been avoided (eg. see pi - atto guide), so I have been aware about this problem for some time! I think that there's two things to think about before fixing this issue though — how frequent conflicting variable identifiers appear (eg. how many frequently-used variable names will start with rad or to?), and whether freedom will be lost in making projects that are designed to fit in a tight character space (eg. Twitter's 280 char limit).

Thankfully, keywords for constants don't cause conflicting variable names — not being able to start a variable name with e (Euler's number) would be frustrating to many! It could be possible to add some smart variable name vs keyword detection system, though behaviour might be hard to predict as a user.

Thanks for the issue, though. I'll have to have a think about it, and I'd love to know what others think about conflicting variables!

@James-Livesey James-Livesey added the opinions needed Extra thoughts are needed from community label Jul 27, 2021
James-Livesey added a commit that referenced this issue May 11, 2022
This is to prevent variable name collisions, and a weird bug where
`sinsinabc(x)` results in highlighting of `sin` and `sinabc`. In this
case, the fix practically enforces function name token generation if a
function name is followed by an opening bracket (or space and bracket).

This additionally means that variables which start with `max` (eg.
`maxscore`) don't collied with the `max` function name (resolution of
issue #14 for this scenario only).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
opinions needed Extra thoughts are needed from community
Projects
None yet
Development

No branches or pull requests

2 participants