Open johannes-climacus opened 7 years ago
This sounds like a great idea to me, though I'm not at all familiar with the Dr. Racket architecture, so I can't really give any suggestions there.
Right now, the Swift application has to communicate with separate Scheme processes to send them work and receive results. It would be great if we could eliminate the need for this, which should greatly reduce the complexity of adding new interaction features (such as navigating multiple answers, rather than just seeing Barliman's first guess).
I know that Barliman works with Chez scheme at present. Do you (@gregr) think I'll need to port it to (or otherwise modify for) Racket? Still researching this, but pretty sure from my own naivety that no changes are required. Thoughts?
I don't think we've tested on Racket recently, so compatibility may have broken slightly with the changes we've made in our miniKanren implementation. Also, the Swift portion expects Scheme to live at /usr/local/bin/scheme
and passes it Chez-specific command-line arguments, so this will need updating.
Other than that, I think things should work, though performance may suffer. Let me know if you run into trouble.
After discussing a bit with @webyrd and following the discussion in Issue #17, I've been looking into extending Dr. Racket with a Barliman plugin. To do this successfully would have several benefits:
I've never written a Dr. Racket plugin, so I suppose this is a good excuse to learn how. Thoughts and suggestions appreciated.