Comment by pflanze | Hacker News Reader

Comment by pflanze | Hacker News Reader

Parent Full thread

I'm writing a Scheme interpreter in C++ with the express purpose of easily using Qt from it. It supports call/cc efficiently, which I hope will allow me to write Scheme programs handling GUI ops which use signals/slots behind the scenes in direct mode (basically have (potentially many) Scheme threads of execution instead of callbacks). Another thing that I'm vaguely interested in experimenting with is offering a "reactive"/functional/immediate mode layer on top of Qt with it, but I don't have enough experience yet to know how possible that will be.

The interpreter currently relies on refcounting for simplicity and to provide deterministic latency behaviour. It's (currently) a simple s-expression interpreter partially because (at least at first) I want to use it to interoperate with another Scheme system via sending s-expressions forth and back, and then that's the lowest latency option. I've got various ideas in the areas of debugging and typing that I'll try to implement, and if I succeed on that path and start wanting to use it as the main Scheme system then I'll certainly move on to compiling to byte code or use a JIT.

I just started a month ago, and have to nail down licensing with my employer, when that's settled I'll publish the code.

That's a very interesting project. Still, if you're aiming at real-world usage, please seriously consider postponing your own language+implementation (or keep it as a side project) and writing a library for Chez Scheme instead. That would be awesome.

Chez is very mature and probably the fastest Scheme available. It's so good that the Racket team is currently converting Racket to Chez as the backend language and compiler.

I know about Chez and Racket's effort. The reason I'm rolling my own is that as mentioned I've got ideas to help debugging and typing that I find easier to implement when knowing the system and the system is simple. And that I want to control GC pauses, and get easy interop with C++ (e.g. I can use Qt strings as Scheme strings that way). I also don't want to be tied into a particular Scheme implementation (e.g. some of the GUI apps that I write I will want to run client side in the browser, too). I would be happy to meet with any Chez users/implementors though to learn about its internals etc. I'm looking for Scheme and CL people to meet in London, BTW (https://www.meetup.com/London-Metaprogrammers/ - first meetup soon).

PS. consider it to be a Scheme really optimised for doing work with Qt. It appears that binding Qt well into another language is difficult (Python being about the only one where that was done successfully?), so I'm taking the approach of working "close to the metal" (C++), do things that are better done in C++ (like subclassing widgets) there, then making interfaces to scm as I go (i.e. make it so easy to make interfaces that this is a reasonable approach to do). That way I don't have to do all the work of binding the entirety of Qt, I can use qtcreator as I see fit, I can decide on a usage basis how to interface to a widget (modal in the Scheme view but not modal in Qt's view?, when does it need destruction in that case?). I guess the knowledge or abstractions coming out from this might be portable to other implementations, though.

Also again, I also do have code in another implementation (Gambit) that will have to stay there for the time being; communicating with the GUI via sexprs will of course be an indirection, but given that web programming could work the same way (the Scheme implementation on the server communicating with the one in the browser) it looks like the right approach to try for me. That will also mean that the approach will work with any Scheme implementation as the server (Chez, Chicken, whatever).

Reply on news.ycombinator.com