On 10/06/2010 12:37 PM, Everett Morse wrote:
I was just trying to debug a program today that goes through a series of
complex macros. I used Check Syntax so I can see what variables are
bound where (some of which are syntax variables), and when I got stuck I
wanted to see how the macro reduces. I clicked the macro stepper, and it
spun for a long time before crashing Racket (this is the dev version,
5.0.1.7--2010-10-04).
I'll see if there's anything I can do to make it more responsive.
It occurred to me then that the best way to do this would be to select
some piece of code in the editor and tell DrRacket to expand it, but
just that one spot. (It would have to know the macros defined in the
editor, but I already ran check syntax and the code is already compiled,
so somewhere it ought to be able to grab the definitions.) This would
avoid a long wait for parts I'm not interested in. If I was stupid
enough to select code that does expand right, that's my fault.
Check Syntax gathers far less information than the macro stepper. But if
you just want to see the fully-expanded code for some subexpression, you
could probably bolt that on to Check Syntax fairly easily. (Whether
that's a good idea is another question... and if you do add it, make
sure it doesn't show up in the teaching languages!)
As to selectively expanding things in place in DrRacket, you're right:
it's not easy.
Ryan
Anyway, this probably isn't easy, practical, etc. But it is what I
naturally looked for and so I consider it the ideal. The macro stepper,
as is, is too slow and hard to focus in on the right place.
-Everett
On 08/27/2010 07:39 AM, Shriram Krishnamurthi wrote:
I can think of many different ways to make the stepper<->definition
correspondence manifest. As John said, I once suggested that the code
should be reduced in-place, in the definition window. Shriram doesn't
like that idea (but he has never bothered to say why.)
That's right, I didn't.
Here's why. It introduces subtle state into the editor.
If you start stepping, and then try to Save, are you saving the
stepped version or the original?
If you start stepping, forget that you are doing that, and then start
editing, what are you editing?
If you step, does it affect the unsavedness of the editor?
(Presumably not.)
If I have a textual program, and step, does it next save in graphical
format? (I wouldn't want that.)
One way to prevent some of the more egregious problems is to make
stepping a mode. That brings its own problems -- how do you make it
not suck, how do you focus attention on it, etc.
I think people have a clear model of what an editor is: it's like
Word, like the text box of GMail, etc. Each one offers some
highlighting feedback and some rich-text editing -- but it's just an
editor. It's not a place where programs run. Putting the stepper
into the editor in a model way really messes with that.
I certainly agree with you (and have always agreed with you, for the
many years we've talked about this) that losing the correspondence to
the source program is a problem. But I don't think putting it in the
editor is the solution. I do find Ryan's suggestion -- to use
highlighting in the editor -- very intriguing. We already highlight
in the editor, and it's pretty unintrusive. In that style, it might
even be possible for a stepper window to combine highlighting with
showing *just* the current redex, and giving the user the option of
expanding the scope of attention (ie, show me more of the current
expression when I want it).
Shriram
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
