Feature request regarding the Tracer

[kai]

The Dyalog Tracer has not seen any kind of makeover for a long time. With dfns becoming more and more popular there is a need for such a makeover.

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.

[ray]

I am now retired, and only use APL for Robots running APL on Raspberry Pi's via RIDE, or my virtual Ants running under Windows on a PC.

Personally, although I like dfns, I seldom actually use them in practice.

I don't think I have ever tried debugging a dfn via RIDE.

Part of the reason I don't use dfns that much, is because of the difficulties in debugging them using the tracer.

So, if Dyalog want to encourage the use of dfns, then I think the tracer should be improved along the lines Kia has suggested.

[RichardP|Dyalog]

New APLers love dfns.
I personally think this type of tracing would be good but I'm not sure what time and effort is required to implement it and whether this is worth dropping other things over.

I'm not sure how much you should abuse guards in place of switch:case/select:case but I also don't use this type of construct very often so far (outside of tradfns, and even then). IMHO dfns should be more functional and less conditional, but that's just an opinion I guess.

[Ziggi]

Yes I am very much in favour of the Tracer working for dfns, as long as none of the functionality for the traditional fns is lost.
The main reason I don't use Dfns more is the lack of debug tools.

[gil]

I would love to see this feature. At the moment I have to keep my finger on the Ctrl button when tracing dfns just in case I overlook a branch. In the case I end up tracing into a function I'm not interested in I then resume to exit (which I have set up a keyboard shortcut for). It's doable, but not as smooth as it could be.

In terms of priorities I think it would be useful for Dyalog (and its customers) to have a dedicated, public place to keep track of issues and feature requests separate from the forum.