Given this code:
Code: Select all
Foo←{
a≡1:DoThis ⍬
a≡2:DoThat ⍬
0
}This is the dfn aquivalent of a :Case structure in a tradfn:
Code: Select all
∇r←Foo arg
[1] :Select a
[2] :Case 1
[3] DoThis ⍬
[4] :Case 2
[5] DoThat ⍬
[6] :EndSelect
[7] r←0
∇It's obvious why many find the dfn construct appealing: much less code.
However, when it comes to tracing through such a structure the dfn is a nightmare. The reason is that for the Dyalog Tracer a line is the smallest unit of operation, so when the Tracer is on line 1 and the condition is not true then it carries on to the next line. No problem. But when the condition is true the expression
DoThis ⍬is executed as well, and (worse) the Tracer returns to the line where the function "Foo" was called from.
When tracing through the code while hunting a bug I am often forced to copy the condition to the session and execute it there in order to find out whether it is true or not.
What should happen is that when the Tracer enters line 1 it should highlight just the condition: the stuff to the left of the colon.
If the user then presses <enter> and the condition is true then the Tracer should highlight the code to the right of the colon. For that code to be executed the user needs to press <enter> again.
That would improve things a lot.
By defining tokens in a different way than just lines as a side effect the Tracer would also be able to handle this:
DoThis 1 ⋄ DoThat 2
Rather than executing this in one go it should first highlight just "DoThis 1" and execute this (and only this) in case the user presses <enter>. Then "DoThat 2" should be highlighted and so on.
Now this is a major change to the way the Tracer currently works. Major change means major investment. Dyalog would do this only if they believe that their customers want this. Therefore, if you are in favour of this enhancement, you should voice your opinion, because otherwise it is unlikely to happen.
