[a103...a132] continuation section start mark: persistent bug

Report problems with documented functionality
User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

[a103...a132] continuation section start mark: persistent bug

Post by vvhitevvizard » 20 Apr 2021, 07:19

(bug) Concerning line continuation section start mark.
https://lexikos.github.io/v2/docs/Scripts.htm#continuation
If a line begins with a non-escaped open parenthesis ((), it is considered to be the start of a continuation section unless there is a closing parenthesis ()) on the same line.
That brings issues of mixing continuation section with expressions divided by continuation prefix:

Code: Select all

a:=1
(b(0
, 0)) && a:=2
In the above snippet one would expect Line 1 is completed and not connected to line 2,
Line 2 starts with an expression in parenthesis (function call with 2 args) and that expression's result used as 1st operand of && operator.
When a regular continuation section starts, it looks like

Code: Select all

Var := "
(
Line 1 of the text.
Line 2 of the text. By default, a linefeed (`n) is present between lines.
)"
so ( of a continuation section's start mark is a solo opening or closing parenthesis and not followed by a variable or operator or other stuff we expect to be within an expression.
The current state leads to the following preprocessor printout (the same behavior with AHK v2 builds 103,108,115):

Code: Select all

Error at line 1.
Line Text: a:=1, 0)) && a:=2
Error: missing ")"
WOW. In "Line Text" printout (b(0 disappeared! between lines 1 and 3. So AHK simply ignored leftovers that followed opening (. That's totally counter-intuitive.
another example
Request: In order to let lines starting with an expression to co-exist with continuation sections, start mark for the latter should be considered only when its a solo parenthesis on the line. And the closing section mark to be ) or )", )', )` respectively.

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: [a103...a132] continuation section start mark: persistent bug

Post by lexikos » 20 Apr 2021, 17:20

start mark for the latter should be considered only when its a solo parenthesis on the line
No. That would mean the continuation section options no longer work.

This isn't a bug, and you've already pointed out the documentation describing this behaviour as correct. Your line (b(0 starts with an open parenthesis and there is no closing parenthesis on the same line, therefore it is considered to be the start of a continuation section, as documented.

Any invalid continuation section option (such as B(0) could prevent it from being interpreted as a continuation section. This was not done because 1) it makes differentiating between expressions and continuation sections more complicated, 2) it prevents options from being added in future without greater potential of breaking scripts, and 3) it encourages poor style, such as in your example. If your condition is long or complex enough that it must span multiple lines, you should begin with a proper IF, not use &&; or you can evaluate the condition separately, using a function or temporary variable.
And the closing section mark to be ) or )", )', )` respectively.
I see no reason to make this restriction. Also, )` has no meaning. To be clear, )" never was a "continuation section mark"; the continuation section ends at ), and joins lines with whatever follows the close parenthesis.
So AHK simply ignored leftovers that followed opening (. That's totally counter-intuitive.
Yes, I suppose it should display an error, because your continuation section options are invalid.

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: [a103...a132] continuation section start mark: persistent bug

Post by vvhitevvizard » 21 Apr 2021, 08:05

@lexikos Thank u for the explanation.
it encourages poor style, such as in your example.
There r reasons to put an expression to the left in parenthesis and some expressions might be long enuf to fit into a single line. That's frequent in use compared to continuation sections with specific options. It has nothing to do with poor styling - replace short-circuit conditional branching with ternary operator expression and u get the very same unintuitive behavior:

Code: Select all

a:=1
(b(0
, 0)) ? func1() : func2()
Just imagine the 2nd line expression is long enuf to be divided into several lines.
1) it makes differentiating between expressions and continuation sections more complicated
Maybe start mark/end mark should be replaced with c-like multiline comment marks */ /* or something like that to fight the root of the problem? :D
Yes, I suppose it should display an error, because your continuation section options are invalid.
Yes please. It cannot accept it then it should flag an error for starters.

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: [a103...a132] continuation section start mark: persistent bug

Post by lexikos » 21 Apr 2021, 22:34

vvhitevvizard wrote:
21 Apr 2021, 08:05
It has nothing to do with poor styling - replace short-circuit conditional branching with ternary operator expression and u get the very same unintuitive behavior
Also poor style. Obviously, the person using poor style isn't going to think of it that way.

If your condition is long or complex enough that it must span multiple lines, you should begin with a proper IF, not use ternary; or you can evaluate the condition separately, using a function or temporary variable.

(Déjà vu? I said this already about &&.)

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: [a103...a132] continuation section start mark: persistent bug

Post by vvhitevvizard » 22 Apr 2021, 06:44

@lexikos I beg to differ. It cannot be justified just by "poor style usage". In the examples I used my styling, but lets put it straight: legitimate language lexems usage (subexpression in conjunction with line continuation) conflicts with continuation section syntax and might lead to that unexpected behavior.

Concerning style, we can argue what can be classified as low readability but better let a user to choose.
I, for one, prefer the whole algo to fit on the screen using lots of inlining and getting rid of excessive temporary variables. And the majority using Python would say the same: the condensation of expressions is very convenient for scripting languages. E.g.: Python's loops inside array's square brackets: [f(x) for x in xs if condition] and nested loops within 1 line: dif=sum(abs(c1-c2) for p1,p2 in pairs for c1,c2 in zip(p1,p2)). Check it urself: the majority don't break down such lines into a multitude of flow control statements. Not to mention that if-else blocks and additional temporary variables lose vs conditional branching within expressions performance-wise in AHK.

User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: [a103...a132] continuation section start mark: persistent bug

Post by kczx3 » 22 Apr 2021, 12:48

Agree that it is to each their own however in scripting languages I see zero reason to make such a statement/expression so difficult to read and reason about. Code size isn't really a factor here like how it is with JS and delivering assets over the network. Your Python example with nested loops on one line makes my head spin and I'd never recommend that to anyone. Performance considerations don't apply in my mind if they are negligible and only noticeable via benchmarks.

At the end of the day, Lexikos gets to dis/allow whatever syntax he wants in this language.

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: [a103...a132] continuation section start mark: persistent bug

Post by lexikos » 22 Apr 2021, 17:08

vvhitevvizard wrote:
22 Apr 2021, 06:44
It cannot be justified just by "poor style usage".
And it wasn't. That was reason number 3.

User avatar
vvhitevvizard
Posts: 454
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: [a103...a132] continuation section start mark: persistent bug

Post by vvhitevvizard » 23 Apr 2021, 10:46

At the end of the day, Lexikos gets to dis/allow whatever syntax he wants in this language.
I agree, over the years, lexikos has proven his concept of the new AHK language to have a success. :superhappy: I just felt like I should leave some feedback [again] on this weird behavior.
Your Python example with nested loops on one line makes my head spin and I'd never recommend that to anyone. Performance considerations don't apply in my mind if they are negligible and only noticeable via benchmarks.
@kczx3 That concise notation is one of the factors Python is so popular actually.
Optimization depends on - sometimes there r 2 options - rewrite the algo in compiled language version or simply resort to optimising AHK version - if I write library functions OR nested loops I make sure those r optimized at least. AHK becomes more versatile and less and less error-prone (good stuff!) but at heavy cost of performance degradation.

Post Reply

Return to “Bug Reports”