Can we talk about REPL interaction?

#1

There’s a lot of chatter about live-coding systems, but not much regarding the middleware we use to send code to them. For some systems, there are already nice REPL-plugins available, but I’ve noticed that many live-coding libraries/language/frameworks/systems have their own plugins, or sometimes even their own specialized editors.

In most “traditional” programming scenarios, you can use whatever editor you want. Just compile and run your program, or execute the entire file. But live-coding often necessitates the ability to execute segments of code in isolation, which requires specialized tools that are often bound to particular editors and platforms.

The need for these tools gives rise to a bunch of (I think) interesting questions:

  • How do you send code to your language/interpreter?
  • Does this require a plugin?
  • Is this a generic plugin for the language, or specific to your live-coding system?
  • How do you go about making a plugin/editor targeted at live-coding?
  • What medium do you use to communicate between live-coding system and editor? (network? pipes? files?)
  • What editors do you support? How do you choose?
  • Have other people made plugins for your live-coding system?
  • What features are unique to your editor/plugin? What features does it have specific to your live-coding system?
  • Is your editor or plugin inextricably tied to the system? Is it the system itself? (Orca comes to mind)

I’ve been thinking about this specifically because I cannibalized an existing Lua REPL plugin for Emacs while building Cybin, but I’m beginning to yearn for something more specialized, robust, and modern. There are, as far as I can tell, no resources out there to guide someone if they want to create a live-coding-centric REPL plugin or editor. I think it would be valuable to hear from folks who have done this.

0 Likes

#2

personally I’m a big fan of building languages, so my preference for the live-coding things I’ve built has mostly been to eschew a REPL. Either by having an interpreter that accepts code via some other transport (Improviz gets sent code via HTTP requests) or by having it built into the editor (Atomiix runs in Atom, with the interpreter just being javascript so running within the Atom plugin).

In the case of Improviz, editors need a plugin, but the hope was that it’s pretty simple to create one. I guess it’s specific to that system as it needs to send to specific URLs, but in theory it could be fairly generic.

I guess that thinking about Atomiix in terms of your questions, the editor is the language system itself (It’s still throwing OSC to supercollider, but then what isn’t heh)
In theory the parser/interpreter is a standalone JS library, so could pretty easily be built into VSCode, a web app or a standalone Node server that accepts HTTP, but for the time being at least it’s intrinsicly linked to the editor.
The plus is that it’s pretty easy to install. The minus is that if you don’t like Atom then you’re out of luck.

It’s worth pointing out though, that as much fun as it is building languages from the ground up, and having more control over how interpreters accept code to run, it’s a significantly larger amount of work, and probably not worth it if you’re more interested in actually making music than building parsers/interpreters :smiley:

re-reading this I’m not sure how much I’ve actually answered your questions heh, but it’s certainly something I want to think/talk more about. I’m wondering if, as live-coders, it’s worth us contributing more to the languages we use so that we can get better support for the slightly odd ways we want to interact with these language runtimes?

0 Likes

#3

This is an interesting topic for me, and tangentially relates to parts of a blog post I’m thinking of extending for an ICLC paper - something about the benefits of transactional code changes, or No Right of REPL. :smile:

PraxisLIVE obviously fits in your definition of “own specialized editors”, but the underlying PraxisCORE actor system really doesn’t require it - PraxisLIVE is just a graphical and code representation of that system. Every actor in that system accepts (and can respond with) its own code as a String. So how you deliver the code to that actor is up to you - you can have a node that listens on a file, or map the code property to OSC, use the command line, or whatever - you can even have meta-programming nodes that can do templating, etc. There are no simple answers to your questions, at least from an editor perspective.

Secondly, Java has very limited support for hotswapping out existing code. I looked at it initially, but swiftly realised that not using it was an asset not a liability. Despite the IDE editor flashing select lines when you update (actually those that have changed) the entire code is replaced. The system and API is carefully built to make a transactional change between one code state and the next - creating, copying over, resetting and/or disposing of resources as required. This simplifies external editing, because there is no need to execute segments in isolation. It also ensures that the code at any time is a complete picture - you can serialize down and restart the actor graph later and ensure you’re back where you were, without requiring a complete replay of REPL history.

As far as I know there’s a few system that do whole code replacement for similar underlying technical reasons - CLive comes to mind.

0 Likes