Jan Wirth (Jul 06 2022 at 18:13): Jan Wirth (Jul 06 2022 at 18:13):Is there any previous work on interpretability? "Interpretability is the degree to which a human can understand the cause of a decision." I borrowing this term from machine learning because I don't know better.
Concrete problem: I am looking at a user interface based on HTML which is generated by a server during runtime, based on state of the database and the user's session. It would be an absolute game-changer to explain why a specific element has come to existence - which line of code was building the tags, which row in the database is the data coming from?
The closest thing to what I mean are source maps, but source maps usually map onto the source of a compiled code. Why is only AI privileged to have their (black) boxes explained? Why not explain the output of all our boxes?
Zeljko Nesic (Jul 07 2022 at 10:21):Have you seen any good AI system which would give you that level of interpretability out of box?
Jan Wirth (Jul 10 2022 at 21:55):No, but I don't have a terrible amount of knowledge in the field. Source maps are the closest thing to what I mean.
Zeljko Nesic (Jul 11 2022 at 01:42):You mean mapping from Roc to assembly code, ala godbolt.org?
Brendan Hansknecht (Jul 11 2022 at 02:45):The closet thing to general interpretability that I have seen in code is definitely time travelling debuggers. Since they allow you to see an outcome and work backwards until you find the cause.
Brendan Hansknecht (Jul 11 2022 at 02:46):I think that theoretically Roc/the editor/platforms could be combined in a way to support this well, but it will be a pretty large ordeal.
Brendan Hansknecht (Jul 11 2022 at 02:46):Otherwise, llvm debug info and source maps could be created for roc.
Brendan Hansknecht (Jul 11 2022 at 02:48):They may not be useful though. Roc does not necessarily map well to the end executed code. We have so many lambdas inlined and a lot of work around uniqueness checking. Unlike more imperative code, roc may be much further from the output assembly. As such a source map may really just map 1 large block of assembly instructions to a large block of lambdas. Or it may not map well at all.
Anton (Jul 11 2022 at 09:46):Would the dev backend allow for a better mapping?
Zeljko Nesic (Jul 11 2022 at 11:46):@Brendan Hansknecht But in theory, could we somehow make a translation and make looks-like-a-stepwise-debugger or the translation goes only one way?
I mean, maybe we build Roc separately for stepwise-debugging?
Brendan Hansknecht (Jul 11 2022 at 15:38):Yes the dev backend/llvm without optimizations should be better (we still do a few transformations, but they should map much better). Depending on the program that may or may not be ok. In some cases it may be quite slow. But I bet in a lot of cases it will work just fine.
@Zeljko Nesic As for the translation question, I am not sure what you mean. Can you explain a bit more?
Zeljko Nesic (Jul 11 2022 at 15:54):@Brendan Hansknecht So imagine one aspect of the editor, that takes your Roc code, takes input, and produces how data flowed trough your code base. To do that, we will need to capture somehow how data goes trough Roc program.
Could we somehow capture that data?
Brendan Hansknecht (Jul 11 2022 at 16:03):That should definitely be possible. In the worst case, we essentially chunk the program by adding a special editor effect between each line of the program. The effect would pass information of what changed backed to the editor.
Depending on needed granularity, a simpler solution would be to look at the single function call level. Since roc in many cases will regularly communicate with the host. It should be possible to record data in from the host and data out from roc. This of course gives a much more limited view, but it could still be extremely useful if each call into roc is a logical step. It may be possible to figure out which step went wrong. Then you could unit tests the roc function with the bad input and fix the bug.
Other options that I can think of off the top of my head: profiler/debugger hooks, running roc code in an interpretter
So there are at least a few options that should make this possible at different granularities.
Tobias Steckenborn (Jul 11 2022 at 16:57):Maybe there's something to learn from Wallabys docs / blog / GitHub. As far as I understand it they are using hooks provided by the test framework. Yet I’m not sure what JavaScript offers the test runners.
// Edit: Probably nothing sophisticated publicly available https://wallabyjs.com/docs/intro/how-it-works.html
Last updated: Jun 16 2026 at 16:19 UTC