[racket-dev] stepper UI question

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