105 replies to this topic

[just me]

http://www.autohotke...lease/?p=572443
 

v2-thoughts
 
This started several months ago as "tentative plans" and eventually devolved to "ideas and thoughts". It isn't complete or in any way final, but contains quite a few things that people may wish to comment on. Most of the content originates from notes I've been taking over two years, but is far more thorough.

 

So post your comments right here after reading the v2-changes document also, please.

Edited by just me, 24 February 2013 - 06:42 AM.

[just me]

Variables -> Syntax
 
After reading this part repeatedly I suggest the following:

• Command syntax:
  Leave all as is, that is only %var% is allowed as  a variable reference.
   
• Expression syntax:
  Allow %var, %x.y,  and %(expression), but not %var%. %var1%var2 would be interpreted as two variable references. Multiple-level derefs could be written like %%%var.

[guest3456]

initially i thought that optionally only having a preceding % was a good idea, however, given the complications, i dont really think its worth it, especially if the only benefit is that it:
 

"seems convenient, and improves subjective readability in some cases"

that doesn't seem to be a huge benefit that justifies the ambiguities and inconsistencies presented.

given the above, i think this is the best route:

• Allow %exp%, where exp is almost any expression. For example, %var%, %x.y%, %array[i]% and %(var)% would all be valid, but %var and %(exp) would be invalid. Performing a double-deref would require parentheses; e.g. %(%var%)%.

also, i didnt see any mention of derefs within quoted strings, i'm hoping that is still on the plate

[Lexikos]

just me:

The purpose of %(expression) is to allow expressions in command syntax without changing the whole parameter to an expression. Allowing it only in expressions (for double-derefs?) would defeat the point, and wouldn't be worth implementing. Whichever way it goes, the syntax for % must be consistent across command syntax, quoted strings and (of lesser importance) double-derefs.

 

guest3456:

I'm not sure what you mean by "ambiguities and inconsistencies". If the rules are clearly defined, there is no ambiguity. The problem is that the rules might not be intuitive enough that one can understand them without reading the documentation. The fewer cases where users might expect something contrary to reality, the less potential there is for error.

[Uberi]

Allow %exp%, where exp is almost any expression. For example, %var%, %x.y%, %array[i]% and %(var)% would all be valid, but %var and %(exp) would be invalid. Performing a double-deref would require parentheses; e.g. %(%var%)%.

 

I personally see a little issue with this: a double-deref being %(%var%)% looks like single-deref "%(%", followed by non-deref'd "var", followed by single-deref "%)%". Sure, it's possible to add a special case for the parser, but it looks rather confusing.

[Lexikos]

I personally don't see how anyone could confuse it the way you say, but in any case, there would not be a special case just for %(%var%)%; it would be supported as a consequence of allowing expressions between %. If you think it's confusing, don't use it.

[Uberi]

