i am going over Parser Combinators, K-style from

nsl.com/k/kparse/pcomb.k

choose: {[a;s] fail{:[err x;y s;x]}/a}

@dzaima You can use vim slime with tmux to achieve this effect

Install vim slime using vundle, or your favorite package manager for vim, or manually

open tmux, and then split the panes into 2

in one of the panes open k repl, in the other open your vim editor with vim slime installed

now over any k text in your vim editor, press Ctrl-C Ctrl-C, it will prompt you for what screen you want to use, say tmux, then press .1 (as .1 is your repl pane), the text will be sent to your repl pane through tmux

Although, @ngn still for whatever reason your K vim plugin conflicts with my tmux hotkeys :C

@dzaima I use entr with a bit of vimscript that saves the buffer on any change, with two terminals side by side

there are potentially infinite ways to achieve that workflow (but i don't use vim so neither of those applies to me ¯\_(ツ)_/¯)

@dzaima what do you use?

i use neovim

although i cant seem to run tmux on MSYS2

@PyGamer0 sublime text mostly; but i'm working on a custom text editor that's somewhat near a usable state

@dzaima it is open source?

my thing? not yet

:(

(ping me when it is, i want to see it)

@meyt4r iirc, k3 was the last version of k that had any (even if partial) support for closures. ngn/k, being an imitation of k6, doesn't have them. i think closures are an elegant and natural concept but i don't see a way to implement them without also introducing major problems complexity, speed, and compatibility.

@meyt4r when i need access to a variable from the outer scope, i usually either do like you did - introduce a global, or add an extra parameter to the inner function and curry the value there - something like choose:{[a;s] fail{[s;x;y] :[err x;y s;x]}[s]/a}. the latter works only for read-only closures.

also, surprisingly often there's a way to rewrite the code so it doesn't require closures at all

@dzaima entr doesn't require vim

entr executes and arbitrary command on various triggers

the usage he's referring to is something like find . | entr /path/to/k ./my.k

this will watch all input files from find . as triggers, whereupon a change takes place, the command to the right will be executed again

@nathanrogers doesn't seem to be possible to make that work with a REPL after running the file

No, but you just edit the file and the thing runs again

right but my original message said starting a REPL after executing the file

No, you can't persist a load of state, but its great for fast iteration on smaller data

I'm not ignoring your message

but providing alternatives and possible work arounds

No need to be a pedant

i mean my workaround would be to write a custom thing that does precisely what i want

It takes like 5 minutes to learn to use vim at a rudimentary level, and notice... that DOES include the REPL into the workflow

but you dismissed that approach, which seems to be the only adequate suggestion

@dzaima Then go right ahead

@nathanrogers I don't see how entr allows a REPL

I didn't fucking say that did I?

I said vim slime did

didn't I

that's just executing the file. I want both a persistent file and a non-persistent REPL to explore in after executing the file

but - again - as I said before - but then I repeat myself - since you rejected the approach that uses the repl, I recommended entr

doesn't have anything to do with entr does it?

ah right that's about vim slime

so entr is a less wasteful watch, and vim slime is a shortcut for copy & paste