conversion logic, v1 = -> v1 := -> v2, two-way compatibility

Discuss the future of the AutoHotkey language
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

conversion logic, v1 = -> v1 := -> v2, two-way compatibility

19 Jan 2017, 00:44

Since being prompted by guest3456,
I'm working on an AHK v1 command style to expression style converter,
as a preamble to an AHK v1 to AHK v2 converter.
It would convert 'var = value' to 'var := "value"' and certain commands to expressions,
and optionally '%var%' to '% var' in commands parameters.
I think this will ultimately help and encourage people to make the transition to AHK v2,
in tandem with the AHK strings/commands/functions/v1/v2 tutorials I'm working on.

My main concern is identifying continuation sections and multiline expressions,
prior to dealing with stand-alone lines only.
(Is their anything else that can be 'multiline' in code?)
I checked the code for the 'v1 -> v2 Script Converter',
but it's just an incredibly obscure RegEx line, if anybody wouldn't
mind outlining some of the logic for this procedure.

Stand-alone lines are either: commands, two commands in one line,
expressions, multiple expressions in one line, subroutine/hotkey/hotstring labels,
auto-replace hotstrings, hotkey/action one-liners (name for this?), directives,
function definitions, or lone curly brackets. Am I missing something?

I've done a lot conversions of this sort in the past,
I think the idea of multiple stages, and doing it in a practical way, are key,
and my general approach would be:
- Identify continuation sections and multiline expressions,
tag those lines with EOL comments and ignore them till later or for manual editing.
- Each remaining line must be a stand-alone line.
- Then one at a time, apply a conversion 'filter', and check the changes manually, e.g. with WinMerge,
then apply the next filter etc.
- When you parse each line remove and restore L/T whitespace and EOL comments.
- First filter: deal with 'var = value' lines, where 'value' is alpha. (An 'easy win',
this conversion stage should be uncontroversial yet there may be a lot of these lines.)
- Do the same again but 'value' can be alpha or one additional character
that is not % or a digit.
- Do the same again adding further allowable characters that are not % or a digit.
- Then it's time to work with the more fiddly conversions, % and digits, including
instances where decisions must be made.
- Then a similar procedure for command parameters, start off
with the most rarely used command first. And also 'if' lines.

Note: lines changed by conversion can have EOL tags added to indicate this,
also, lines confirmed as not needing conversion can also have EOL tags added.

Is there some major issue that I'm forgetting here?

Btw any AHK v1/v2 before/after code lines/full scripts, would be
very useful for establishing that the conversion procedures are working correctly.

My key intention would be that any existing script
could be made 'two-way compatible',
functional in AHK v1 and AHK v2,
no matter how ugly it or some of its functions would have to be.
I would be most interested in any new changes in AHK v2,
that would make this difficult/impossible.

Thanks for reading.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

19 Jan 2017, 11:36

I absolutely stand 100% behind what I stated above.

My approach is practical and straightforward, adaptable
to unrelated conversion projects.
My scripts are readable they are not a black box.
Instead of trying to be too clever and do all the conversions in one go and leaving a mess
like in some converters, it separates the easy and difficult conversions.
It is the perfect approach for a 'work in progress' converter,
that may never be perfected, with granular control over which filters to apply.

Continuation sections and multiline expressions,
are what matters, they are the stumbling block.
I have workarounds, but a simple effective
solution would be desirable.

If a filter only changes a few lines, you can automatically apply more filters
until a specified number of changes is reported back to the user.

I will proudly state the *GOAL* of TWO-WAY COMPATIBILITY,
where AHK v1 scripts are altered until they are AHK v2 compatible.
When I say 'any new changes in AHK v2, that would make this difficult/impossible',
I mean *very very* difficult, and if two-way compatibility in some code areas
is impossible, so be it.

I make simple readable code in a short amount of time, that works,
nothing to be ashamed of.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

19 Jan 2017, 16:20

extract/identify/label continuation sections:

This works correctly on my 78621-line script, however, I do not use continuation sections as parameters, and I have an incomplete system to check for false positives, but that does currently handle my few false positives.

I advocate flexible easy to edit scripts for script conversion. And since it is difficult to code for every conceivable scenario of text in a script, it is better for scripts to resolve what they can, and state which lines they have ignored. Or to clearly mark some lines as *definitely* resolved if they are simple enough, in early filters, and other lines as *probably* resolved in later filters.

I don't use multiline comments, so now I will try for confirmation checks, to check that lines are stand-alone, and perhaps manually label (EOL comment) any multiline expressions, which I hardly ever use, then I can work on the batch conversion of individual lines, and continue my work on correction filters. To the doubters: pretty good for day 2.

- Look ma no RegEx! -

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

guest3456
Posts: 2354
Joined: 09 Oct 2013, 10:31

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

