A glitch with stand-alone Ternary operator

AutoHotkey Community
Let's help each other out

FAQ

Memberlist

Profile

A glitch with stand-alone Ternary operator

AutoHotkey Community Forum Index -> Bug Reports

View previous topic :: View next topic

Author

Message

Sean

Joined: 12 Feb 2007
Posts: 1249

Posted: Fri Aug 03, 2007 5:21 am Post subject: A glitch with stand-alone Ternary operator

I'm not sure if it's easy to fix or not.
If the fix would break something, then leaving it as now will be fine with me as there is easy work-around to it, using variable . "" instead, although I frequently forgot to do it.

Here is the summary of the tests:

Code:

test:=0
test=0 ? res:=True : res:=False
MsgBox, % res
; Output nothing! So, the whole-line as assignment.

test:=0, test=0 ? res:=True : res:=False
MsgBox, % res
; Output wrong 0! Just a consequence of = as expression-assignment in the multi-statement.

test:=0, (test=0) ? res:=True : res:=False
; test:=0, (test=0 ? res:=True : res:=False)
MsgBox, % res
; Output correct 1!
; If using the same operator = for both assignment and equal in the future, however, which one should (test=0) be?

;/* I'd like to be able to use it in these cases!
test:=0
(test=0) ? res:=True : res:=False
;(test=0 ? res:=True : res:=False)
MsgBox, % res
; Compile error: Missing ")" at the end.
;*/

BTW, a glitch with ! operator:

Code:

test:=1
!test ? res:=True : res:=False
MsgBox, % res
; Output wrong 1!

test:=1, !test ? res:=True : res:=False
MsgBox, % res
; Output correct 0!

Lexikos

Joined: 17 Oct 2006
Posts: 2472
Location: Australia, Qld

Posted: Fri Aug 03, 2007 12:29 pm Post subject:

Quote:

test=0 ? res:=True : res:=False

Those aren't expressions... = vs :=.

Sean

Joined: 12 Feb 2007
Posts: 1249

Posted: Fri Aug 03, 2007 1:48 pm Post subject:

lexikos wrote:

Quote:

test=0 ? res:=True : res:=False

Those aren't expressions... = vs :=.

I didn't say it was an expression, and yes, it was interpreted as plain assignment here. You seem to miss the point.
I just started with it to emphasize the ambiguity when using the same symbol = for both assignment and equal, even with expression-assignment which looks like to be planned for V2, as the second example shows.

Roland

Joined: 08 Jun 2006
Posts: 238

Posted: Fri Aug 03, 2007 1:51 pm Post subject:

Why not write:

Code:

test:=0
res := test=0 ? true : false
msgbox % res

?

I don't think the ternary operator was meant to be used in the way you're trying to use it. I might be missing something though.

Sean

Joined: 12 Feb 2007
Posts: 1249

Posted: Fri Aug 03, 2007 2:04 pm Post subject:

Roland wrote:

Why not write:

Code:

test:=0
res := test=0 ? true : false
msgbox % res

If that was always possible, I wouldn't even start this post.
BTW, there is a real work-around too: just use if-else instead.

Code:

test=0 ? (res:=True) . (other stuff) : (res:=False)

Quote:

I don't think the ternary operator was meant to be used in the way you're trying to use it.

On what basis do you think so?

Roland

Joined: 08 Jun 2006
Posts: 238

Posted: Fri Aug 03, 2007 2:52 pm Post subject:

Quote:

On what basis do you think so?

On the basis of the example in the documentation I guess.

Lexikos

Joined: 17 Oct 2006
Posts: 2472
Location: Australia, Qld

Posted: Fri Aug 03, 2007 3:01 pm Post subject:

Roland wrote:

I don't think the ternary operator was meant to be used in the way you're trying to use it.

I was going to say something similar, on the basis that "1 ? 0 : 1" is a valid ternary expression, yet has no effect on it's own. Other languages I've used that have ?: do not allow it to be used this way; just as they wouldn't allow "true" to be used alone (i.e. the compiler would complain that the expression has no effect.)

