Parser off-by-one error? Or operator error?

[petermsiegel]

Why does the expression with the unbalanced parentheses below not trigger an error, while the expression with balanced parentheses triggers an error signalled by the interpreter? In both cases, the increment requested only happens to the first part of the expression (a.A a.B are incremented, but b.A is not). There must be a rule about grouping with dot notation vs grouping for assignment. (A different error occurs with ∘←.)

      )clear
clear ws
        'ab'⎕NS¨⍬ ⍬            ⍝ Create namespaces 'a' and 'b'
        a.B←1+a.A←1            ⍝ Assign two vars in a
        b.A←100                ⍝ Assign one var in b
        a.A a.B b.A            ⍝ All is well 
1 2 100
       ((a.(A B)b.A)) +← 1     ⍝ Increment the vars. Proper syntax, but error!!!
SYNTAX ERROR: Unpaired parenthesis
      ((a.(A B)b.A))+←1        ⍝ Note: the parens are balanced!!!
      ∧
        a.A a.B b.A            ⍝ The increment half-succeeded before the error
2 3 100                        ⍝ Why isn't b.A incremented???
       (a.(A B)b.A))+←1        ⍝ Try again, but LEAVE OFF the leading left paren.
         a.A a.B b.A           ⍝ Unbalanced parens, but no error message
3 4 100                        ⍝ Another half-success...

Of course, the workaround is to use (a.A a.B b.A), but where's the fun in that? NB: This isn't the actual code I'm trying to run, but a simplification for perspicacity.

]Version
Dyalog 18.2.45405 64-bit Unicode, BuildID a02bc166
OS Darwin 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct 9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64

[Vince|Dyalog]

Hi Pete,

Thanks for reporting this.

We can reproduce the issue and have logged it as 21018.

Regards,

Vince

[Vince|Dyalog]

Hi Pete,

I think that this problem has been in all versions of Dyalog since 10.0 in 2003.

My developer colleague Silas has been looking into this. This is what he has told me:

The problem is testing that valid strand assignment statement must evaluate names within the brackets –here (A B) – and resumes execution in wrong place!

This smaller case reveals the problem too, with evaluation continuing at the inner )
A←b←0
(#.(A) b)←1
A b≡1 0 ⍝ NOT 1 1

Regards,

Vince

[petermsiegel]

Thank you. I had the feeling the parser error (feature?) had been there a while. That said, because it's not proscribed, it takes me a few days of intermittent troubleshooting to remember that I need to break up the assignment expressions when moving from simple (undotted) variables to more complex ones. At the same time, even if the parser accepts unbalanced parentheses in cases like this--

Code: Select all

    a←b←0
    (#.(a) b))←1 ⍝ Dyalog APL accepts this with an extra parenthesis!!!

--my brain doesn't!

I used to teach APL and the hardest thing is explaining to students NOT to test the limits of the syntax.

Cheers