AutoHotkey Community

hello lexikos, coult you tell me something about the topic http://www.autohotkey.com/forum/viewtop ... 886#305886 and the following entries?

Lexikos: I like the idea of changing the parsing loop to allow parsing an object.

More specifically, I would like to see the "InputVar" param be changed to a generic expression. It would not break any current implementations of Loop, Parse since expressions handle variables the same way InputVar does:But it would simultaneously add the possibility of parsing the contents of an object, plus allow things like this:

(Just an example. Yes, I know that in reality escaping literal text for use in a regex pattern is much faster with RegExReplace)
Edit: Here's an example that's more clear:

_________________
Scripts - License

While testing a recent change (the first item on my "summary"), I noticed an undocumented feature I had forgotten about: If an object is automatically created by multi-param mode (e.g. obj[x,y] := z where obj[x] didn't exist), the new object receives the base of the parent object.

This can be useful when the base object defines generic array-like behaviour, since the newly created object will automatically support all of the functions of the parent object. However, it can also be undesired, and even if it were documented would probably still be obscure. Additionally, the behaviour can be replicated by using a __Set meta-function:
It relies on the the function's minimum parameter count being enforced and the following documented behaviour: "If a meta-function does not return any value (not even a blank value), the operation continues as normal."

The current behaviour can be controlled by setting base to something other than x.base, or not setting it at all. As for the next revision, there are two options:

1. Keep the behaviour, but document it and how to disable it.
2. Remove the behaviour, but document how to replicate it.

I'm leaning toward the second option, which is probably safer. Any thoughts?
Thanks for the suggestion, I'll consider implementing it.
I'll consider ways to support expressions generically in InputVar parameters. It might also tie in with another change I had hoped to make: allowing commands to use results of expressions (i.e. pure integer/float results for numeric params and possibly objects/arrays for some commands). However, I think that it might require significant/low-level changes (or an ugly hack), so I won't be implementing it soon.

I've been working with Pseudo-Properties (which is an absolutely fantastic concept for AHK-IMO), something along the lines of:
Currently is there any way to use this concept similar to how a function can be called from an external file as long as it's in the Lib folder (and the file name is the function name)? If not, are there any plans to create functionality for something like a Default Base Standard Library file?

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

I would like to have the second option

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

jethrow, I would use something like this:
i.e. Call a library function to include the appropriate file and initialize the pseudo-properties. Also note: is, in and contains aren't supported in expressions, and by definition, the ternary operator (a?b:c) requires three operands. If you omit the third operand (a?b:), it becomes "the binary operator". (It may cause the overall expression to fail if the winning branch was omitted or it isn't the last operation in the expression.) Incidentally, I have a tentative plan to improve syntax validation to prevent these sorts of errors.
I suppose you mean a file that would be loaded automatically into every script; I have no plan to implement that.

I've thought about implementing an "/i file" or "/include file" switch, which could serve the same purpose (i.e. after editing the .ahk association in the registry) but also has other uses.

Actually, I didn't think that syntax should work - but since it did, I didn't worry about it . Thank you for clarifying.

Sounds like a great idea to me.

Thanks for the information. I don't know much about editing the registry, but I'm sure I'll learn if you implement this feature

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

Although I don't have a rationale against the check, I'm afraid that it'll break numerous scripts of mine, definitely almost all of my custom libraries, which is currently 37, let alone plain scripts. I used x?:z a lot more than x?y: whose behavior is rather restrictive against current syntactic error check of AHK. Personally I took it as a handy syntactic sugar, looking far more elegant than If ... Then .... And I suppose some other languages/compilers also support this as I think I saw a few times codes written like that, IIRC.

Omitting the winning branch of the ternary op causes a sort of "stack underflow"; i.e. because the winning branch contains no operands, no value is pushed onto the stack. If there are too few tokens on the stack when an operator is being evaluated, evaluation of the overall expression is aborted. I suppose the only way around it (to make it "legal") would be to treat the omitted branch as if an empty string was specified. The purist in me thought this a bad idea, instead preferring that a future version specifically point out the syntax error and require that the user correct it. On the other hand, it could be exclusively allowed where the result of the ternary op will be discarded; e.g. x ? y(), z ? x:=z.
That reminds me, I had considered letting x?:z be equivalent to x?x:z as an alternative to simply copying C#'s ?? operator or changing the existing behaviour to match Lua's or operator.

I was aware of that, however, that does not always hold true.

Maybe you misunderstood me. I didn't suggest to make it legal. I'm well aware of that it'll produce a runtime error when it succeeds, but, I don't care about the error when I use x?:z. So my request was that don't pop-up an error message at compile time as is currently, just leave it to the user, or at least give some option to turn it off.

I was very careful to word it accurately; I did not say it will happen every time you omit part of a ternary op, I said it happens "If there are too few tokens on the stack when an operator is being evaluated". Since the result of the first comma-delimited statement becomes the result of the overall expression, it must remain on the stack while the other statements are evaluated. Stack underflow does not occur because the second assignment has two operands: 'x' (the result of x:=1) and 'y'. Because 'x' is below 'y' on the stack, the actual assignment that occurs is x:=y.

This sort of "hidden consequence" is why I want to either make it legal or prevent it entirely.
No. I suggested an alternative.
Obviously it won't produce an error message if it's "legal".

Some bugs with this test code:



On V35


On V33:

I knew it still had a bad consequence (noted for later argument).
That'll be perfectly fine with me as I'm only concerned about the error message pop-up. IMO, this is a hard-to-make unintentionally kind of error, otherwise, there would have been already a post in the Bug section as the consequence would appear a mysterious bug. Or the user was aware of that it's not legitimate but it's looking too awesome/concise to abandon. So, my point was: why putting an effort into what nobody was dissatisfied with.

The same "bug" occurs with:

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

fragman & jethrow: thanks, I'd forgotten about those two.
I think the issue is more that it is hard to debug when it does happen.
Nobody, eh? That's me.