Syntax colouring

[Phil Last]

In a function, there's often a good reason to embed an in-line dfn inside parentheses:

[3]   a←({whatever}⍺)this ⍵

Having done that there's often a good reason to extend the inner dfn with extra lines:

[3]   a←({whatever
[4]       and something else
[5]   }⍺)this ⍵

Not noticable in this forum but sytax colouring now highlights the parentheses because on a line-by-line basis they are individually unbalanced.

Before someone who hasn't noticed this yet gets a chance to act to the contrary I'd like formally to register my prior objection to any future attempt to turn this enormously useful feature into a bug report.

[JohnS|Dyalog]

I have added a regression test (ref 5601) to our QA suite, so that we don't accidentally "fix" this behaviour:

Code: Select all

    ∇ ok←m5601    ⍝ Preserve behaviour of parenthesised multi-line dfn.
[1]   :Trap 0
[2]       ok←5=({
[3]           ⍵
[4]       }2)+3
[5]   :Else
[6]       ok←0
[7]   :End
    ∇


I have also logged a low priority issue (ref 5603) to address the misleading syntax colouring of the parentheses.

[Phil Last]

Thanks for prompt response and action but:

I seem quite good at persuading people that I mean the opposite of what I'm actually trying to say, perhaps it's the triple negatives, I don't know.

Anyway, I didn't assume anyone would ever object to being able to split a dfn across multiple lines even if it IS parenthesised.

What I was hoping would be KEPT in the face of a future objection is the syntax colouring AS IT IS.

Highlighting these parentheses is akin to highlighting a control structure AND IS A GOOD THING because it aids the visual understanding of a complex expression.

I now find myself the instigator of the very issue (ref 5603) that I was hoping to avoid.

The reason I posted it was because so often, not just at Dyalog but in all walks of life, people live happily with things that might arbitrarily be seen as anomalies and even find uses for them until others come along and tidy them up for no other reason than that they love tidying things.

If no prior comment has been made the change is already a fait accompli and a request for its reintroduction is bound to fail as no-one would ever deliberately introduce an anomaly.

[JohnS|Dyalog]

Phil, apologies for misunderstanding your post. I will add your comments to 5603, so that we consider them before deciding whether to "fix" the syntax colouring.

This is all part of a wider problem that we have some work to do on "multi-line expressions". In classic APL, an expression cannot span more than one line, but with dfns, we can have a single expression such as:

Code: Select all

    2+3{
        ⍺+⍵
    }4+5

which can extend over any number of lines. In general, the indentation provides a strong hint about what is going on but we may be able to improve this.

A related issue is with the tracer. When poised to execute the above expression, perhaps it should highlight the whole of it, rather than just the last line. Or would this be too loud a visual noise for a many-line expression?

[Morten|Dyalog]

I agree that we want to have some form of additional highlighting of this structure, but I don't think we should do it by marking the unmatched parentheses as an error! What if there WERE really unmatched parentheses on the line, etc?

[Phil Last]

What if there WERE really unmatched parentheses on the line, etc?

Then one would look and see and more than likely there would be an odd number of them and one would correct it. As it is, in a single-line statement the colouring doesn't tell one exactly what's wrong in the sense that it might be an inner or outer pair that's lacking a member and it misses the entire class of errors with intertwined parentheses, brackets and braces epitomised by:
      a(b[c)d{e]f}g
We're more intelligent than our computers. We can deal with it.

I almost wish I hadn't mentioned it. There were probably only a dozen people who'd noticed it anyway. One actually has to be coding un-named in-line multi-line dfns to encounter it. But now it's out in the open I'd better point out that it's exactly the same for brackets. And remember that it's only actually valid if the pair surrounds a multi-line dfn.

My advice and request is still that you leave well enough alone. By all means if you want to commit the resources to do all the analysis required to highlight in a different colour a new class of syntactic anomaly when it's already done satisfactorily by default it's entirely up to you but please don't just suppress it as being a normally valid use and therefore not highlighted at all.

Just one more comment: the reason I like it the way it is now is that it reminds me that the expression is getting too complicated and needs to be broken up! I don't have a single (multi-)line of code stored that displays this feature.