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
majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
So we all concluded that it is best to separate assigment and comparison.

I fully understand concernes about errors in code when using C syntax, thats why I concurently supported both solutions as I don't care about the syntax but the meaning. My often error in C is the one menntioned above, but in my case that is because I use large number of languages witch all have different symbol for the thing. I am not sure how non programmer would react on = and ==, but I can extrapolate from my experience with the n00bs that it will be bad. On the other hand, := is symbol that is created to underscore the difference, and was already succesifully used in Pascal witch was created as a learning language, so why reanylising psyhology of non-programmers ? Some ppl long time ago deduced that this is the best way, certanly not on coffie break, so we should stick to it. Form of this symbol is also used in mathematics, so ppl may be familiar with it from the school :D

So, Chris if you are so much concerned about n00bs, and you are, don't think any more and use Pascal method. If you want to indulge yourself for the first time and not the n00bs (and us, others C programmers) you should use C syntax. It is really simple as that.

About === we can open separate topic.
Posted Image

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
I though of this for a while before I replied. But I'm still not settled. Here are my thoughts:

1) All this started, because noobs had problems to understand the difference between := and = as the left most operator. They used
x := %y%
or
x = "y"

Because you could use ":=" and "=" for assignments.
I never had any problem with this, but it seems to be for a lot of users by the number of posts on this.

2) I prefer the idea to have different operators for different actions. Either "=" and "==" or ":=" and "=". To have a single operator doing different things regarding of context is errorprone, even if there is no ambiguity in respect to context. I do not think that it is an issue to write one character more.

3) I guess that noobs will find it easier to use ":=" only for assignments (can be translated as "defined as") and "=" only for comparison ("equal to") instead of "=" and "==". This is a clear way and easy to remember. No ambiguity. Little change to v1.

Thus, if 1) needs to be solved, I support ":=" and "=".
A "=" as the left most operator should cause an error message, since it is likely to be an error and it doesn't serve a purpose.
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.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
x = y = z  ; Syntax error! Slap wrist of lazy programmer.

x = (y == z)  ; == as a case sensitive comparison.

x := y == z  ; == as a case sensitive comparison.

func(x == 2)  ; == as a comparison.

x = (IsDone ? func() : y:=1)  ; force use of brackets - assignment.

If x = y ; comparison

If x == y ; comparison

If (x = y) ; syntax error

x = y ; assignment

x == y ; syntax error



PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
corrupt, I am really confused by your examples! Why use both := and = for assignment? Is there a difference between x = (y == z) and x := y == z? If no, why have two notations for the same thing? Why, if If x = y is legal, If (x = y) should be illegal? A comparison is an expression, and expressions can always be enclosed between parentheses (no effect here, but legal).

Chris, it looks like you have no luck with your dual-purpose proposal. IMHO, it would be falling again in the same trap we are trying to avoid in v.2.
Of course, I fully agree that in if x = 3, the = should be only a comparison. If one must want to do an assignment here, he should use a distinctive symbol. That rules out the C syntax, despite it takes the current majority in the poll... Too many C newbies felt in the trap, and even experienced programmers like me do the error from time to time (mostly when switching languages... ;-)).
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

corrupt, I am really confused by your examples!

Me too ! I didn't understand his intent at all... and can't even understand all the examples....


One symbol acting two roles is pure evil. This is programming, not chit chating... If the one doesn't want to read the manuals, and devote certain amount of time to solve its problems it is not worth it. There are many ppl on this forums that were complite n00bs in programming when started, but cuz they worked on themselves, they stand good on their feet now (I am sure you will recognise some of them). So please, Chris, stop protecting those that are lazy and impatient. Even the programmming language designed for non-programers is after all, a programming language. Some ppl are just not capable for that and there is nothing you can do.


After all, if you are afraid of increasing number of n00b questions connected to lazines, we always have BoBo to direct them what to do :D
Posted Image

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

After all, if you are afraid of increasing number of n00b questions connected to lazines, we always have BoBo to direct them what to do :D

Posted Image

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Novices vs. veterans

1) All this started, because noobs had problems to understand the difference between := and = as the left most operator.

Not just novices! Myself and many other veteran scripters constantly use = when := was intended.

So, Chris if you are so much concerned about n00bs, and you are

No, I was concerned about the 80% of AutoHotkey users who have no C-like experience.

Ambiguity of a dual-purpose equal-sign

Thus, if 1) needs to be solved, I support ":=" and "=".
A "=" as the left most operator should cause an error message, since it is likely to be an error and it doesn't serve a purpose.

"a=b ?..." where a will be assigned the value of b, which determines the branch of the if. In the ALGOL like syntax the corresponding error is "x = y", meant for assignment, which is much easier to spot (can be a syntax error).

The current plan is to treat the leftmost = in something like x=y as an assignment unconditionally. I think it would do more harm than good to make x=y a syntax error.

Explanation: When the user's intent is 99.9% clear, a modern language shouldn't quibble about purity because the user's productivity is at stake.

To have a single operator doing different things regarding of context is errorprone, even if there is no ambiguity in respect to context.

