why was LoopParse (no space) removed?

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

Re: why was LoopParse (no space) removed?

26 Dec 2017, 07:35

just me wrote:
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.
agree. but i dont know how that would work for all of the special Loop params.



lexikos wrote:
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?

thanks for the link, i did not remember seeing that post. you arent required to repeat yourself, but you could've linked that initially in your first reply. you can't expect everyone to have read every post in every thread

re: respect.. respect is earned and reciprocated, not automatically given. you often don't show much respect to the people who make suggestions. you've been dismissive for a while now whenever most people make a request (including towards everyone in this thread at some point or another).

that said, i dont envy your position. i can imagine its not easy being the sole maintainer of a fairly large project like this. so in that regard its my bad and i should have shown more respect, and ill also take this opportunity to thank you for your continued work. but i think youve become a bit jaded, which is understandable after working on this for years and years. you even hinted at something of that effect in your anniversary post. maybe its time for you to step away and find something you're more interested in? i certainly don't want that. i'd rather you continue in your role, because who knows what happens if you leave. perhaps HotKeyIt steps up, perhaps not. but if you ever leave that puts a huge question mark on the future of AHK. but at the same time, maybe thats best for you, personally, on your journey. i don't know. Chris faced that at some point too



nnnik wrote: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".
so are you proposing the re-addition of command syntax? and if not, then what are you proposing to make things 'easier'?

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

Re: why was LoopParse (no space) removed?

26 Dec 2017, 07:55

guest3456 wrote:so are you proposing the re-addition of command syntax? and if not, then what are you proposing to make things 'easier'?

No but I proved that AutoHotkey v2 is heading in the general direction of not being easy to learn.
Of course removing the command syntax has it's advantages. However in this case I don't think that there is a single good reason why we should keep LoopParse.
Having multiple ways to do the same thing actually makes things more confusing when learning a language.
We can use StrSplit for everything that LoopParse can and more things. It should be the standard way for splitting strings and we should establish that as good practice.
LoopParse is insignificantly faster. StrSplit is more consistent, generalized and powerful.
I suggest to remove LoopParse.
Recommends AHK Studio
guest3456
Posts: 2403
Joined: 09 Oct 2013, 10:31

Re: why was LoopParse (no space) removed?

26 Dec 2017, 08:04

nnnik wrote:
guest3456 wrote:so are you proposing the re-addition of command syntax? and if not, then what are you proposing to make things 'easier'?

No but I proved that AutoHotkey v2 is heading in the general direction of not being easy to learn.
Of course removing the command syntax has it's advantages. However in this case I don't think that there is a single good reason why we should keep LoopParse.
Having multiple ways to do the same thing actually makes things more confusing when learning a language.

v1 has 3 ways: LoopParse, and StringSplit, and StrSplit, and you claimed v1 was easier and less confusing.

nnnik wrote:We can use StrSplit for everything that LoopParse can and more things. It should be the standard way for splitting strings and we should establish that as good practice.
LoopParse is insignificantly faster. StrSplit is more consistent, generalized and powerful.
I suggest to remove LoopParse.

i disagree. splitting and parsing are two separate things

User avatar
jeeswg
Posts: 4992
Joined: 19 Dec 2016, 01:58
Location: UK

Re: why was LoopParse (no space) removed?

26 Dec 2017, 09:31

