Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

v2 Issue: Equal sign (=) used to both assign and compare


  • Please log in to reply
119 replies to this topic

Poll: How should equal-sign (=) and colon-equals (:=) work in v2? (46 member(s) have cast votes)

How should equal-sign (=) and colon-equals (:=) work in v2?

  1. Leave it like v1: Colon-equals (:=) is an assignment and equals (=) is always a comparison. (16 votes [34.04%])

    Percentage of vote: 34.04%

  2. Make equal-sign (=) dual-purpose: it assigns an expression or performs a comparison, depending on context. (3 votes [6.38%])

    Percentage of vote: 6.38%

  3. Switch to the C style of using = only for assignments (never for comparisons). Double-equals (==) would compare for equality. (26 votes [55.32%])

    Percentage of vote: 55.32%

  4. Other (2 votes [4.26%])

    Percentage of vote: 4.26%

Vote Guests cannot vote
Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005

a=b
should be an assignment, and this
If a=b
should be a comparison. I find it hard to believe this is even in contention.

Go a step further: If (a=B)... is comparison. If (a+=B) is not. How about a function call iff(a=B)? You could forbid assignment inside expression, but x++ is an assignment. It should be an exception, right? x+=1 is the same, so should it be also an exception or should it be forbidden in expressions? How about x = y = z? It means the result of y = z is assigned to x. Here y = z is inside of an expression, so it must be a comparison, but most of us would think it was an assignment. Don't you agree that the exceptions, special cases make the language complex and error prone.

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
No. Wrong. Special cases are what happen when you try to fit human logic into computer logic.

x = y = z looks like z being assigned to both x and y. Alternatively, z being assigned to y, then y being assigned to x.

And x++ was made for use inside expressions. Banning assignments in expressions? I don't even know where you got that. Intuition says that an assignment inside an expression returns whatever was assigned.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
2 johny
LOL
Posted Image

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005

2 Laszlo
Are you sure you want to continue to construct examples like that?
The n00b will not even think in that direction. EVER ! :p

I don't think it is a good idea to define the language for n00bs. If some constructs are ambiguous, sooner or later a user will be hit by them. We all were n00bs, but after a few dozen scripts, we are confronted with the subtleties of the language.

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
@Laszlo:
What do you think of this proposal?

Equal signs "=" are for comparison and ":=" are for assignments. In case the ":=" is the left most operator (outside an If statement or function parameter list) the ":" character is optional.


Ciao
toralf
 
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005

x = y = z looks like z being assigned to both x and y. Alternatively, z being assigned to y, then y being assigned to x.

You can explicitly define chains of assignments, and other special constructs, but this is not a good idea. We should have one expression parser which handles x = y = z, as anything else. It is just an expression, consisting of two operators and three operands. All you need is the precedence and the order (left-to-right or right-to-left) of executing the operators. This way you can learn the language and remember the semantics much easier, too.

And x++ was made for use inside expressions. Banning assignments in expressions? I don't even know where you got that. Intuition says that an assignment inside an expression returns whatever was assigned.

If you don't ban them, AHK will be ambiguous with the dual use of "=", as several of the above examples showed.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005

Equal signs "=" are for comparison and ":=" are for assignments. In case the ":=" is the left most operator (outside an If statement or function parameter list) the ":" character is optional.

It might work, but the missing ":" could cause confusion and buys us very little (a few keystrokes). Think about
a=b,f(a)

f(a:=b)

f(a=b)

a=b ? f(a) : f(b)


toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005

It might work, but the missing ":" could cause confusion and buys us very little (a few keystrokes).

It could bring a consense.

Think about

a=b,f(a)
f(a:=b)
f(a=b)
a=b ? f(a) : f(b)

I do, with the above rule your code will be the same as:
a:=b,f(a)
f(a:=b)
f(a=b)
a:=b ? f(a) : f(b)
And this is what Chris has in mind (AFAIU). You only write the ":" where it is needed, in this case "f(a:=b)". The rest are assignments, since a comparison without a var to store its result in doesn't make sense.
Ciao
toralf
 
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
If you want to have a ternary operator without a result var, you will have to write:
dump = a=b ? f(a) : f(b)

or

dump := a=b ? f(a) : f(b)