One symbol acting two roles is pure evil. This is programming, not chit chating...

It is an endless source of coding errors if an operator means different things in different contexts, so I dislike "=" for both comparison and assignment.

IMHO, [dual-purpose] would be falling again in the same trap we are trying to avoid in v.2.

I agree in principle, but please re-examine it from a practical/ergonomic standpoint: there are only a few ambiguous situations in the dual-purpose proposal, and those situations arise only rarely. So if you look at the actual, tangible benefit, it's my contention that a dual-purpose operator will save a lot of people a lot of trouble in the long run (with the possible exception of those with C-like experience; but as I explained earlier, they can use = and == in their traditional C roles in most cases).


Bottom line
Some of you see a programming language as a thing of semantic purity, with no ambiguity. But programming languages are made for people, who have ergonomic needs and to whom the principle of least surprise should be applied to improve productivity. With that in mind, I think it would reduce productivity to adopt either of the following:[*:370wubl4]Treating if x=y as an assignment instead of a comparison (i.e. C-like)
[*:370wubl4]Treating x=y as a syntax error, not an assignment (i.e. require := for assignments)

I do not think that it is an issue to write one character more.

Forcing users to write x:=y instead of x=y really adds up for people who write such statements dozens of times per day. This is especially true for people who have RSI (who are a growing percentage of the population).

Thanks.

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

Not just novices! Myself and many other veteran scripters constantly use = when := was intended.

I do too, because currently = has the sense of assignment...

When the user's intent is 99.9% clear, a modern language shouldn't quibble about purity because the user's productivity is at stake. [...] Some of you see a programming language as a thing of semantic purity, with no ambiguity.

That's not about purity, you get it wrong. That's about confusion. Current syntax has two confusing notations for assignments, and the same notation for a kind of assignment and comparison. Lot of people make errors because of this confusion. I though that with v.2 you wanted to avoid such mess.

Re-reading your proposal, I see you want to have two different assignment symbols doing the same thing, and the same symbol for two different functions, depending on context. Ugh!

really adds up for people who write such statements dozens of times per day. This is especially true for people who have RSI (who are a growing percentage of the population).

Aaah... So that's not PHP nor C that you should copy, but Perl, or even better, APL!
I find this argument rather dummy, but it seems you are set on your proposal, despite the fact that it got not vote.
New proposal: let's double all commands with a much shorter abbreviation.
WW = WinWait
WWA = WinWaitActive
MB = MsgBox
These are very commonly typed, a total loss of time and lot of pain.
(OK, there are hotstrings for that, I know...)

Well, I won't argue anymore, it seems pointless.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

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

The current plan is to treat the leftmost = in something like x=y as an assignment

It could cause confusion, too:
a=b ? f(a) : f(b)
It is unlikely that someone wants to assign the string "b ? f(a) : f(b)" to a.

Also, is "=" the leftmost operator here?
f(a=b)
It should not be, otherwise
f(a<b,a=b)
will behave differently. Then,
a=b
f(a)
is different. It is also a source of error.

I would ban using "=" for assignment, altogether.

Forcing users to write x:=y instead of x=y really adds up for people who write such statements dozens of times per day

I don't believe a few dozen extra ":" is an issue. People with RSI could define hotkeys for frequently used strings, like "" -> ":=", or repeated or long press of a key to insert such strings, etc. This was the main use of AHK in the nice old days.

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

Current syntax has two confusing notations for assignments, and the same notation for a kind of assignment and comparison. Lot of people make errors because of this confusion. I though that with v.2 you wanted to avoid such mess [of using] the same symbol for two different functions, depending on context.

It's a question of degrees: the current method is confusing because there are two different types of assignments. The new method is confusing much less often because it caters to people's existing backgrounds and habits. Even most high school math courses use = as both assignment and comparison (depending on context). If you can't see the ergonomic merit of this, I think we should agree to disagree on this point.

Re-reading your proposal, I see you want to have two different assignment symbols doing the same thing

In practice, the := operator would rarely be used. It's primary purpose is for people with C-like experience to use the result of an assignment; e.g. if not var := func()

really adds up for people who write such statements dozens of times per day. This is especially true for people who have RSI (who are a growing percentage of the population).

I find this argument rather dummy, but it seems you are set on your proposal, despite the fact that it got not vote.

That is less than 5% of the reason for my proposal. The bottom line is that I can't see myself releasing a language in which if x=y is an assignment. So what options does that leave us?

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
2 PhiLho

Well, I won't argue anymore, it seems pointless.

Perhaps, you are just not patient enough :p
Check this out.

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

2 all

But programming languages are made for people, who have ergonomic needs and to whom the principle of least surprise should be applied to improve productivity.


Forcing users to write x:=y instead of x=y really adds up for people who write such statements dozens of times per day. This is especially true for people who have RSI (who are a growing percentage of the population).


How did RSI appear here :?:

This is completely OT.

And principle of last surprise is not about that. It comes in action when you learn the language well. I know AHK very well now, and I am constantly surprised....

