find-expr: find a corresponding expression in the definition window

[Sorawee Porncharoenwase]

Hi Racketeers,

I prototyped a language and a DrRacket plugin that allow you to find a corresponding expression in the definition window from the interaction window. See the following GIF for the demo:

(FWIW: this feature was a wishlist in Pyret. They ended up implementing the spy statement instead, but IMO it serves a different, orthogonal purpose).

The prototype is finished and can be found here. Any feedback would be appreciated. In particular, I have the following question:

1. find-expr / drracket-find-expr is a poor name. Any suggestions?
2. Is it possible to make this a pure DrRacket plugin and no need for a new language? My thought is no because I need the srcloc information of each toplevel expression, which seems to require modifying #%module-begin. I’d love to be proven wrong though.
3. How do I make it less hacky? Currently, I write-special the icon which defines a special method and make the DrRacket plugin spams sending this special method message to every snip whenever the interaction window changes (which could either result in a method invocation or a method not found error —- which will be caught and ignored). Surely there is a better way. I thought of using is-a? to check if a snip is the object I’m looking for, but the test always returns negative (presumably because the object is constructed in user space but the check is done in DrRacket space?)
4. Alternatively, is it possible to create a DrRacket plugin that sets user parameters? The only examples I saw are either non-module based languages (e.g., teaching languages) or parameters that DrRacket has a special support (e.g., current-command-line-arguments). Neither is feasible for my use case.
5. What about the other direction? Can we go from the definition window to interaction window? What should the UI look like?

By the way, here are known bugs / changes I intend to make in the future:

1. Provided that we really need to make a new language, make it a meta language instead so that one could write, e.g., #lang <meta-lang-name> typed/racket.
2. Use a different color for highlighting (currently I use the error highlighting method).
3. Support spy statements, just like Pyret.
4. Make it work in non-debugging mode.

Thanks!
Sorawee (Oak)

[Robby Findler]

Imagine that DrRacket had a way that you could write special to the current-output port (or, more precisely, to a port that was connected to the interactions window) and that port would specially recognize that thing you wrote such that it would come out as a checkmark but clicking on it would set the insertion point and add highlighting (as you've done). If I understand the demo correctly, then you could do what you've done here by changing #%module-begin to change how printing the values of top-level expressions worked such that it did a write-special of that new kind of value and then just did what printing usually does.

Am I getting the behavior properly?

Robby

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CADcuegtHusXDP55EmNVT1xkX3Rmi-z%3DOCVR4-%3DQ2VSWQaophNg%40mail.gmail.com.

[Michael Sperber]

Robby Findler <ro...@cs.northwestern.edu> writes:

> Imagine that DrRacket had a way that you could write special to the
> current-output port (or, more precisely, to a port that was connected to
> the interactions window) and that port would specially recognize that thing
> you wrote such that it would come out as a checkmark but clicking on it
> would set the insertion point and add highlighting (as you've done). If I
> understand the demo correctly, then you could do what you've done here by
> changing #%module-begin to change how printing the values of top-level
> expressions worked such that it did a write-special of that new kind of
> value and then just did what printing usually does.

Robby's hinting at the fact that we're working on such a thing - i.e. a
tiny combinator DSL for "markup" that includes the ability to make
clickable links into source code.

I hope it matches what Sorawee has in mind. If so, that would be an
indication we're moving in the right direction.

Technical question for Robby: How should we represent the icon?
Just a bitmap% object?

--
Regards,
Mike

[Robby Findler]

On Tue, Aug 25, 2020 at 3:19 AM Michael Sperber <spe...@deinprogramm.de> wrote:

Technical question for Robby: How should we represent the icon?
Just a bitmap% object?

A bitmap is a good choice (safe because the data of the bitmap can be extracted and then turned into a safe bitmap% object on the drracket side). And this has me thinking that we also want to take advantage of record-dc here. 

That is, I think a good way to do that is to use the file/convertible interface (we'd have to add a new option) where values can declare that they can be turned into the data structure that record-dc produces in some way (picts and 2htdp/image images would just draw into a record dc and extra the result). That would allow a lot of different kinds of drawing-type thingies and would be easy to support.

Robby

[Greg Hendershott]

I might be misunderstanding and the following isn't some fully-thought-out proposal, but:

IIUC both #%module-begin and read-eval-print-loop use current-print.

What if current-print accepted a new, optional srcloc parameter?

And the default #%module-begin were changed to supply this?

That way, a print handler for a plain-text tool^1 could use the srcloc to create some sort of "link", as well as Racket GUI tools like DrRacket using it to create some fancier UI.

^1: This includes TUI tools like emacs, as well as GUI tools like vscode using a text serialization format like JSON.

[Robby Findler]

That's a nice idea! The code that calls current-print can check to see if the function accepts a specific keyword parameter and, if it does, supply it with a srcloc.

Robby

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/6e1d2180-288d-4789-88fc-2980aaf03650o%40googlegroups.com.