This article was first published on Zilliqa — Official Blog - Medium
A Debugger for Scilla : The Beginning
Writing good computer programs is hard. Debugging them is, more often than not, harder. While bugs are inherent to software programming, certain classes of programming languages avoid many types of bugs by making such bugs impossible to exist. So while you can have memory leaks in a C program, Java’s garbage collector makes sure that you don’t have to manage memory, thus avoiding this whole class of bugs.
Scilla was designed to prevent entire classes of bugs such as memory leaks, memory access violations, and with a guarantee of termination (i.e., any Scilla code execution always terminates). This does not however mean that Scilla code cannot have bugs at all. Functional bugs (i.e., bugs in the business logic coded, for example) cannot be avoided. While we also have on-going efforts on tools for formal-verification of Scilla programs, a tool to aid debugging of Scilla programs is still a necessity.
Debuggers, in contrast to what the name indicates, do not fix bugs. They are tools that programmers use to find the cause of bugs. Typically, debuggers enable executing a program (along with its inputs) step-by-step and viewing the values of program variables during this controlled execution.
The process for debugging Scilla programs, today, is not straight-forward. To find the code path that a particular execution follows, programmers must insert eventstatements (as a substitute for printf debugging). It is cumbersome most times to add extra code just for debugging and ensuring to delete them later. A debugger for Scilla can make life easier.
Instead of writing a debugger from scratch, we’ve decided to piggy-back on our ongoing Scilla Compiler (+VM) project and develop debugging tools in that framework.
The Scilla Compiler and VM
Sometime back, we wrote about a compiled ...
To keep reading, please go to the original article at:
Zilliqa — Official Blog - Medium