Re. Loop.
- I have found it interesting that subcommands are being removed everywhere, except for Loop. I had wanted something like 'LoopXXX' when I started using AHK v1, to avoid ambiguity (is it a count/file/reg loop).
- I view the 5 types of loop as quite different, different enough to be potentially viewed as separate control flow statements, and not 'subcommands' of Loop.
- Also, by removing the space, it's easier to jump between instances of Loop Count and ignore the next Loop File/Parse/Read/Reg, when searching text.
- When writing a beginner tutorial, I found it a bit odd trying to explain that Loop is special, that it uses subcommands but without double quotes, it reminded me of trying to explain syntax inconsistencies in AHK v1. (I think it's fine for some control flow statements/directives to use literal text, however, Loop would be using an odd mix of literal/expression parameters.)

Re. the development of AutoHotkey and delegation.
- If I was a main dev on a freeware project, I'd be wary of tying people in, and nagging them, to do more work than they had the time to do. I'd also be concerned whether their code would be good enough, and therefore whether their code would do more harm than good. Correcting code being potentially more time-consuming than writing it from scratch.
- Contrariwise, as a dev offering my services, I'd be wary of trying to be helpful, but actually being more of a nuisance. Making constant but unhelpful requests, re. 'what else I can help with'.
- If there were to be any delegation, the main devs could say: any takers for writing code X to do Y. With potentially multiple people attempting the same code. People would be just as willing to help here as they would on other AHK subforums. Sometimes I get the big green tick, sometimes I don't. And I don't mind my script not being chosen.
- We could have a C++-athon, where coders are challenged to write stand-alone console apps to achieve certain goals, code that could be used in future versions of AutoHotkey. That way people who don't even know AutoHotkey very well, could potentially be of use. The main devs could make certain stipulations that would make the code easier to incorporate into AutoHotkey.
- I'm learning C++, I've asked for a 'C++ for AutoHotkey forum' to be set up, perhaps within the Other Programming Languages forum, I have a few C++ template scripts, I'm reading the source code and old posts regarding the source code. If the main devs had any kind of 3-page summary of things to know about the AHK source code, that would be amazing to read. I am working on this myself, and/or longer versions, but other people could do a better job right now.
- One potential idea of interest. I was surprised that there isn't a development forum. Where a main dev could say: 'does anyone have any code or links related to this issue'. I.e. 'Ask For C++ Help' / 'Ask For Source Code Help'. To just in general read C++ experts discussing points about the source code.

Re. simplicity and AHK v1 and v2.
- You can only make the language so simple. Anyhow, people will still ask on the forum how to send these characters +^#?{}.
- Generally speaking, syntax-wise, AHK v2 is a subset of AHK v1, with various bits of syntax removed. Therefore it's simpler. You don't have to explain parameter nuances and things like 'force an expression' and 'can be an expression'.
- Having two ways to do the same thing isn't normally a problem. The problem is ambiguity, when you don't know which one of two ways will work.
- When working on beginner tutorials, which I will post soon, I found it much easier to write a tutorial for AHK v2 than for AHK v1.
- Also, functions are 'easier' than commands if you're familiar with sheet functions in Excel.

Re. AHK v2.
- From my perspective, development is happening quite quickly. Most of the decisions have been made, and now the future of the Menu command has been resolved. I'm interested re. any changes to control flow statements or directives, these haven't been mentioned much in 'Thoughts for v2.0'. And whether lines like if (a contains b) && (c in d) will be possible.
- Some points I might make:
- I feel that eventually, the benefits of function names such as EditXXX, LVXXX, TVXXX, LBXXX, CBXXX, applicable to internal/external controls, will become apparent, e.g. LBGetItems/CBGetItems. It's a neat solution to various problems. Also, if additional GUI functions for AHK are added/proposed, the benefits will become further apparent.
Control Functions
https://lexikos.github.io/v2/docs/commands/Control.htm
[EDIT: See more points at the very bottom of this post.]
- Window groups. It might be useful have window groups based on regular arrays. A syntax such as ahk_xtitle/ahk_xclass/ahk_xexe to exclude certain window might be useful. [EDIT: I would probably get by fine without this, but when I first started using AHK, I'd wondered about more granular control of window groups, in particular emptying them.]
- A mode that is stricter about the use of []/() in COM objects might be beneficial. [EDIT: Ignore this. I'm more interested in a script to detect such lines, and to not change the behaviour of AHK. Especially after rereading 'Thoughts for v2.0'.]

- [EDIT:] For certain ControlXXX functions, specific to certain control types, the most sensible thing to do may be to create functions with the control type in the name.
- One reason is that when I look at, for example, ControlShowDropDown/ControlGetCurrentLine/ControlGetSelected/ControlAddItem, I instantly think, which control type is that for, will it work with the control I'm working with.
- Seeing multiple functions specific to a particular type of control, identified by their prefixes, makes it easier to follow the logic of the script.
- I would say as a rule of thumb, a ControlXXX function should only be called ControlXXX if it works with six control types or more.
- People will naturally be reluctant to add more ControlXXX functions to AHK, with the 'Control' prefix, that only work for one type of control.
- There were a lot of listview/treeview functions in AHK v1, and so having LV/TV prefixes would be consistent with this.
Last edited by jeeswg on 28 Jan 2018, 13:23, edited 4 times in total.
coffee
Posts: 69
Joined: 01 Apr 2017, 07:55

Re: why was LoopParse (no space) removed?

26 Dec 2017, 13:38

Comma sucks, in rulz

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

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

Re: why was LoopParse (no space) removed?

26 Dec 2017, 15:10

guest3456 wrote:
nnnik wrote:
guest3456 wrote:so are you proposing the re-addition of command syntax? and if not, then what are you proposing to make things 'easier'?

No but I proved that AutoHotkey v2 is heading in the general direction of not being easy to learn.
Of course removing the command syntax has it's advantages. However in this case I don't think that there is a single good reason why we should keep LoopParse.
Having multiple ways to do the same thing actually makes things more confusing when learning a language.

v1 has 3 ways: LoopParse, and StringSplit, and StrSplit, and you claimed v1 was easier and less confusing.
I claimed that the command syntax was easier to learn.
I didn't claim that things were perfect or less confusing. Also you need to consider that AHKv1 grew historically and that not all StrSplit ways were available at all times.

guest3456 wrote:
nnnik wrote:We can use StrSplit for everything that LoopParse can and more things. It should be the standard way for splitting strings and we should establish that as good practice.
LoopParse is insignificantly faster. StrSplit is more consistent, generalized and powerful.
I suggest to remove LoopParse.

i disagree. splitting and parsing are two separate things
Yes they are. Loop Parse and StrSplit both split, neither parse. In the case of Loop, Parse is just a name that is easier to remember.

@jeeswg cba to correct your post
Recommends AHK Studio
User avatar
jeeswg
Posts: 4992
Joined: 19 Dec 2016, 01:58
Location: UK

Re: why was LoopParse (no space) removed?

26 Dec 2017, 16:20

- @nnnik: I wrote 4 points arguing that AHK v2 is simpler. There may also be points in favour of AHK v1 being simpler, e.g. you don't have to use double quotes for strings. It seems unlikely that you could 'correct' my post, the 4 points are valid and can't really be contradicted.
- If you want to 'win' an argument that AHK v1 is simpler then: (a) you should start a new thread, (b) you'll need a lot of arguments in favour of AHK v1 being simpler (to outweigh any arguments in favour of AHK v2), but unfortunately it is highly unlikely that you'll be able to dismantle or 'correct' any of the arguments that I made. Good luck trying.
guest3456
Posts: 2403
Joined: 09 Oct 2013, 10:31

Re: why was LoopParse (no space) removed?

26 Dec 2017, 19:54

coffee wrote:Comma sucks, in rulz

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



hadn't seen this suggested before, but i like it the best. but also with the OneWord versions instead of the two word
Last edited by guest3456 on 26 Dec 2017, 20:27, edited 1 time in total.

lexikos
Posts: 6131
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: why was LoopParse (no space) removed?

26 Dec 2017, 20:16

just me wrote:
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.
That doesn't make any sense to me. This keyword is not being used to separate parameters.
So only "expression syntax" is left, is it?
No, nor did I say it. Directives do not use expressions (except #If). Hotkey labels and hotstrings do not use expressions.

Goto and Gosub without parentheses now accept only a naked label name, much like C. Even if they accepted %variables%, it would at least be comparable to a (dynamic) function call.

nnnik wrote:We could also let the first access of the StrSplit result define which type of thing it is:
It is still less efficient. StrSplit parses the string provided by the caller directly, and appends one string to the array for each field. Your method would need to store the whole string in the object prior to first access (meaning a memory allocation and copy of a string that could be small or very large), and then also do the same work it did before, but delayed until first access.

Loop Parse already duplicates the input string at the start, but it doesn't also have to construct two objects (the StrSplit object and enumerator) and deal with the overhead of dynamic dispatch (calling _NewEnum and Next). You can cheat and use the one object for both, but that may not go well for anyone attempting to use multiple for-loops on one object. You can design for this and allow _NewEnum to return a new object on the second and subsequent calls, but that means another small increase in code size and complexity (and there's still more runtime overhead).

Maybe the performance difference is nothing for common hotkey scripts, but it may matter when parsing large volumes of text.
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.
It doesn't matter. The point was that Loop Parse makes fewer heap allocations.

nnnik wrote:Most people that started with command syntax - therefore we can assume that this is the main aspect of "easy to learn".
This is not proof, merely conjecture, and I disagree. People started with command syntax because that's what the documentation promoted, if not actually the only choice. I think coffee said it well:
coffee wrote:People keep saying that command syntax is easier for newbies, but what makes autohotkey easier to use is the fact that it doesnt require a full on development suite, it can run scripts with a double click, and it exposes a lot of automating functions and functions from the operating system into simple lines. Its the accessibility to doing things that makes it great, not its obsolete command syntax.
Source: Commands vs Functions - Page 5 - AutoHotkey Community
just me
Posts: 5460
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

27 Dec 2017, 05:47

lexikos, obviously you don't want to change it, so just leave all as it is, though it doesn't make any sense to me.
Helgef
Posts: 3163
Joined: 17 Jul 2016, 01:02
Contact:

Re: why was LoopParse (no space) removed?

27 Dec 2017, 14:39

I will add to the monologues; I couldn't care less if it is loop parse or loopParse. However, I vastly prefer that the loop performs well, rather than it being consistent with I don't know what.

Cheers.
just me
Posts: 5460
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

27 Dec 2017, 16:28

LoopParse might perform (some fractions of) a nanosecond better. It's not a question of performance, it's just a question of syntax design.

Cheers.
User avatar
nnnik
Posts: 3230
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

28 Dec 2017, 07:05

Well all things considered I still don't understand why you want to keep LoopParse.
Could you explain why and which other reasons you have beside a minor speed gain?
Recommends AHK Studio
just me
Posts: 5460
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

28 Dec 2017, 10:48

Hi nnnik,

I wrote:It's not a question of performance, it's just a question of syntax design.
Did you read the whole thread?
User avatar
nnnik
Posts: 3230
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: why was LoopParse (no space) removed?

28 Dec 2017, 11:06

just me wrote:Hi nnnik,

I wrote:It's not a question of performance, it's just a question of syntax design.
Did you read the whole thread?
Yes I have read it over again and I have not found the post that clearly points out the syntax design advantage of having both LoopParse and For each, substr in StrSplit over just having StrSplit. If you did find some could you show me?
I'd be fine with Lexikos saying "I want to stick with the procedural paradigma for AHK v2 for many situations, since AHKs objects aren't really optimized and I don't plan on doing that in the foreseeable future" - I just want some reason.
Recommends AHK Studio
guest3456
Posts: 2403
Joined: 09 Oct 2013, 10:31

Re: why was LoopParse (no space) removed?

28 Dec 2017, 15:09

nnnik wrote:If you did find some could you show me?
... I just want some reason.


some reasonings were already given here:
https://autohotkey.com/boards/viewtopic ... 18#p190618

just me
Posts: 5460
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

28 Dec 2017, 17:40

Hi nnnik,

I'm talking about Loop Parse vs. LoopParse. IMO, it's a relict of an AHK 1.0 concept pretending that there is only one Loop statement performing all the different tasks depending on different parameters. Interestingly, this "one and only Loop statement performing different tasks" has been documented in different sections of the help file related to the special task as long as I remember. This is one of the reasons why I think that the 'one and only' concept has always been wrong.

In AHK v1 the 'special task' is determined by the first parameter. IMO, AHK v2 should replace this poor concept and introduce different statements for different tasks. That's why I suppose e.g. LoopParse Param1, ... instead of Loop Parse, Param1, .... That's my conception of a clear and 'easy to learn' syntax.
User avatar
jeeswg
Posts: 4992
Joined: 19 Dec 2016, 01:58
Location: UK

Re: why was LoopParse (no space) removed?

30 Dec 2017, 09:32

With a 'OneWord' option/default there would be a simple to describe situation: 7 loop-related one-word control flow statements, with parameter syntax rules similar to functions.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

just me
Posts: 5460
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: why was LoopParse (no space) removed?

30 Dec 2017, 09:50

And the solution is another "which can be omitted" option. :(

@jeeswg:
The second part of your list should be

Code: [Select all] [Download] GeSHi © Codebox Plus

For
Loop [[Count]|[Files|Parse|Read|Reg][,]]
While
There are only three control-flow statements for loops with this syntax.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 5 guests