Now that I think of it, "a ? b=c : b=d" (where '=' is assignment) might actually be valid - I might've just assumed it wouldn't work. (I don't have any compilers on hand to try it.)

Before posting, I thought to read the docs:

Quote:

This operator is a shorthand replacement for the if-else statement.

By that description, it should be cabable of doing whatever an if-else statement can do. Smile

Chris
Site Admin

Joined: 02 Mar 2004
Posts: 10464

Posted: Mon Aug 06, 2007 3:26 pm Post subject: Re: A glitch with stand-alone Ternary operator

Sean wrote:

Code:

test:=0
test=0 ? res:=True : res:=False
MsgBox, % res
; Output nothing! So, the whole-line as assignment.

Yes, that one's normal: it's done for backward compatibility. This will probably change in v2 to be the more expected behavior.

Sean wrote:

Code:

test:=0, test=0 ? res:=True : res:=False
MsgBox, % res
; Output wrong 0! Just a consequence of = as expression-assignment in the multi-statement.

Yes, the = in test=0 is interpreted as :=, so I think the result obtained above is as documented. In v2, the behavior will probably be the same.

Sean wrote:

If using the same operator = for both assignment and equal in the future, however, which one should (test=0) be?

It would be a comparison because that's the most intuitive. You may have already seen the discussion/poll at www.autohotkey.com/forum/viewtopic.php?t=14667

Sean wrote:

Code:

;/* I'd like to be able to use it in these cases!
test:=0
(test=0) ? res:=True : res:=False
;(test=0 ? res:=True : res:=False)
MsgBox, % res

Parentheses were put into service for continuation sections before the ternary operator was designed. This made it too difficult to disambiguate cases like the above without breaking existing scripts. At the time, I put a lot of thought into it, but the current behavior was the best I could do in a reasonable amount of time.

Sean wrote:

BTW, a glitch with ! operator:

Code:

test:=1
!test ? res:=True : res:=False
MsgBox, % res
; Output wrong 1!

The loadtime line parser isn't smart enough to differentiate between a leading ! or - that's meant as a continuation character and one that isn't. Even if it were, it would still be ambiguous in some cases because the author's intent isn't known; for example, the leading minus sign on the second line below is ambiguous, so will probably remain a continuation character in both v1 and v2:

Code:

x := y
-z ? a:=1 : func()

I realize there are many inconsistencies in the v1 syntax. Most of them are caused by backward compatibility. In v2, many of them will be fixed, but others will be introduced -- namely the ambiguity between a comparison equal-sign and an assignment equal-sign. In my opinion, ambiguity is sometimes a good thing, such as when it improves intuitiveness and ease-of-use. The challenge is to find the best compromise, which the topic/poll mentioned above tries to do.

Thanks for posting about these problems; hopefully this info will be useful to others who use ternary operators on lines by themselves.

corrupt

Joined: 29 Dec 2004
Posts: 2383

Posted: Mon Aug 06, 2007 8:53 pm Post subject:

Will any of these be fixed in v1.x Chris?

Chris
Site Admin

Joined: 02 Mar 2004
Posts: 10464

Posted: Mon Aug 06, 2007 9:56 pm Post subject: Re: A glitch with stand-alone Ternary operator

All of these behaviors are by design except the following two:
1)

Sean wrote:

Code:

;/* I'd like to be able to use it in these cases!
test:=0
(test=0) ? res:=True : res:=False
;(test=0 ? res:=True : res:=False)
MsgBox, % res

Assuming its even possible to fix this without giving up continuation sections, there's no plan to fix it because the current behavior was the best I could do in a reasonable amount of time. Keep in mind that it affects only lines that consist solely of a termary expression, which are rare.

2)

Sean wrote:

BTW, a glitch with ! operator:

Code:

test:=1
!test ? res:=True : res:=False
MsgBox, % res
; Output wrong 1!

This can't be completely fixed due to backward compatibility and due to ambiguity in cases like the following, in which the leading minus sign on the second line is ambiguous:

Code:

x := y
-z ? a:=1 : func() ; Leading minus sign currently causes this line to be joined to the one above. The same is true for a leading exclamation point.

In v2, I'll take another look at supporting exclamation points as the first character in a standalone ternary line.

corrupt

Joined: 29 Dec 2004
Posts: 2383

Posted: Tue Aug 07, 2007 1:06 am Post subject:

Thanks for the response Smile

. I'm having a bit of trouble understanding how 1) gets misinterpreted as a continuation section. Could you please explain?

Quote:

Method #1: A line that starts with "and", "or", ||, &&, a comma, or a period is automatically merged with the line directly above it (in v1.0.46+, the same is true for all other expression operators except ++ and --).

I was hoping that you might consider trashing this idea in v2...

Chris
Site Admin

Joined: 02 Mar 2004
Posts: 10464

Posted: Tue Aug 07, 2007 6:10 am Post subject:

corrupt wrote:

I'm having a bit of trouble understanding how 1) gets misinterpreted as a continuation section. Could you please explain?

Lines that start with '(' look like the start of a continuation section. Though it's easy for a person to visually distinguish between the two, I couldn't find a way to code it 100% accurately without taking more time than seemed justifed. Although RegEx might be one way to attack it, I generally avoid using RegEx internally for performance reasons. To avoid this problem, I'd considered disabling standalone ternary operators; but it seemed better to have partial support than none.

corrupt wrote:

Quote:

I was hoping that you might consider trashing this idea in v2...

I and some others use it heavily because it adds readability and convenience. To remove it would require a convincing explanation of how these benefits are outweighed by the costs.

Display posts from previous:

	AutoHotkey Community Forum Index -> Bug Reports	All times are GMT
Page 1 of 1

You can post new topics in this forum
You can reply to topics in this forum