Easier macro debugging

[cwebber]

I'm currently writing a larger program in Hy. Coding in Hy is a dream.. debugging is a headache. The reasons are simple: line numbers are lost in the context of any macros, and of course plenty of things in Hy are macros. In one of @paultag's demos he shows that using pdb with Hy works surprisingly great, but of course this presentation didn't show anything wrapped in a macro, in which case all information and context is lost. You're debugging blind: you still have other senses, but sight of line numbers isn't one of them. Similarly with tracebacks.

The problem is that have no idea what will come out of a macro, and even if we did, we lose track of it by the time it comes around to the AST being generated.

Is this unsolvable? Maybe. But other languages have done better:

• Emacs Lisp and Racket both allow for stepping through macros. Many lisps do not provide it, and both of these do something clever to provide it.
  • Emacs lisp has users "instrument" macros with specifications. You can step through functions using edebug much the way you can step through things with pdb.set_trace(). It relies on the specification to figure out what is happening somehow.
  • Racket allows for some sort of macro debugger.
• Guile and Racket both have tracing, and Racket even has macro tracing (whatever that is).
• Probably if we had something like define-syntax in scheme and encouraged users to use that, it would be easier to infer some of these structures.

Is it impossible for us to do this? I don't know... I think that if emacs lisp can have a sense of where things are, probably we can. At the very least, once we build AST, we might be able to use some information from macro expansion (or at least, certain common patterns of macro expansion using some sort of define-syntax system) to be able to debug things.

The current state of things is pretty sorry anyway. I'd like them to become better. Feel free to use this thread to dump ideas.

[cwebber]

Alternately, if other core developers decide "there's no way forward" or that this bug won't provide a useful dialogue, feel free to close it.

[cwebber]

DrRacket seems to have even more debugging features, but how do those work? How are you able to so easily set breakpoints and step through, from a GUI even? What sorcery is this? I'd love to hear more from someone who knows.

[cwebber]

Note, @paultag says pdb will probably never be able to help with this. But maybe hdb could?

I don't know that tracebacks could be made easier but maybe at least hdb could make debugging nicer.

What would it do? I'm not sure, but a crazy idea is that it might write information about Hy lines to a hdb-readable-only object, or something?

[refi64]

Last time I tried hdb, it removed the concept of newlines from my terminal. And crashed.

I rarely use debuggers; I only touch them when doing assembly programming. Usually, I just shove print calls everywhere.

Also, my best friend while writing HyTest and Hyskell has been hy2py. It really helps.

[cwebber]

Oh, I was making a joke about hdb, is there such a thing?

[cwebber]

@kirbyfan64 The point about hy2py is really good. Maybe hdb could have an easy "py-l" command which prints out where you'd be from a hy2py perspective if running "l" in pdb? That could help, and would be easy to write I think.

[tianon]

Being still pretty green to Hy myself, I can say for sure that this is one of the first things that turned me off really, really hard -- macros can sure look clean and neat when they're working, but when one breaks, abandon all hope.