Deduction 1: AHK favorize dummy people and walk by "programmers" that sole intention is to solve couple of current problems and forget about it.

Deduction 2: If you want to be serious AHK programmer, devote your time to it by upgrading, anylising, and writting AHK code, espect less support and bigger confuson eatch day.

--------------------------------------------------------------------------------------------------------

Q: How many ppl voted ?
A: 18

Q: What is the score for 2nd option in the poll ?
A: 0

Q: How many ppl voted for non dual-purpose equal-sign ?
A: 100%

Q: Who is the boss here ?
A: Chris

8)
Posted Image

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

but as I explained earlier, they can use = and == in their traditional C roles in most cases

Its not about that people are eager to use == it is about that people dislike = as equality check and assignment because it will cause trouble. And the vote proves that.

Forcing users to write x:=y instead of x=y really adds up for people who write such statements dozens of times per day. This is especially true for people who have RSI (who are a growing percentage of the population).

While assuming the dualoperator is not an option the C-Syntax approach is favorable because there are much much more assignments in code then equality checks.

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

The current plan is to treat the leftmost = in something like x=y as an assignment unconditionally. I think it would do more harm than good to make x=y a syntax error.
Explanation: When the user's intent is 99.9% clear, a modern language shouldn't quibble about purity because the user's productivity is at stake.

I agree with you on the explanation. And you made AHK doing a good job in this respect today. But I want to add that a modern language should also help users to avoid 99,9% of possible errors (which are easy to fix if you know where and what to look for).

please re-examine it from a practical/ergonomic standpoint: there are only a few ambiguous situations in the dual-purpose proposal, and those situations arise only rarely.

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.
The x = y = z as assignment idea is bad, although convenient. Bad because it would introduce yet-another-exception-to-memorize and more newbies ask for help asking why it doesn't work as expected...
So in my idea, x = y = z would be the same as x = (y = z).

So if you look at the actual, tangible benefit, it's my contention that a dual-purpose operator will save a lot of people a lot of trouble in the long run.

What kind of trouble? Only to write a ":" when it is needed in the other case, right? That's the only tangible benefit I see.
But may it be that way, I see no problem then to apply PhiLhos idea to make only the first operator a dual-purpose equal-sign. In the rare case that this line "x = y = z" should all be assignments it will only need a single ":", for most of the assignments (I guess more then 90% only have a first operator) the ":" can be saved.
I guess this rule is easier to remember then checking the meaning of = by looking at the context.
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. This is similar to the optional first comma after MsgBox, Gui and other commands.

Edit:
Thus I think I will become the first voter for the second option (dual-purpose equal-sign) reducing my vote from the first option (when PhiLhos simplification is applied).
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.

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
I don't have much time, but I think something needs to be said. Oh, and for the record... if I see the word "n00bs," I stop reading and go to the next post. In fact, why are we using terms like "newbies" at all? People, what. the. HELL. This is AUTOHOTKEY. If we aren't considering these "newbies," the purpose of this project has utterly failed. This is not primarily a scripting language. This is a tool for getting stuff done. Keeping that in mind, I'm going with Chris and saying that this

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.


And about this:

Deduction 1: AHK favorize dummy people and walk by "programmers" that sole intention is to solve couple of current problems and forget about it.

Deduction 2: If you want to be serious AHK programmer, devote your time to it by upgrading, anylising, and writting AHK code, espect less support and bigger confuson eatch day.


Please. This isn't about principle of least surprise, or about what's most logical, or any kind of theoretical programming topic. It's about what's most intuitive to everyone, with as little background as possible.


I'd suggest this to everyone. If you want to prove your way is better, prove it with some actual code that works with your way, and that demonstrates clarity, ease of understanding, ease of usage, and intuition. Do not keep throwing around generic terminology or waving banners for your favorite syntax without consideration to real-life circumstances. In fact, forget the poll completely. This can't be fit into neat categories. If C syntax seems better to you, show it. If you think it would be simpler to eliminate = as assignment, show it. And don't even worry about implementation or how ambiguity is handled... that's much less pertinent, and much easier to handle. Let's worry about this decision first.

I've already spent way more time than I meant to, so I'll post my own code later today, demonstrating the dual-purpose assignment.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
I can't help but argue... ;-)

The bottom line is that I can't see myself releasing a language in which if x=y is an assignment. So what options does that leave us?

If you really cannot see yourself releasing a language in which x := y is an assignment, well, indeed, there is no choice. Otherwise, my proposal is still here.

BTW, foom is resurrecting an early proposal of mine which I don't deny, but I prefer the second one.

OK, let's take another look at the initial proposal.
x = y ; Simple assignment
If x = y ; Simple comparison
; Fine

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
One point that annoys me is that x = y = z isn't consistent. Perhaps it should be x = y := z, thus x = y := z := v, to follow the rule of := being assignment in expressions and = being comparison in expressions.
I am a bit reluctant on the use of := as leftmost symbol, but seeing that an assignment is an expression, well it is consistent...
So the previous expression can be written also as x := y := z := v for consistency (still allowing the other form, but I prefer this one).
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.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")