19 Jan 2017, 20:00

mr readable code doesn't even use indentation

you couldn't make this stuff up

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

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

19 Jan 2017, 20:27

I used the AutoHotkey style guide for indentation, which is where?
Btw some of us only really know coding through AutoHotkey so ...

I don't like when people indent too much, I don't find it helps,
although I did use some indentation.
Nobody does vVariables and oObjects like me hardly either,
but I find those variable names really useful for searching and debugging.
Auto-replace hotstrings (thanks AHK) save the shift+pressing.
Apart from that I try to keep most things pretty standard.
Helgef
Posts: 3094
Joined: 17 Jul 2016, 01:02
Contact:

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 04:14

As far as I know, there isn't really an official style guide for ahk. While indentation is optional, I dare to say that close to no-one will ever look at any unindented code that spans more than a few lines. Meaning, if you want to share code, indent it.

Good luck.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 05:15

@Helgef What do you think of the AutoHotkey Basic source code? Or alternatively the more recent versions? And do you have any examples of good and bad code or code manifestos, I've been meaning to collect some to critique them, they often contradict though!
User avatar
nnnik
Posts: 3061
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 06:10

Your line to line approach will probably fail.
The easiest way of approaching this is defining a group of Object that I will name CodeAreas in the following text.
One CodeArea may consume one or more Characters and contain any amount of other CodeAreas and checks itself where it ends but before that lets any containing CodeArea define itself by checking where it ends:

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

Msgbox( "Test()" . ((a**2)+(b**2))**0.5
, 2017 )
Msgbox( p* )
{
s:= ""
For each, val in p
s .= "`n"
Msgbox % s
return p
}
In the beginning the first CodeArea is named AutoHotkey Script it goes from the beginning to the end.
That CodeArea may contain several other CodeAreas and tests for them:
Msgbox( "Test()" . ((a**2)+(b**2))**0.5
, 2017 )
This is the first CodeArea it encounters it's an Expression.
The Code Area Expression then tests for the first CodeArea it contains or it's own end.
The first ( and only CodeArea ) the Expression encounters is a Function Call!!
The Function Call may contain one or multiple CodeAreas named FunctionParameters ( not Expressions ):
The first FunctionParameter first finds a CodeArea String then a CodeArea .Operator then a CodeArea BracketOperator ( that itself contains an Expression ).
...
Since the closing Bracket of the Function has not been encountered yet it will also start to consume the next line where it finds the second FunctionParameter.

And so on and so on....
The advantage of such a technique is that it is fairly easy to analyze the entire script and then only get and change the parts you want.
It will definitively be less than 2000 lines of code. Also you might be able to use it for more general purposes.
It will reduce the amount of exceptions you have by like 99%. It is very readeable and people might be able to help you because it is very modular code.
Recommends AHK Studio
guest3456
Posts: 2354
Joined: 09 Oct 2013, 10:31

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 12:26

Helgef wrote:As far as I know, there isn't really an official style guide for ahk. While indentation is optional, I dare to say that close to no-one will ever look at any unindented code that spans more than a few lines. Meaning, if you want to share code, indent it.


of course, but this genius was the one to self-proclaim that he writes readable code, after being condescending towards RegEx. turns out he doesn't even know how to use proper indentation and we get that beauty. one of the most delusional people on here

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

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 13:51

Btw guest3456 how long have you been on the forum, I don't remember
you much from the pre-2012 era.

guest3456, seriously calm it with the rhetoric.
What you fail to understand, is that I am mimicking you slightly.
Everything you accuse me of doing is just me mimicking you.
You are incredibly hyperbolic, and you are the rudest member
of this forum. I can't tell when you're being harsh friendly
or harsh harsh. You seem like Oscar the Grouch stopped
being a hobo and took up programming.
You remind me of Poly a bit.
Are you Anglosphere? Continental European?
It might be a language issue.
When you respond in a certain way, I respond in kind.
You touch me I touch you back. I respect you, and I respect
anyone with 100 comments+ here,
and I don't condescend users with fewer comments than that.
I've been here a month and I have 250 comments.
250*12=3000, at that rate, in 11 months' time I will be the 4th
greatest contributor to the new forum, behind
joedf, lexikos and just me.
I don't need AutoHotkey, I don't need to be on this forum,
I think AutoHotkey will be at least fractionally better off with me here.
Note well the phrase 'put up or shut up', you don't like my code,
indent it for me, link me a guide to code style, you say I'm
unreasonable on the Stack Overflow forums, post
the quotes on my offtopic page.
We need to be friends, because AutoHotkey has very few
major users here, that still visit regularly.
Together we will make AutoHotkey great again,
actually, it always was great.

