Break, continue - allow expression mode
Re: Break, continue - allow expression mode
+1 dah quote
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Break, continue - allow expression mode
This doesn't convince me, as it appears that it is possible to have multiple control flow-like statements in one line in v2:Coco wrote: 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
Code: Select all
a := 3, b := 4
for k, v in ['ABC', 'DEF', 'GHI']
if (v == 'DEF'), if(a == 3), if(b == 4), break
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
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...
Re: Break, continue - allow expression mode
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
Re: Break, continue - allow expression mode
Yes. Lets differentiate between two things:Lexikos wrote: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
- 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
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.Coco wrote:Break is more like a control flow statement [...]
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)
Last edited by trismarck on 03 Jul 2014, 05:10, edited 4 times in total.
Re: Break, continue - allow expression mode
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.
Re: Break, continue - allow expression mode
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 instead of
?? The first is clearer and less confusing.
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
}
Code: Select all
loop
Break,,K:=A_index
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Break, continue - allow expression mode
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
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
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
Re: Break, continue - allow expression mode
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.
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.
-
- Posts: 504
- Joined: 03 Dec 2018, 20:02
Re: Break, continue - allow expression mode
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
Who is online
Users browsing this forum: No registered users and 7 guests