Ciao
toralf
 
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
but most of us would want a=b ? f(a) : f(B) different from a:=b ? f(a) : f(B). I don't like to think about if I can drop ":" or not. Especially, if I look at others' code.

And you probably have to constantly extend the list of exceptions, like with a future switch/case statement.

Also a = b = c is not the same as a = b := c. Not nice.

JSLover
  • Members
  • 920 posts
  • Last active: Nov 02 2012 09:54 PM
  • Joined: 20 Dec 2004

I mention this because I think it would be a serious mistake to release a v2 in which if x = y is an assignment.

...perhaps...but I vote for a "top 10 things to understand about AHK"...which can say really loudly & in bold...EQUALS means ASSIGN...DOUBLE EQUALS means COMPARE...with examples...or perhaps not even allow them to download without passing a survey...
[*:21t4solm]How do you expect to assign a var in AHK?
<input box>

[*:21t4solm]How do you expect to do an if that would compare a var to a string?
<input box>...or perhaps the answers would be reviewed & the docs changed to take care of more noobs misunderstandings...the language should be good...just improve the docs or debugging tools some...I think, with a quick-reference style layout it could work...noobs don't wanna read, they just wanna know how to do simple things...so have a table...

I want to...                operator needed         example
compare a string            ==                      if "string"=="string"
compare vars                ==                      if var1==var2
compare a var to a string   ==                      if var=="string"
...of course in HTML it would look better & be more verbose...like directly telling them...
to compare a string...

correct...
if "string"=="string"

incorrect...
if "string"="string"

...single = sign is incorrect for compare operation......the bad code examples should be in red...& perhaps hideable if they just want the good examples...perhaps some of the examples...like assigning in an if & using the result should be mentioned in an Advanced page...where the top says...if you don't understand why you want to assign in an if & then use the result...then this page isn't for you...perhaps have a #Level directive to disallow Noobs from using the if var=1 syntax, since it's an Advanced syntax...

#Level Noob
if var=1
	msgbox, wtf var always equals 1...? huh?
...this would immediately give an error since the script says the user is at level Noob...not having a #Level would probably default to noob...this lets noobs QUICKLY learn they are doing it wrong & once they understand that, they can upgrade their #Level...
Useful forum links: New content since: Last visitPast weekPast 2 weeks (links will show YOUR posts, not mine)

OMFG, the AutoHotkey forum is IP.board now (yuck!)...I may not be able to continue coming here (& I love AutoHotkey)...I liked phpBB, but not this...ugh...

Note...
I may not reply to any topics (specifically ones I was previously involved in), mostly cuz I can't find the ones I replied to, to continue helping, but also just cuz I can't stand the new forum...phpBB was soo perfect. This is 100% the opposite of "perfect".

