uiua-lang / uiua

A stack-based array programming language
https://www.uiua.org
MIT License
1.59k stars 116 forks source link

Enable naming stack values for debugging. #79

Closed bhansconnect closed 8 months ago

bhansconnect commented 1 year ago

Especially when modifying a complex function, it can become easy to mix up stack values. This is made much worse by some functions where most values are the same shape. It can be easy to be left with a stack of values that are too big to print (or even worse, not very meaningful if printed), that are the same shape, and that are accidentally out of order. The only visible symptom is the final output being wrong.

Being able to somehow annotate a stack value with a name that will flow it around as it is moved and duplicated on the stack would be very useful. The name would clear whenever doing any modifying operation (I think that would be most ergonomic). Then a parallel to dump could be added dumpnames. Not sure on best names, but could theoretically work like this:

name "x" [1 2 3]
name "y" [4 5 6]
dumpnames
# "x"
# "y"
,
dumpnames
# "x"
# "y"
# "x"
+
dumpnames
# "x"
# "" If we want to be super helpful maybe we could print "unnamed with shape ..." or just the shape for unnamed things.
kaikalii commented 1 year ago

Would names be maintained if values were modified? Or just when they were copied/moved?

bhansconnect commented 1 year ago

I was thinking only when copied or moved. You would have to rename if you modify.

Two other seeds of ideas that might also solve alleviate problem: 1) Some form of trace mode that could derive automatic naming. The name would just be where the tensor was created originally. So it would point to a location in the source code instead of using a proper text based name. 2) Essentally a debugger: some way to step through code. Simply having that and being able to view the stack or stack shapes as you step through code probably could alleviate most of the pain.

kaikalii commented 1 year ago

Essentally a debugger: some way to step through code. Simply having that and being able to view the stack or stack shapes as you step through code probably could alleviate most of the pain.

So, the body of the main loop of the bytecode interpreter could probably be factored out to be "resumeable", which could potentially enable this. The question becomes: How do you handle breakpoint setting?

jshholland commented 1 year ago

It might be worth a play with the Factor walker to see one approach.

goyalyashpal commented 1 year ago
  1. Some form of trace mode that could derive automatic naming. The name would just be where the tensor was created originally. So it would point to a location in the source code instead of using a proper text based name.

+1 for this one

-1 for text based naming

bhansconnect commented 1 year ago

Here is an example where I struggle and just decided to explicitly name everything on the stack with comments. This is what I am hoping to solve for myself.

almost all the data on the stack at one time is:

  1. too big to print reasonably
  2. of the exact same shape

https://github.com/bhansconnect/uiua-raytracing/blob/292f16cd6137ba270ae1e407dae431403d9b4faf/main.ua#L46C1-L79

kaikalii commented 8 months ago

The experimental labels, which use the syntax $LabelName, implement this feature.