Loop, Parse, Var, CSV

[just me]

I implemented this suggestion for v2, see 1d48aa7a...

I thought that means that you want to change only v2.

I just had a deeper look at the supposed changes. I think that a new subcommand ParseCSV while keeping the CSV option in Loop, Parse as is would be the best solution for v1. Hope it will be implemented asap. v2 is too far beyond the horizon.

Thank you!

[SOTE]

Oh, feel kind of bad. Thought Helgef was referring only to v2 too. Well, glad that it all ends well.

[Helgef]

I only wanted to change v2. My implemented suggestion is for v2 only, however, it is probably trivial to backport it to v1 and if its breaking potential is considered low enough, it might be (although not by me). As I said, the best chance for v1 to get the desired features, is if there is an easy to backport change to v2. If backported to v1, Loop Parse, CSV would be deprecated, but kept.

@SOTE, don't feel bad, we're all good here .

Cheers.

[jeeswg]

If LoopXXX is to be kept in AHK v2, I had this is mind for two-way compatible code:

Code: Select all

AHK v1/v2 -> AHK v1
Loop (Arg1) -> Loop % Arg1
LoopFiles Arg1, Arg2 -> Loop Files, % Arg1, % Arg2
LoopParse Arg1, Arg2 -> Loop Parse, % Arg1, % Arg2
LoopParseCSV Arg1, Arg2 -> Loop ParseCSV, % Arg1, % Arg2
LoopRead Arg1, Arg2 -> Loop Read, % Arg1, % Arg2
LoopReg Arg1, Arg2 -> Loop Reg, % Arg1, % Arg2

If everything was to be done via iterators, I guess we'd have something like:
(I'm neutral on the function names, I'd suggest others give a full list of potential names.)

Code: Select all

for Index, Value in Range(Count)
for Index, Value in Range(Start, End, Step)
for Index, oFileInfo in FileSearch(FilePattern, Mode)
for Index, Value in StrSplit(String, Delimiters, OmitChars)
for Index, Value in StrSplitCSV(String, Delimiters, OmitChars, Qualifier)
for Index, Value in StrSplitFile(File, Delimiters, OmitChars)
for Index, oRegInfo in RegSearch(KeyName, Mode)

perhaps:
for Path, oFileInfo in FileSearch(FilePattern, Mode)
for RegKey, oRegInfo in RegSearch(KeyName, Mode)

A potential Range function:
traditional for loop: for i = a to b (step c) possibilities - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=43022&p=238737#p238737

Re. else if:
else if > elseif > elsif > elif ['else if' looks more elegant]
LoopXXX > Loop XXX [LoopXXX better for searching/sorting, no 'where does the comma go' issues, consistent with AHK v2 dropping subcommands, allows for possible function-like syntax, no odd quote-less 'subcommands']
Link:
why was LoopParse (no space) removed? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=41821

[nnnik]

Loop,XXX is to be completely removed from the language - it actually prevents valid statments from working correctly.

[jeeswg]

- @nnnik: I made no mention of 'Loop,XXX' (with a comma), could you clarify?
- What does it prevent in AHK v2? I know it prevents the OTB style in AHK v1.
Scripting Language | AutoHotkey
https://www.autohotkey.com/docs/Language.htm#loop-statement

OTB ... is not supported by the other Loop sub-commands

- Where was it suggested it might be removed? Thanks.

[nnnik]

Because Loop with multiple parameters is retained all control-flow statements are treated as if they all have parameters (which they don't)
The only other control flow statement that could be seen as having parameters of sorts besides Loop,Parse etc. is for key, value in object.
However the syntax for that is very unique and probably shouldn't follow the same error checking rules as all other control flow statements.
When LoopXXX is removed we can finally stop thinking about control flow statements and parameters, preventing advanced brain damage such as this:
https://www.autohotkey.com/boards/viewtopic.php?f=37&t=66082

[SOTE]

I'm wondering if the original point of the Loop syntax is being overlooked. Maybe the question of why the Loop syntax was chosen in the first place should be asked? The "readability"of LoopXXX syntax is very high. It's easy to immediately understand or get a clue, and then use in scripts, even for non-programmers. It's probably why it was chosen originally. It then seemed to be used to progress users into more advanced concepts and functionality. Thus the LoopXXX variations.

Dropping LoopXXX looks to be a major change in the readability of the AutoHotkey language between versions. We are talking about entirely different syntax, even if the task will be the same. If For Loop is the preference, I think some study should go into issues surrounding it, in terms of how obvious it will be to recognize what it will do and explaining it in the documentation. To include examples of usage between AHK v1 to AHK v2. Not against "For Loop mania", just wondering if there will be some unforeseen issues surrounding the change.

And I will add that the way For Loop is used in AutoHotkey, will still be different and particular to the language. So even for someone coming from a different programming language (and not a newbie or casual programmer), AutoHotkey's LoopXXX or For Loop will likely be equally strange and peculiar from what they were doing. Since the target audience, tasks being done, and emphasis on automation were likely different.

[Albireo]

I agree with @SOTE that the use of the instruction Loop must still be easy to understand, but I do not think it needs to be more complicated to use because of this.

The CSV option is quite useful if (and only if) you parse a CSV file using the English default Excel format:

• " text field delimiter.
• , field separator.

Both characters (" and ,) are hard-coded in AHK's modul script.cpp:...

What I understand is quotation marks, as text field delimiter, no problem (internationally?) - Am I wrong?
The big constraint is in the field separator "," (CSV)
Must the freedom to choose the field separator be completely free?
Is it not enough to give the opportunity to choose between a maximum of 5 or 10 different field separators?
For example .:

• CSV => , (like today - no change)
• CSV1 => ;
• CSV2 => TAB
• CSV3 => Space
• CSV4 => |

and so on...
Like this (from the AHK-manual) .:

Code: Select all

; Example #??: Parse a semicolon separated value (CSV1) file:
Loop, read, C:\Database Export.csv
{
    LineNumber := A_Index
    Loop, parse, A_LoopReadLine, CSV1
    {
        MsgBox, 4, , Field %LineNumber%-%A_Index% is:`n%A_LoopField%`n`nContinue?
        IfMsgBox, No
            return
    }
}

Would be very nice if the same CSV possibility was given eg. StrSplit
Like this .: Array := StrSplit(String, CSV1, OmitChars)(for semicolon-separated strings)

[Helgef]

Is it not enough to give the opportunity to choose between a maximum of 5 or 10 different field separators?

Your suggestion it is still potentially breaking old scripts, less useful, less readable, and would require more work on the source code and the documentation.

Cheers.

[just me]

... and would require more work on the source code and the documentation.

More work than a new loop-command? I doubt! But things like CSV1 where 1 stands for ; are unnecessary 'cryptic'.

[Albireo]

...More work than a new loop-command? I doubt! But things like CSV1 where 1 stands for ; are unnecessary 'cryptic'.

Absolutely, but my idea was that the loop-command would work with older / newer scripts as before. But if a better functionality in future AHK programs is desired, it is possible to use more than just one CSV functionality.

Is there any other programming language that handles more delimiters than ","?