hckrnws

Actual paper: [1]

This could be useful. I've been plugging away, on and off, on the concept of statically checked back-references for Rust. This is one of the biggest complaints that C/C++ people have about Rust - if A points to B, it's really hard to have a pointer from B to A. This leads to unsafe workarounds.

You can do it safely with Rc, RefCell, Weak, borrow(), borrow_mut(), upgrade(), and downgrade(). It's verbose, adds run-time overhead, and there's the potential of panicking at run time on a double borrow. But the expressive power is there. This is work in progress, and I have some notes here.[2]

The thing that's hard to check statically that borrows are disjoint as to scope. Borrows have lifetime scopes. If those lifetime scopes do not overlap, the borrows do not clash. Checking this across function calls is hard. (Checking across generic function calls is worse.) The Flowistry approach might help. The note that "Flowistry does not completely handle interior mutability" is a concern, because we're analyzing things that use RefCell.

The practical problem is to come up with a set of restrictions that are 1) sound, 2) checkable at compile time without too much compute effort, 3) allow programmers to do most of the legit things people want to do with back pointers, such as have a reference to the parent node in a tree, and 4) lead to usable diagnostic messages for problems.

[1] https://arxiv.org/abs/2111.13662

[2] https://github.com/John-Nagle/technotes/blob/main/docs/rust/...

Does this exist for larger/more informal dependency relationships within a function body in other programming languages?

For instance, if I highlight a parameter or variable foo, can I see not only all usages of foo itself, but usages of any variable that was derived from foo?

While borrow usage makes this foolproof, this type of visualization would be tremendously useful for even other types of code.

(As for Flowistry, I can see this being vital for anyone trying to maintain e.g. https://github.com/servo/servo/blob/main/components/layout/f... - perhaps the most daunting single file in a modern codebase I've ever seen! And yes, that's a 400-line function.)

This is called program slicing in general

looks fantastic, and rust is probably a great language for this since ownership restricts effects - even if you add it to python, you can't really trust it, because at runtime you can just run up a call stack and modify memory at any time. (though I would still definitely want it, as it's usually going to be correct)

(Author here) That's exactly why I built this for Rust, and why it's difficult to replicate in any other language.

Hey author, interested about your bio and work.

Any way to follow what you up to?

My personal site (https://willcrichton.net/), lab site (https://cel.cs.brown.edu/), and Mastodon page (https://mastodon.social/@tonofcrates) are all good ways to follow me!

The author has a nice talk diving deep into the routines research and the plugin in a Rust East Coast talk here: https://youtu.be/aYmuMlzvjvc

Why not contribute to rust-analyzer's documentHighlight LSP method? It behaves very similar to what GIFs are showing.

Seems like a very specific feature to have plugin for.

https://microsoft.github.io/language-server-protocol/specifi...

Explained in README: https://github.com/willcrichton/flowistry#why-isnt-flowistry...

Looks cool, but why say 'IDE' instead of just VSCode plugin?

Probably because "Visual Studio Code" is a Microsoft trademark, but the plugin works with all the IDEs based on the open source base (VSCodium, Cursor, etc.)

It says IDE plug-in

Yes, that's the question. It doesn't appear to support any IDEs except VSCode so why use the general term and give an incorrect impression?

Probably because it's based on an idea published in a paper, it's not limited to this particular repo

Just the other day I was experimenting with moving over a big chunk of a C# codebase (heavy on allocations) to Rust, and the Rust code quickly became very cluttered. C# reads better but is a bit more verbose. Rust is more compact and sometimes very dense.

To make it easier to scan through long files, I wished for an extension that could make the traits appear a few shades darker. This might be even better. Going to give it a try tonight.

I’ve always dreamed about this + also how the data flows from the outside (who calls this function)

Couldnt we re-use data from the compiler to help with that ?

as far as I understood from the corresponding talk, it uses data from the compiler

These kinds of tools should be standard in understanding code

this looks fantastic

would love this for typescript

Anyone have suggestions for similar tooling for other languages?

JetBrains IDEs :)

Super cool! I assume it plays nice with rust-analyzer?

This is an interesting way to do micro context engineering. This is basically pulling in the minimum relevant code for your current concern, and then you can just sprinkle on some instructions and send off your prompt. Might work reasonably well for very small local models, or just generally cheap inferencing on the server.

I love this plugin btw.

Nice plugin, will try this out tomorrow!

[flagged]