Hammock thoughts on procedural languages

[Dotrar]

Hey all. I loving what's possible with conjure, it's really great and I think "conversational development" is a great idiom.

I'm curious about the non-lispy interactions and what could be done in the future. I can see that the Lua repl has started to make its way in, and I personally use ipython a lot at work (Django development) so I'm interested to see what could come about in developing the more procedural languages.

I'm wondering what the scope is for the interactions, and thoughts were on how it would work. Due to procedural languages being side-effect-city, do you think there's a change of approch compared to the lispy conjuring?

Given that return values are usually put into variables, one couldn't quite use <leader>e! in procedural languages for instance. Would the users be forced into writing a particular style? Or would we repurpose those mappings for other things?

My workflow

Currently, my ipython workflow is to use a simple plugin called vim-slime that will copy any selected text (vip by default) over to the last tmux pane, which would be running a repl. Largely my approach is to slime over some function definitions, then try to run it by directly typing into the repl. Things like breakpoints are triggered and interacted in the repl, which I can manage with tmux so it's a little less painful, but it's not "integrated"

Then when I hit a snag, I put in some breakpoints and step through the code on the repl side, changing things as I go. I haven't yet tried to find any debugger that integrates with nvim as they don't sound appealing to me on the whole.

So far I'd rate this workflow about 7-8/10. It sort of feels like the same "conversational" development that you're talking about but I use it more for "fixing" and modifying things, rather than creating things, and most of my time is in the repl, not in nvim.

Conjuring Procedural languages idea

Could we have the option of running the repl server in a :term window, meaning the log becomes a little more of a scratch buffer one could use to place definitions and declarations, that can be used with the repl?

Meaning there's effectively 3 windows:

• the code
• the conjure log / "procedural scratch"
• the :term running the repl

Perhaps <leader>e! can become the "copy to log and eval (when in procedural languages)" mapping. <leader>el eval entire log buffer.

Perhaps another vim debugger will satisfy my debugging needs and work alongside this, but it feels closer to my workflow above while not entirely removing things (like the repl prompt / debugger)

Snag with class instances and method definitions

I think another real issue might be with things such as class method re-declarations. Would "eval method declaration" eval the whole class again? There's all sorts of non-lispy problems here.. I think it might be doable, but we'd have to have the flexibility to patch in custom python code before and after certain evaluations in the python client. (Such as "monkey patch new method into all instances of the class" ??)

Similar is the issue with methods. I don't think I've seen ipython handle the case properly where foo() will call bar(), but if you redefine bar(), foo() will still have the reference to the old bar()

Would "keep a track of references to bar() and update them" be above and beyond the scope of conjure? I think maybe, which supremely reduces the effectiveness of this idea.

These are just some of the thoughts I had written down and wondering if you had any insights?

Alternatively, fork the whole lot and call it "Procuring - for procedural languages" 🤣😅

(PS: would love to see a video on how you use the clojure client as it seems more featureful and has a debugger? Might be inspirational to above)

Thanks for the great plugin!