Break, continue - allow expression mode

[joedf]

+1 dah quote

[trismarck]

Break is more like a control flow statement rather than a command. If it were one, I would expect this to work for v2, but nope, it doesn't...:

Code: Select all

for k, v in ['ABC', 'DEF', 'GHI']
	if (v == 'DEF'), break() ; Command(s) can be called using function syntax -> this throws an error

This doesn't convince me, as it appears that it is possible to have multiple control flow-like statements in one line in v2:

Code: Select all

a := 3, b := 4
for k, v in ['ABC', 'DEF', 'GHI']
	if (v == 'DEF'), if(a == 3), if(b == 4), break

If I can have multiple control flow if() statements separated by a comma, why can't I add anything after break, if it's also a control flow statement? (~I know it's the _ending_ type of the control flow statement, but just to make the point).

But at the same time I agree that _in v2_, _that_ would be confusing:

Code: Select all

a := 3, b := 4
for k, v in ['ABC', 'DEF', 'GHI']
	if (v == 'DEF'), if(a == 3), if(b == 4), break, , found := true

So the bottom line is that Coco has me convinced that in v2 the idea is kind of flawed (because of code readability, workarounds available in v2). As for v1, the change _could_ be introduced, but I guess it would be more reasonable to just learn v2 instead.
Solved, thanks.

//edit: but if the change was introduced into v1, then if v2 would want to be compatible with v1 in this context, v2 would have to introduce that change too...

[lexikos]

If, Else, Try and Finally can be followed by almost anything which can normally be used at the start of a line (because these statements are expected to be followed with an associated line or block of code). This is not true for all control flow statements. I think Coco's point was that it is a control flow statement, and therefore can't be called with function() syntax.

All commands can now be called as functions, except for control flow statements
http://ahkscript.org/v2/v2-changes.htm

[trismarck]

If, Else, Try and Finally can be followed by almost anything which can normally be used at the start of a line (because these statements are expected to be followed with an associated line or block of code). This is not true for all control flow statements. I think Coco's point was that it is a control flow statement, and therefore can't be called with function() syntax.

All commands can now be called as functions, except for control flow statements
http://ahkscript.org/v2/v2-changes.htm

Yes. Lets differentiate between two things:

• a given control flow statement can be followed by some other control flow statement
• a control flow statement can be called with a function-like syntax

What I've meant when writing the example with multiple if() statements was that, for _some_ control flow statements, it _is_ possible to have something _right to_ the control flow statement (~if() ) and for some control flow statements it is _not_ possible to have something right to the control flow statement (~break). This is why I wrote that Coco's explanation doesn't convince me (as Coco was talking about control flow statements):

Break is more like a control flow statement [...]

To continue the thought, if it is possible to have something (a command / other cf statement) to the right of the control flow statement, _why_ can't there be anything right to break (if it's a cf statement too). So now we can see that in this context, there are _two_ types of cf statements - the ones that can be followed with something and the ones that can't.

As for the ability to call the cf statement as a function, _none_ of the cf statements can be called as if they were a function, _regardless_ of the type of the cf statement in the context of what construct can follow that cf statement. As for if(), which looks like a function call, this isn't the case, as the if() statement can't be called per se (I guess).
Thanks.

//edit: so the original confusion was from the fact that:

• Coco was talking about v2 (~break is a control flow statement in v2) (and _I_'ve thought that, in v2, break has moved from being a command to being a control flow statement ~type of entity the compiler recognizes)
• I was talking about the fact that in _v1_, break _is_ a command/function (BIF_Break)

Now I see that even in v1, break _isn't_ a command/function, but rather it is an Action (ACT_). So what Coco has originally said makes even more sense now - break is a control flow statement in _both_ v1 and v2, it's just documented as a command in v1 documentation. As a side note, Loop and other control flow statements are _also_ documented as commands in AHK documentation, but really are Actions from the point of view of the compiler.

[Coco]

Because by logic, if (expression) requires a line or block of code after it. That is its purpose, which is not the same for break [LoopLabel]. It's not about restricting control flow statements on whether they should be followed by another statement or not but applying what's logical for their purpose.

[joedf]

I dont see the purpose in this other than for one-liners...
Break [, LoopLabel, Some random expression]
How I see it, if break gets to have a random expression at the end, then that would suggest that ALL commands would have a random expression, if we want it to be consistent... It just doesn't seem necessary... I don't know of any languages that have break evaluate an expression... What's so difficult in having

Code: Select all

loop
{
    K:=A_index
    Break
}

instead of

Code: Select all

loop
    Break,,K:=A_index

?? The first is clearer and less confusing.

[tank]

i think there is a clear difference in what people think is clearer. code blocks are more or less bread and butter of every language. and there are times when they are a bore. but consistency is far to important to muddy the water here. in general to many different ways of doing something just generates needles confusion for people wanting to learn. and while the argument for creative coding style is strong it really introduces another complexity of optional syntax that is sure to drive ask for help and bugs.

in defense of all new programmers everywhere i must offer a vote of NO on this idea. As always Lexikos will choose on his own what to or not to implement

[lexikos]

I don't really care whether it is "clearer" or more "readable". It simply doesn't make sense, so won't be added.

I know you can do similar things with return and multi-statement comma, but that's no argument for allowing more ways to write code that doesn't make sense.

Perhaps in a future version of the language, control flow statements will be usable to the right of a multi-statement comma (at the top level, not within an expression). With the current system, it is not feasible.

[william_ahk]

Another way I just discovered, braces are used but lines are saved, also makes semantic sense.

Code: Select all

for index, item in list {
} until item = input && found := index