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

Left-associativity hint for the exponentiation operator. #369

Closed
wants to merge 2 commits into from

Conversation

lvalkov
Copy link

@lvalkov lvalkov commented Jun 1, 2019

Lost some time debugging otherwise valid code because I assumed it was right-associative.

@HelgeffegleH
Copy link
Contributor

HelgeffegleH commented Jun 1, 2019

There is a mention in the docs,

Operators of equal precedence such as multiply (*) and divide (/) are evaluated in left-to-right order unless otherwise specified in the operator table.

src

If this operator was an exception, it would be mentioned. That being said, it is not uncommon for exponentiation in infix notation to be right-associative, as it is in superscript notation. So I think your suggestion is reasonable 👍 .

Cheers.

@lvalkov
Copy link
Author

lvalkov commented Jun 5, 2019

Indeed, there is. Still, I think an explicit reminder would constitute a worthwhile addition, despite the duplication issues that would arise.

Some observations

@Lexikos
Copy link
Collaborator

Lexikos commented Jun 28, 2019

There are unrelated changes in your pull request that you have not mentioned. This is poor form, even if the changes are trivial and acceptable.

This applies to all versions of AutoHotkey, so why is this PR targeting the v2 branch?

Would it not be better to change the behaviour in v2 and then document right-associativity? As far as I can find in the source code, backward-compatibility is the only reason left-associativity is kept. Changing this is a trivial matter of adding 1 to the SYM_POWER entry in the sPrecedence array.

@lvalkov
Copy link
Author

lvalkov commented Jul 1, 2019

I hadn't thought about switching **'s associativity, but now that you have mentioned it, I reckon bringing it more inline with its mathematical counterpart would constitute a welcome change in the long run. I find right-associativity to be the more intuitive and sensible approach, despite the lack of a clear-cut consensus on how the behavior should be handled. Though I must admit, I am biased towards this.

That said, I am also open to leaving the operator as is, so long as something is added to the operator's description to tip off users about this apparent peculiarity.

The PR is targeting the v2 branch, because that is the version I use exclusively. As far as I can tell, clicking the Pen (Edit) prompts you to merge into v2. I simply mimicked that. If there are any guidelines in place dictating how documentation contributions are to be made, point me towards them and I'll make sure to abide by them next time. It seems the unrelated changes consisted of a trailing space that my editor must have gobbled up and a hyperlink I've added. I could revert those if you want me to.

Lexikos added a commit that referenced this pull request Jun 28, 2020
Supersedes #369

Behaviour to be changed in v2.0-a113
Lexikos added a commit that referenced this pull request Jun 28, 2020
@Lexikos
Copy link
Collaborator

Lexikos commented Jun 28, 2020

Looks like Chris anticipated a change in behaviour:

// On a related note, the right-to-left tradition of something like 2**3**4 is not implemented (maybe in v2).

@Lexikos Lexikos closed this Jun 28, 2020
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

Successfully merging this pull request may close these issues.

None yet

3 participants