Use in computer games

[talas]

Hi, thanks for creating this!

I have decided to use a small fork of ktye/k in a computer game project.
My fork is here: https://gitlab.com/talas777/spesh

I only plan to use the C-version and I used the LGPLv3+ license (my favorite).

Please let me know if there is some way I can credit you or give attribution.
Perhaps a link to your project?
I added "Copyright (c) 2022,2023 ktye", hope that wasn't too wrong?

Thanks again!

[ktye]

cool. it looks you really worked through the code!
if anything is unclear, just ask. i'm happy to help.

the attribution is fine.

please tell me when you have a game ready which uses k.

[ktye]

i made some simplifications for smaller code size recently. e.g. i removed digraph adverbs, over/scan with initial value, and each-prior. your refcard reflects the old behaviour.
If you prefer this you can browse:
07aa8ec
Also in sort.go (in that commit) i removed specialized sorting routines that may be faster and left only merge sort.

Longer ago i also had simd versions (simd128 in wasm) and portable vector instructions in c.
If you care for more speed you can see those here: https://github.com/ktye/i/tree/77a566f

[talas]

Interesting, I did notice something had changed w.r.t adverbs. I guess this is to implement k7/k9 syntax?

FYI I posted a job on freelancer to see if someone is willing to rewrite the parser/interpreter so that it doesn't recursively call exec. This would allow stepping through the byte code, which would be quite useful in my projects.
It would be much slower of course, so I doubt you would care for it..
I haven't gotten anyone to accept the job yet, perhaps my budget ($350) is too low, or my description is too bad.. https://www.freelancer.com/projects/c-programming/interpreter-programming-project
I'll let you know if I get someone to work on that.

[ktye]

k7/k9 syntax
that's a recent change in k9 but no version has been made public. arthur also mentioned to use f'x as each prior if f is monadic or for special basic verbs, but i have not implemented this.

the current version uses a very small stack at a fixed address. it can be extended, e.g. by using a normal k list that may grow. that would require a further indirection as the address may change.

i think the small k stack is mostly limiting recursive calls, long before the c stack is exceeded.
i just don't write in recursive style in k but try to find an array solution instead. e.g. my initial try for the compilers in x/ recursively generate code for each node which hit the stack limit very fast. i change that to work bottom up which made it also faster.

[ktye]

i thought about it for a while and wrote down how i would rewrite it: steps.md
maybe i implement it one day as an experiment but i cannot promise right now.
i would keep it if it shrinks code size and does not slow things down too much.

if you or someone finds a better way it would be interesting to see.

[talas]

Thanks for the write up. Not sure if code size would shrink, but code complexity might be decreased somewhat. I'm sure some cases could be faster, but anything involving each or reduce with a lambda would certainly be slowed down. At least I don't think it would be easy to optimize that kind of construct.

[ktye]

the question is how important vm speed is for a language like k.
some time ago i wrote a compiler that translates the byte code to native code:
https://github.com/ktye/i/tree/e0d043cc7db0c97e9f842afcec5dd44f4bcde9c6/kom
in the benchmarks you can see the interpreter overhead.
in the worst case (pure scalar code) the speed is 0.5 x native.
for qr decomposition there is no difference, despite the complicated looking k code.

my guess is that some slowdown in the vm will not be noticed.

[ktye]

i abandoned the stepping interpreter described in steps.md and found a simpler way for tail calls: bfb9a6e50

we can keep the current exec function mostly, including keeping the stack top in a local variable (accumulator).

todo is the monadic case :f x
and maybe to increase the stack in general.

i also store symbols and shadowed variables for lambda calls in a complex vector, which is flat so we don't need to do refcounting.
since you removed Z, you can use a F with 2n or I with 4n and adapt the loops.

[talas]

I used to treat (guile-) Scheme as my go-to calculator / prototyping language, so tail call optimizations sounds great. About the stepping, I have someone looking into it but no clue if they are getting anywhere. Worst case it's a feature that can live on my TODO list for a few years.

[ktye]

it should work now for both monadic and n-ary application of lambda functions.

odd:{$[~x;0;:even x-1]}
even:{$[~x;1;:odd x-1]}
odd 1001   /1

also in the general sense not just tail-recursion but any function with different number of arguments can be called.

i'd like to see some examples, e.g. for algorithms that can be nicely expressed with tail calls but are more cumbersome in k without.