%x%y%z% is ambiguous (can be %x%, y, %z% or x%y%z deref'd)
%x(%y%)z% is invalid (function call with following variable)
%x%(y)%z% is not ambiguous but doesn't do a double-deref
%(x%y%z)% works but looks strange, like the current Return, %var% behavior

I think it would be pretty natural to write a double-deref as %x%y%z% and forget the parentheses. But then again, I don't have any better ideas myself that use the same start and end delimiters and keep them nestable.

[guest3456]

The purpose of %(expression) is to allow expressions in command syntax without changing the whole parameter to an expression.

i thought i remembered discussion about whether or not all command parameters in v2 would be expressions by default. or maybe that was me being confused and associating that in my brain with the fact that all commands will now be able to be used as functions

The problem is that the rules might not be intuitive enough that one can understand them without reading the documentation. The fewer cases where users might expect something contrary to reality, the less potential there is for error.

yeah, this is what i was getting at.

the other alternative that i like is:

• Allow %var and %(expression), but not %var%. %var1%var2 would be interpreted as two variable references. Multiple-level derefs could be written like%%%var; however, this would probably be very rarely used.

i probably like that one too because of the lack of ambiguity as well. its consistent. only way to deref is with one preceeding %. curious why you say that %%%var would rarely be used though?
 
the other choice that i like first which is more backwards compatible, to only deref with both start and end %s, is again consistent.
 
the mix and match of allowing both one preceeding and/or both start and end seems less intuitive to me, and more confusing and prone for error. i like one or the other

[Lexikos]

Anyone not familiar with the current state of v2 should read v2-changes before discussing v2-thoughts, to avoid confusion and time wasted on redundant suggestions.

 

 

i thought i remembered discussion about whether or not all command parameters in v2 would be expressions by default.

"Command args are never expressions by default, except with control flow statements such as Return." (Under "Uncategorized" in v2-changes.)

 

curious why you say that %%%var would rarely be used though?

I thought it was obvious. How often do you need a triple/quadruple-deref?

 

 

%x%y%z% is ambiguous (can be %x%, y, %z% or x%y%z deref'd)

Currently % begins a var deref and the next % ends it.  Hypothetically, it would be the same with an expression except that any % enclosed in parentheses would be ignored (since to do otherwise would make the expression invalid). If there is ambiguity, it is only imaginary.

 

%x%(y)%z% is not ambiguous but doesn't do a double-deref

It's no more or less ambiguous than the example above. Since x%(y)%y could be a valid double-deref, it could be misinterpreted in the same way that you suggested for the example without parentheses.

 

I think it would be pretty natural to write a double-deref as %x%y%z% and forget the parentheses.

That error has already been made by at least one user, and may be made again regardless of whether a double-deref is actually possible in that context.

[just me]

just me:

The purpose of %(expression) is to allow expressions in command syntax without changing the whole parameter to an expression. Allowing it only in expressions (for double-derefs?) would defeat the point, and wouldn't be worth implementing. Whichever way it goes, the syntax for % must be consistent across command syntax, quoted strings and (of lesser importance) double-derefs.

 

IMO one "common source of confusion" is the different behaviour of %var% in command and expression syntax. This would be preserved if it was changed to %var in both cases, but could be eliminated if %var% would stay necessary for commands but become invalid in expressions and report an error. So only %(expression)% should be valid within commands.

 

However, in consequence of my present experiences with v2 I'll use the new "function syntax" instead of commands wherever possible, So only the valid syntax for expressions will be relevant for me.

 

Edit: After some more reading ...

Edited by just me, 24 February 2013 - 06:34 AM.

[Lexikos]

IMO one "common source of confusion" is the different behaviour of %var% in command and expression syntax. This would be preserved if it was changed to %var in both cases, but could be eliminated if %var% would stay necessary for commands but become invalid in expressions and report an error.

 

In other words, eliminate double-derefs or change the syntax. I'm not in favour of eliminating any useful functionality, and until I see an appealing alternative, I'm inclined to leave the syntax as is.

 

Personally, I think %var% having two meanings is intuitive:

• In a string, the contents of the variable are inserted into the string.
• In an expression, the contents of the variable are inserted into the expression (with the limitation that the contents of the variable must be a variable name).

Either way, it is as if the deref is replaced literally with the contents of the variable.

[just me]

Commands -> Commands with sub-commands

 

This part should include the Gui command. When called as function you currently have to write

Gui("GuiName:New", "Options", "Title") 
Gui("Add", "ControlType", "Options", "Value")
Gui("Show", "Options", "Title")

I think that

GuiNew("Name", "Options", "Title")
GuiAdd("ControlType", "Options", "Value")
GuiShow("Options", "Title")

would be a more common format. However, I'll stay alive if it won't be done. 

 

 

 

[just me]

@Lexikos:

 

What I mean is the constantly repeated noob mistake:

var = 1234
...
If (%var% = 1243)

[Lexikos]

How would one specify which Gui to operate on?

 

I think that the entire Gui system is outdated, and would require more time to review than I am willing to spend on it (at least for v2.0).

 

What you meant about %var% was clear, and no matter how intuitive it is to some users, there will always be others who'll get it wrong.

[just me]

Good point!

GuiAdd("GuiName", "ControlType", "Options", "Value")

where an empty string passed as GuiName refers to the current default GUI. As I said, it doesn't greatly matter now. However, changing the GUI subsystem after the release of v2 will probably break existing scripts again.