We currently have a haphazard collection of debugging features in CodeWorld. These fall into two basic categories: the inspect window, and the on-screen controls. Both of these are powerful, but they follow completely different design choices, and have two different UI and API systems. This adds too much complexity, both for the user, and in the code.
The inspect window UI is implemented in JavaScript, and communicates with the running program via a set of callbacks and global functions set up in JavaScript. It's implemented inside of runInspect, and generalizes the standard CodeWorld model with arbitrary event delivery so it can talk to the JavaScript UI.
The on-screen controls are implemented entirely in Haskell with the CodeWorld API. They wrap the underlying program so that the entire program, including debugging, acts like a single CodeWorld program.
Ideally, the entire debugging UI would be implemented in one place -- most likely, in JavaScript and DOM since it's a more powerful UI system. There would be a single API based on message passing that's implemented in a generic way and documented so that it's easy to develop against.
(@kammitama5: Don't worry, this is a long-term goal. The current system is fine for now, and you should keep developing with it for Summer of Code.)
Thanks. I'd like to keep working on getting better at Haskell (and reasoning with code written in Haskell) and keep contributing to CodeWorld in any way I can in a long-term capacity.
We currently have a haphazard collection of debugging features in CodeWorld. These fall into two basic categories: the inspect window, and the on-screen controls. Both of these are powerful, but they follow completely different design choices, and have two different UI and API systems. This adds too much complexity, both for the user, and in the code.
runInspect
, and generalizes the standard CodeWorld model with arbitrary event delivery so it can talk to the JavaScript UI.Ideally, the entire debugging UI would be implemented in one place -- most likely, in JavaScript and DOM since it's a more powerful UI system. There would be a single API based on message passing that's implemented in a generic way and documented so that it's easy to develop against.
(@kammitama5: Don't worry, this is a long-term goal. The current system is fine for now, and you should keep developing with it for Summer of Code.)