[EDIT: Btw I remember Poly's presence on the forums, and he had a good avatar,
but I don't recall his personality in particular, so that point is neither true nor false, simply invalid.]
Last edited by jeeswg on 21 Jan 2017, 14:14, edited 2 times in total.
guest3456
Posts: 2354
Joined: 09 Oct 2013, 10:31

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 14:40

ok blame me. just like you blamed the stackoverflow people. all you do is blame everyone else. start taking responsibility for your own idiocy and change it, and then youll see people responding to you differently. but it probably won't happen. you'll "100% stand behind" your view and your approach, and remain delusional

you made claims about the v2 changes being dangerous, and you didnt even know what features v2 had. so because of that, you also don't know that a 100% compatible converter is impossible.

you would do better to be less certain about things in both AHK and life.

not only is your code unreadable, but so are your posts. why do you keep pressing enter?

Helgef
Posts: 3094
Joined: 17 Jul 2016, 01:02
Contact:

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 18:20

jeeswg wrote:@Helgef What do you think of the AutoHotkey Basic source code? Or alternatively the more recent versions? And do you have any examples of good and bad code or code manifestos, I've been meaning to collect some to critique them, they often contradict though!

I have no comments on this, I'm not sure why you ask.

jeeswg wrote:indent it for me, link me a guide to code style

online converter: converts your autohotkey code into pretty indented source code.
Indent_style - wikipedia, examples of indentation styles.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 19:26

@Helgef Cheers, 2 great links, plus the AHK one above.
No-one's ever complained about my scripts needing indentation,
here or on Stack Overflow, until now.
I use tabs when there are 3 lots of brackets,
but generally don't find them helpful.

I couldn't find an ahk version of the indenter JavaScript, I was thinking
about looking for one when the topic was raised.
Btw I had been curious about implementing a JavaScript
for doing hotstrings online.

Re. the AHKB source code, although I've been able to understand it,
it seems really messy to me and unnecessarily difficult to read,
it made me think that C++ was a messy language, but I think
that it can be as tidy as any language.
I think there's a lot of lower case variables, whereas AHK encourages CamelCase.
Perhaps there is a good text editor that can make it look better.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

20 Jan 2017, 19:45

@nnnik Thanks for your response. Although I can't guarantee it would work
on all scripts, my con. sec. checker did correctly identify all continuation section lines on my
script, a bit under 80K lines.

It seems that continuation sections must start with '(' as the first character of a line,
and end with ')' as the first character of a line, making them easy to find (when leading whitespace is removed),
as long as you can rule out false positives that start with '('.

I've created categories for all the individual lines, that leaves behind
multiline statements to be dealt with manually, so the final step for me
is dealing with parameters, which I've done before to an extent.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

21 Jan 2017, 17:47

==================================================

AUTOHOTKEY V2 COMPATIBILITY ISSUES:
[I may update this post as more issues are discovered]

A new era, I started using AHK v2 today (2017-01-21).
AutoHotkey v2 changes: 17 issues so far (all resolved/resolvable).
*So far* there are no obstacles to making all my current AHK v1 scripts
two-way compatible (AHK v1 and AHK v2 compatible).
I have managed to find adaptations/workarounds for everything thus far.

Note: I would welcome other people posting below,
their own lists of key compatibility issues, or otherwise links to such.

==================================================

MY DESCRIPTIONS:

[I now have functions for:][details to follow soon] (3)
- InStr negative position: InStr/SubStr/RegExMatch/RegExReplace, now -n indicates nth-to-last character
- returned parameter: last parameter is returned instead of first (e.g. 'Return 1, 2, 3', 'var := (1, 2, 3)')
- command style within expressions: e.g. MsgBox % "hello %var%", the var is resolved (correct terminology, 'resolved'?)

[not fully sure of the ramifications yet:] (4)
- &&/|| return value: && (AND) and || (OR) yield the value or 0 (rather than 1 or 0) [who knows what the consequences might be]
- variables (types): pure numbers and strings are now distinct types [not sure what this will do in practice]
- keys (objects): stored differently than on v1 in a few cases
- ControlMove/ControlGetPos/ControlClick: use client coordinates

[possible to correct lines in scripts:] (10)
- function definition default parameters: assign via ':=' instead of '=' (possible in AHK v1 since v1.1.09)
- IniRead: return default is blank rather than ERROR
- SendMessage: returns ERROR rather than FAIL
- Sort: input var and output var
- InputBox: parameters changed
- WinGet/WinSet/Process: various changes, new functions
- A_TitleMatchMode: default is 2 [this could be a little annoying, in theory it won't make any difference, otherwise I'd have to change every thread] [EDIT: can be set to another value in the auto-execute section]
- #SingleInstance: default is prompt mode, #SingleInstance on its own sets force mode
- CoordMode: default is Client (added in v1.1.05)
- ternary operator: must specify the alternative result

==================================================

DOCUMENTATION DESCRIPTIONS:

All from:
v2-changes
https://autohotkey.com/v2/v2-changes.htm

- A negative StartingPos for InStr, SubStr, RegExMatch and RegExReplace is interpreted as a position from the end, starting at 1.
- The result of a multi-statement expression such as x(), y() is the last (right-most) sub-expression instead of the first (left-most) sub-expression.
- Text and output var args and quoted strings can contain not only %variables%, but arbitrary expressions between percent signs.

- The operators &&, ||, and and or yield whichever value determined the result, similar to JavaScript and Lua.
- Address-of: Since pure numbers and strings are now distinct types, &(var := 123) now returns the address of an int64 instead of the address of a string. For consistency, VarSetCapacity returns 6 (the size of int64 minus a null terminator).
- Keys are stored differently than on v1 in a few cases
- ControlMove, ControlGetPos and ControlClick now use client coordinates (like GuiControl) instead of window coordinates.

- := must be used in place of = when initializing a declared variable or optional parameter.
- IniRead defaults to an empty string when the Default parameter is omitted, instead of the word ERROR.
- SendMessage sets ErrorLevel to ERROR instead of FAIL when it fails, for consistency with Run.
- Sort: the VarName parameter has been split into separate input/output parameters, for flexibility.
- InputBox, OutputVar [, Title, Prompt, Options, Default]
- Sub-commands of WinGet, WinSet and Process have been replaced with individual functions, and the main commands have been removed.
- Title matching mode defaults to 2 instead of 1.
- #SingleInstance prompt behaviour is default for all scripts; #SingleInstance on its own activates Force mode.
- CoordMode defaults to Client (added in v1.1.05) instead of Window.

[where in the documentation?][my choice of words] [EDIT: not in the documentation explicitly, one of many minor errors]
- (ternary operator: must specify the alternative result)

==================================================

TERNARY OPERATOR ISSUE EXAMPLE:

A minor issue but it is curious.
I think it's good for this to be the new default.

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



==================================================
Last edited by jeeswg on 21 Jan 2017, 20:35, edited 1 time in total.
lexikos
Posts: 6039
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

21 Jan 2017, 19:05

A_TitleMatchMode: default is 2 [this could be a little annoying, in theory it won't make any difference, otherwise I'd have to change every thread]
It's exactly the same as including SetTitleMatchMode 2 in the auto-execute section, which the New AutoHotkey Script template has done for many years.
ternary operator: must specify the alternative result
The real change here is "Many errors which caused silent failures now cause an error message (some at load time)." It was always invalid to omit any of the three operands of the ternary operator. If you omit an operand, by definition, it is no longer ternary. There were many small changes to error-handling, and since most of them do not contradict the v1 documentation, I didn't feel the need to document every small change.
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

21 Jan 2017, 19:58

Re. SetTitleMatchMode, thank you, I realised later to read up on the auto-execute section (been a long time since I touched it), in case the following defaults can be set permanently: A_DetectHiddenWindows / A_StringCaseSense / A_TitleMatchMode. [EDIT: Whew, it does all 3 and other values.]

Re. the ternary operator. I've planned some line-by-line-as-an-individual-script testing to check for rare errors. I often use the following one-liner:
(vWinClass = "Winamp v1.x") ? (vUtil := "Winamp")
It'll now be the following, which is no problem to correct:
(vWinClass = "Winamp v1.x") ? (vUtil := "Winamp") : ""
I don't know if there's a better way.

===============

The other essential hack that AHK v2 breaks for me, which I have a fix for, is my one-liner that I use all the time, to 'set and break' from a loop:
if vCond
if (1, vMyVar := A_LoopField)
break

I could make it the following, to make it two-way compatible, but yeesh it's ugly now:
if vCond
if (1, vMyVar := A_LoopField, 1)
break

Instead I could do:
if vCond
if FuncAlwaysReturnTrue(vMyVar := A_LoopField)
break

or:
if vCond
if (vMyVar := A_LoopField) OR 1
break
lexikos
Posts: 6039
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

21 Jan 2017, 22:23

The other essential hack ...
I would rather call that a dirty method of obfuscation, certainly not essential. It isn't even a "one-liner". Using braces to group statements is a fundamental part of the language. Why work around it?
User avatar
jeeswg
Posts: 4778
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

21 Jan 2017, 23:43

Sometimes I add brackets that aren't strictly needed for clarity.
Sometimes I remove brackets to get 2 lots of brackets rather than 3 for clarity.

I guess I also feel that in theory, if it were possible,
the code should be:
if vCond
vMyVar := A_LoopField, Break()
so it deserves not to have the brackets.

Btw is there nothing better for
'if A then do B (else do nothing)' than:
(vWinClass = "Winamp v1.x") ? (vUtil := "Winamp") : ""
Thanks.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 3 guests