I also semi-plan to start my own, phpBB-based AutoHotkey forum (or take over the old one, if he'll let me)
PM me if you're interested in a new phpBB-based forum (I need to know if anyone would use it)
How (or why) did they create the Neil Armstrong memorial site (neilarmstronginfo.com) BEFORE he died?

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
You're skipping over this problem with some weak justification. If you're relying completely on clear and concise documentation, you could use any operator you wanted to, since you can drill it in and make it familiar. Heck, why not this?

x @> y

Or this!

x([y=])

I mean, all we have to do is make a quick-reference table showing:

ASSIGN

a([b=])


COMPARE

if#(a)-eq-b#then


and we're all set, right?

My point is, it makes more sense to design syntax that you don't need to read about to understand.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

a=b ? f(a) : f(B)
It is unlikely that someone wants to assign the string "b ? f(a) : f(b)" to a.

The current plan is to treat that as an assignment of an expression. If a comparison is desired, it would be done by enclosing (a=B) in parentheses or by using == instead of =. However, I consider this to be in the "1% rare" category, so please see my points below.

Also, is "=" the leftmost operator here?

f(a=b)

No, because parentheses count as operators. In other words, only things that are obviously assignments are treated as such:
x = 1
x = y
x = fn()
x = anything including ternaries.

Go a step further: If (a=B)... is comparison. If (a+=B) is not. How about a function call iff(a=B)? You could forbid assignment inside expression, but x++ is an assignment. It should be an exception, right?

To me, there's no ambiguity at all in these examples. In fact, v2 would behave exactly the same as v1 already behaves in these cases.

x+=1 is the same, so should it be also an exception or should it be forbidden in expressions? How about x = y = z? It means the result of y = z is assigned to x. Here y = z is inside of an expression, so it must be a comparison, but most of us would think it was an assignment. Don't you agree that the exceptions, special cases make the language complex and error prone.

I think it's a question of rarity. Together with the stand-alone ternary example you mentioned, the x=y=z case is about the only weird/ambiguous situation that arises under the dual-purpose proposal. I contend that although these situations are evil and will cause harm, they represent only 1% of real-world usage. If the other 99% of equal-sign usages are intuitive and improve productivity (which I believe), the net benefit outweighs the net harm (see next section).

I agree and I must say that you convinced me. Only one thing still bugs me. These lines are confusing to me:

x = y = z
x = (y = z)
x := y = z
In all three cases the left operator is for assignment, when a dual-purpose equal-sign is set. That's easy. But the second operator does have a different meaning depending on context. I can only support this if PhiLhos statement from above gets applied:

If we want simplicity, I propose to drop the multiple assignment syntax idea. Thus, we have a very consistent behavior: only the leftmost = sign (outside function calls, of course), is an assignment. Everywhere else, it is a comparison sign.

That's a good point. However, I contend that due to the rarity of x=y=z, it almost doesn't matter what decision is made. It's more important to make the decision that maximizes overall/average productivity and minimizes bugs in scripts.

One can also think of this rule as: Equal signs "=" are for comparison and ":=" are for assignments. In case the ":=" is the left most operator (outside an If statement or function parameter list) the ":" character is optional.

That's a creative way of putting it. If this plan is adopted, maybe it should be documented something like that.

x = y [color=red]=[/color] z  ; The second [color=red]=[/color] is ambiguous. Current plan is to treat both as assignments.
; OK, or is it?

x = (y [color=red]=[/color] z)  ; Current plan is to treat the rightmost one as a comparison.
; Hum, well, why not

x [color=red]:=[/color] y [color=red]=[/color] z  ; Current plan is to treat the rightmost one as a comparison.
; I don't like it...

func(x [color=red]=[/color] 2)  ; Current plan is to treat it as a comparison.
; OK. We can add:
func(x [color=red]:=[/color] 2)  ; Current plan is to treat it as a an assignment.

x [color=red]=[/color] IsDone ? func() : y:=1  ; Current plan is to treat it as an assignment.
; Once I digested the := in expression as assignment, to be consistent with +=, why not

It's good that you restated the above. Let me restate that I had to really stretch my imagination just to come up with those ambiguities, and I consider them rare. Can anything think of any other, more common ambiguities? If not, my whole proposal is based on the fact that providing 99% intuitive/good behavior outweighs 1% harmful/ambiguous behavior. Please keep in mind that all of the proposals under consideration here have serious defects. The goal is to choose the lesser evil.

If we agree on this (x = y = z being the same as x = (y = z)), then you can have my vote.
If not, well, I am only an user...
At worse, it can be ruled as "super special syntax for chained assignments"... After all, it is mostly a specialized use.

Your point about "specialized use" is right on target. That's why I said earlier that it almost doesn't matter what decision is made for the case above because hardly anyone cares. What's most important to me is that users hardly ever have to consult the documentation because 99% of the time, the behavior is intuitive and just makes sense.

My point is, it makes more sense to design syntax that you don't need to read [the documentation] about to understand.

Yes!

foom
  • Members
  • 386 posts
  • Last active: Jul 04 2007 04:53 PM
  • Joined: 19 Apr 2006

My point is, it makes more sense to design syntax that you don't need to read [the documentation] about to understand.

Yes!

That's not even funny.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

Even most high school math courses use = as both assignment and comparison (depending on context).

Just to nitpick (it was bugging me... ;-)): my high school courses are very far away, but I don't recall having ever used an assignment in my math courses... = is always, AFAIK, a comparison symbol, meaning equality, nothing else. Assignment is a concept specific to computing. Now, perhaps you can prove me wrong.

I wonder if (a = B) = c is legal, and if yes, what it means...
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")