why was LoopParse (no space) removed?

Discuss the future of the AutoHotkey language
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

why was LoopParse (no space) removed?

24 Dec 2017, 11:16

Removed LoopFiles/LoopParse/LoopRead/LoopReg (now require a space).
this makes no sense to me.

1. it makes the command syntax of these inconsistent (with the first param not really being a param but an alternate command entierly). if these are now really 2-word commands, then there should still be no comma between the command and the first param, since you also removed that previously optional comma.
so with the new synxtax rules it should be Loop Parse Param1,Param2 instead of Loop Parse, Param1,Param2
really, both of these are gross, and there should be no two word commands. and more importantly..

2. now we can't call it in function form either. or can we?

User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

24 Dec 2017, 13:11

It will be replaced by enumerators.
That's cleaner.
Recommends AHK Studio
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: why was LoopParse (no space) removed?

24 Dec 2017, 19:55

I believe I marked it as "experimental" (as I've done with function-style Return, Until and Loop-count). Well, this experiment's over, and my conclusion was that neither changing the style nor adding a second optional style (effectively duplicating sub-commands with functions) was warranted.

I am not currently planning to replace Loop with enumerators for v2.0, but it does seem like a natural conclusion. That is one of the reasons I chose to keep closer to the v1 style (rather than have LoopParse() in v2.0-final and then shortly replace it with enumerators).

I would not classify control flow statements as commands, despite the current documentation structure. There are several differences. The Loop sub-command parameter was always a bit special, and unlike (nearly?) every command:
This parameter must be the word PARSE, and unlike other loop types, it must not be a variable reference that resolves to the word PARSE.
That aside, Loop, Parse, ... -> Loop Parse, ... follows the same pattern as for commands; the initial optional comma is removed. "Loop Parse" is not a command name, but a Loop statement with Parse keyword.

I'm on the fence about allowing the "second" comma to be omitted, but personally I prefer to write/read it with the comma.

As for other function-style statements, if() and while() were originally supported because other users are used to typing them that way. It seems preferable over interpreting them as function calls. Return, Until and even Loop-count are less of an issue than other Loops because it's just a difference of one space. If, While and Loop have the problem of resembling function definitions, while being something totally different. If and While at least commonly take that form in other languages.

Also, for(x in y) has never worked.
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

25 Dec 2017, 04:27

lexikos wrote:The Loop sub-command parameter was always a bit special, and unlike (nearly?) every command:
This parameter must be the word PARSE, and unlike other loop types, it must not be a variable reference that resolves to the word PARSE.
The word PARSE is defined as a parameter in v1. What is it in v2?
  • Parameter?
    This would require surrounding quotes.
  • Sub-command?
    I hope that v2 will abolish sub-commands.
  • Keyword?
    v1 docs wrote:
    • For and several types of If statement use keywords or an operator instead of commas to separate some of their parameters.
  • Operator?
    Operators have never been followed by a comma.
For me, there are only the following options:

Code: Select all

; Parameter, with comma
Loop "Parse", String, ...
; Keyword, without comma
Loop Parse String, ...
; New syntax
LoopParse String, ... ; or just Parse String, ...
I prefer the latter.

I support the "scrap commands" idea. For the same reason I'm against the "function-style" syntax for control-flow statements.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: why was LoopParse (no space) removed?

25 Dec 2017, 05:46

- @guest3456: +1

Code: Select all

;this makes the most sense to me:
LoopParse String, Delimiters, OmitChars
;and if people wanted it, I'm neutral on the matter, this:
LoopParse(String, Delimiters, OmitChars)
- Since some of the file loop and reg loop 'A_' variables are due to be changed in AHK v2, and since the 4 LoopXXX control flow statements aren't used in AHK v1 at the moment, at some point it could facilitate conversion if the 4 LoopXXX control flow statements were backported to AHK v1 (using expression-style parameters). That way people can isolate that part of the conversion to AHK v2, getting it right in AHK v1 first.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

25 Dec 2017, 05:57

I would prefer removing LoopXXXX in general.
StrSplit is better than LoopParse anyways.
And adding enumerators seems like the better practice.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: why was LoopParse (no space) removed?

25 Dec 2017, 06:18

@nnnik: I am pro-enumerators in certain respects, (although I am perfectly happy with loops as they are,) but is there a risk that the enumerators can slow things down? E.g. StrSplit requires parsing the entire string, and you might be working on a massive string, and want to break out of the loop early.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

25 Dec 2017, 08:21

That speed-loss can be repaired by changing the implementation of StrSplit
Recommends AHK Studio
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: why was LoopParse (no space) removed?

25 Dec 2017, 14:08

lexikos wrote:The Loop sub-command parameter was always a bit special, and unlike (nearly?) every command
isn't this reason enough to introduce some more consistency in the language? using the one word CamelCase version of the commands eliminates this inconsistency, removing this "special parameter unlike any other command"

lexikos wrote:I'm on the fence about allowing the "second" comma to be omitted, but personally I prefer to write/read it with the comma.
i agree with this, but then i dont understand how you don't prefer normal commands to be read without the comma


side note: i do like that new language doc help page. i think it was certainly needed

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: why was LoopParse (no space) removed?

25 Dec 2017, 16:41

nnnik wrote:That speed-loss can be repaired by changing the implementation of StrSplit
No, it cannot.
1. StrSplit effectively does the work of Loop Parse and then also creates an array and copies of each substring.
2. Enumerating over the array returned by StrSplit adds more overhead.
3. StrSplit parses the whole string, whereas the loop can be stopped early if the script does not need all of the substrings.

Even if there's a function to return an enumerator with the same characteristics as Loop Parse, it still has the overhead of allocating an enumerator and dynamic dispatch to utilize it. The enumerator is also limited to using heap memory, whereas Loop Parse can optimize by using a stack allocation when appropriate. In the common cases (for strings <= 40000 characters), there's only one allocation from the stack and none from the heap until you retrieve A_LoopField.
guest3456 wrote:isn't this reason enough to introduce some more consistency in the language?
Isn't [the presence of inconsistency] reason enough to introduce some more consistency? No, it isn't a reason at all; it is a prerequisite. If there's no inconsistency, one can't add consistency. I think what you mean to say is "Isn't the inconsistency reason enough to change Loop in this specific way?" and no, I don't feel that it is.

As an aside, the loop sub-commands are already more consistent with respect to each other.
unlike any other command
Notice I said "unlike every command", as most control flow statements are special.
i agree with this, but then i dont understand how you don't prefer normal commands to be read without the comma
I do prefer normal commands to be read without the comma, and I can't imagine why you would think otherwise, given that parameterless function calls cannot be written any other way in v2.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

25 Dec 2017, 18:12

lexikos wrote:
nnnik wrote:That speed-loss can be repaired by changing the implementation of StrSplit
No, it cannot.
1. StrSplit effectively does the work of Loop Parse and then also creates an array and copies of each substring.
2. Enumerating over the array returned by StrSplit adds more overhead.
3. StrSplit parses the whole string, whereas the loop can be stopped early if the script does not need all of the substrings.
All your reasoning is based on explaining what StrSplit currently does. If I remember correctly I mentioned changing what it does.
One solution could be returning an Object that does not actually contain anything but rather will determ the value of whatever attribute you try to access.
In a example for prime numbers:

Code: Select all

SetBatchLines, -1
for each, prime in Primes
	Tooltip % prime

class Primes {
	__New() {
		static init := new Primes()
		if init
			return init
		Primes := this
		this.1 := 2
	}
	
	__Get( primeIndex ) {
		if ( primeIndex * 0 == 0 ) {
			n := this[ this.maxIndex() ]
			Loop % primeIndex - this.Length() {
				Loop {
					n++
					fail := 0
					while ( A_Index <= this.length() && n >= ( nr := this[ A_Index ] ) ** 2 ) {
						if !mod( n, nr ) {
							fail := 1
							break
						}	
					}
					if !fail {
						this.push( n )
						break
					}
				}
			}
		}
	}
	
	_NewEnum() {
		return val := { next:this.next.bind( this ), index:0 }
	}
	
	next( enumerator, byref key, byref value := "" ) {
		enumerator.index++
		if IsByRef( value )
			value := this[ enumerator.index ]
		key := enumerator.index
		return 1
	}
}
This class does not actually generate all possible prime numbers in advance but rather calculates it when needed.
The same approach should be possible for StrSplit.
Of course there still will be overhead, however I think it is neglectable compared to the gain in consistency.
Recommends AHK Studio
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: why was LoopParse (no space) removed?

25 Dec 2017, 23:44

lexikos wrote:I believe I marked it as "experimental" (as I've done with function-style Return, Until and Loop-count). Well, this experiment's over, and my conclusion was that neither changing the style nor adding a second optional style (effectively duplicating sub-commands with functions) was warranted.
lexikos wrote: I think what you mean to say is "Isn't the inconsistency reason enough to change Loop in this specific way?" and no, I don't feel that it is.
its clear from these two quotes of yours, that you have no reasoning to justify your decision, or you wouldve given it.

quote 1, "ive concluded no change was warranted" but you give no reasoning on how you came to this conclusion.

so pretty much just a whim. fine

why dont you tell us why you even decided to "experiment" with this syntax in the first place?

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: why was LoopParse (no space) removed?

26 Dec 2017, 03:30

nnnik wrote:All your reasoning is based on explaining what StrSplit currently does.
Sure, when you conveniently ignore my second paragraph. Why are you fixated on StrSplit() anyway? You want to add complexity to it so that it can be used for "efficient" enumeration (while possibly making it less efficient in some array-access cases), but it would be more efficient and just as usable to create a separate function for enumeration. Either way it would have the issues I mentioned.
Of course there still will be overhead, however I think it is neglectable compared to the gain in consistency.
First you say that the speed-loss can be negated, now you say that the speed-loss does not matter. Hopefully that means the discussion can end.
guest3456 wrote:why dont you tell us why you even decided to "experiment" with this syntax in the first place?
Maybe because I don't like repeating myself. Why don't you show some respect?
I wrote:I added them as an obvious method of giving authors a way to use expression syntax uniformly across the entire script (avoiding commands and the % prefix), but that's been superseded. It seemed obvious because it looks like a function call. On the other hand, it looks like a function call or definition, but is neither. I decided that the original "sub-command" approach was clearer. It goes without saying that any statement beginning with "Loop " (with space) is a loop statement, whereas the same can't be said for any statement/function name beginning with "Loop" (without space).

One (perhaps contrived) drawback of the function-like syntax is that typos may go undetected:

Code: Select all

Looparse(x, y) {
    ; this doesn't raise an error.
}
Source: (5) Re: v2.0-a079-be5df98 - Loop statements - AutoHotkey Community
just me wrote:The word PARSE is defined as a parameter in v1. What is it in v2?
I didn't see this post earlier. Loop and Parse are both keywords, I suppose, in the same sense as in every other programming languages which has elements based on human language. In some sense Parse is an operator - it denotes an operation - but clearly it does not fall under the same category as and/or/not/new. Maybe it is a parameter, maybe not. There is no single way to classify it, and I do not see why it matters in the first place.
; Keyword, without comma
Loop Parse String, ...
Does it being a keyword preclude the use of a comma? Why?
Parameter?
This would require surrounding quotes.
Why? Goto and gosub do not require quotes. I see no practical value in taking "consistency" that far. (Though for goto/gosub, I opted for consistency with label definitions over consistency with functions.)
Sub-command?
I hope that v2 will abolish sub-commands.
Why, when it is just a matter of how you classify it, or whether there is a space? I converted WinGet/WinSet/etc. to individual functions to avoid adding quote marks (i.e. convenience and style) and to provide consistency between related functions (e.g. WinGetText vs WinGet other things), but that hardly applies to Loop in its current form.
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 04:24

lexikos wrote:Does it being a keyword preclude the use of a comma? Why?
just me wrote:Keyword?
v1 docs wrote:
  • For and several types of If statement use keywords or an operator instead of commas to separate some of their parameters.
I think that's the right way to handle keywords/operators which don't define built-in commands/functions/statements.
lexikos wrote:Why? Goto and gosub do not require quotes. I see no practical value in taking "consistency" that far. (Though for goto/gosub, I opted for consistency with label definitions over consistency with functions.)
Changes from v1.1 to v2.0 wrote:Legacy Syntax Removed
Removed "command syntax".
So only "expression syntax" is left, is it?
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 05:29

lexikos wrote:Why are you fixated on StrSplit() anyway? You want to add complexity to it so that it can be used for "efficient" enumeration, but it would be more efficient and just as usable to create a separate function for enumeration.
Because I want to avoid adding an unneccessary amount of functions that can be used for rare cases instead of enhancing the core functionality in a way the average user does not need to know about. It's about saving our "easy to learn" point of AutoHotkey. This point is what drives this community. Without this point inside the software this community revolves around it will loose many members. Yoiu have been gradually giving up on this point. As far as I remember you once said that the documentation should just make it easy to understand operators when you removed command syntax. But as far as I can tell AHK v2 just makes it more difficult to learn this language. And at a certain point this community might just be better off never moving to AHK v2.
lexikos wrote:First you say that the speed-loss can be negated, now you say that the speed-loss does not matter. Hopefully that means the discussion can end.
That was with regards to your second paragraph. I guess that the case of not accessing A_LoopField is a really rare occurence and should probably not matter much when designing a coding element. And I think that the overhead from creating the enumerator can be neglected compared to the gain in consistency. The speed-loss that can be negated is the one from exiting Loop,Parse early.
lexikos wrote:(while possibly making it less efficient in some array-access cases)
We could also let the first access of the StrSplit result define which type of thing it is:
firstAccess: _NewEnum -> StrSplit Enumerator ( with the solution I mentioned before )
firstAccess: anything else -> just resolve it into an array
Recommends AHK Studio
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 06:02

nnnik wrote:But as far as I can tell AHK v2 just makes it more difficult to learn this language.
This has been claimed many times without any proof. I don't agree.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 06:11

just me wrote:
nnnik wrote:But as far as I can tell AHK v2 just makes it more difficult to learn this language.
This has been claimed many times without any proof. I don't agree.
You can't prove the absence of something.
Thats why you always need to prove the presence of something.
Recommends AHK Studio
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 06:37

Or simply put my argument stands unless you can prove that AHK v2 is easy to learn.
Recommends AHK Studio
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 06:45

nnnik wrote:Thats why you always need to prove the presence of something.
I agree, and you are claiming "the presence of something":
... just makes it more difficult to learn ....
So where's the proof?
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

26 Dec 2017, 07:07

OK as a basis for this prove I will take AHK v1.
We assume that AHK v1 is easy to learn due to practical tests ( people that learned AHK v1 say that it is easy to learn ).
Most people that started with command syntax - therefore we can assume that this is the main aspect of "easy to learn".
AHKv2 lacks this aspect therefore we can assume also lacks the attribute "easy to learn".
Recommends AHK Studio

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: DaveT1 and 29 guests