OP here.

This IDE started as a final project in Gerry Sussman's LISP class at MIT.

When programming and debugging, you often want to know what your code is going to do without the possibility of unintended side effects (state change) by actually running the code.

Towards this goal, we added a concept we call "preview execution." That is: you can preview the output of code in our IDE simply by highlighting a section of code. The IDE will show the output of the highlighted section, but when you de-select the section, there are no side effects: no state is changed in the Scheme instance.

It's downloadable as a Mac app, but also open source. Would love to hear people's thoughts on it!

What about side-effects that cannot easily be contained, e.g. HTTP requests sent from your code, DB writes?

I don't think the goal can be achieved pragmatically for many types of modern applications generally. Maybe offering some sort of debug snapshotting and mocking layer for things like that and libraries to implement might be an idea. The debugger should then also be able to identify for which parts preview execution can be done and for which ones it's not possible to contain side-effects.

> but when you de-select the section, there are no side effects: no state is changed in the Scheme instance.

So if your code deletes itself on disk - that code path will run in a sandbox, and roll back? Or are you talking only of state contained/managed by scheme (eg not the os) like global data structures etc?

Ah, from tfa:

> How Preview Execution Works

> Under the hood, preview execution works by using Scheme environments.

> When code is highlighted, Toski duplicates the current environment and executes the code. Then, when the cursor is moved or the code is de-selected, Toski removes the new environment, returning the instance to the previous state.

Which makes sense - but it would be cool if it automagically mocked all external calls... ;)

or, just showed you a call graph, with symbolic values - e.g., instead of printing 'hello world', it would show a box, highlighting the argument to the 'display' function , and showed how that argument value is propagated through the rest of the code. If i clicked on the highlighted argument, and started typing, i should be able to see how my changes affect the flow and what the output might be.

Chrome's JavaScript console does this too. Type in e.g. an array transform code and the output should appear below in faded text without you having to click enter.

Ever thought about merging it with property based testing (ala quickcheck) ?

You might find the work Chris Granger did on Light Table quite interesting ( https://www.youtube.com/watch?v=H58-n7uldoU )

I really liked the first version and did some research some time ago on how to make this usable by a wider audience: https://ferrucc.io/posts/a-new-ide/

This one shows function calls and linked lists in case you find it interesting: http://davidpilo.com/pvts/

It says "Can't find scheme, contact the developer". I figure I'd contact you here so that others can see the answer too.

I have MIT scheme installed on the system. How do I tell it where to find Scheme?

Or better yet, any chance you can just package up the interpreter with the IDE, or make that an optional download?

Not sure if there's anything wrong with the page or not, but when I visited it locked up my machine and used a lot of RAM until Firefox killed the tab.

my guess is it uses css skew (a rarely used css function). update your firefox

The previewing execution is cool, reminds me of my Python debugger https://marketplace.visualstudio.com/items?itemName=fraser.l...

Preview execution is pretty cool. Looks similar to the instarepl from nightcode: https://sekao.net/nightcode/

Isn't such a thing already possible in emacs?

In Emacs you have to actively evaluate expressions (i.e., C-x C-e). This IDE apparently will evaluate highlighted expressions without interaction on the user's part. That said, you could easily write an elisp routine to do the same (evaluate region when point and mark set).

Yeah this is fairly trivial to replicate. Plus if you’re using Clojure there aren’t many side effects anyway so the effect of rolling back is largely the same.