*

{x@1} / :)

w00t one more chat room to kill time in

yessssss

@J.Sallé sorry, i really didn't want to cause chat room proliferation, but i also wanted to continue that extremely interesting (at least for me) conversation about rust's performance, and of course Adam is entitled to clean up the orchard as he sees fit

APL Orchard signal to noise ratio needs to be carefully maintained. whats the big deal with creating a new room? lets party

besides now we can spread rumors about Shakti

@ThomasLackner there's no big deal, anyone can do it

the problem is attracting people in the rooms

many rooms get frozen for inactivity

you could post on r/apljk. didnt do much for my telegram room "Finally Understanding Q (FUQ)" haha

i regret that i have yet to study your interpreters ngn. hopefully i can dig in soon.

@ThomasLackner do you have any you're willing to share publicly?

@ngn nope. i signed up and got an email from F.Q. that the beta would be available soon. that was a few weeks ago. i dont have any inside info but i did consider humbling myself as their intern or something. really eager to get into AW's orbit.

@ThomasLackner the only reason i might recommend somebody study ngn/apl is to learn from the many mistakes i made :) but generally, there's no point

isnt there an ngn/k in the percolator somewhere ;)

@ThomasLackner i keep the source private now, but i'll probably publish (at least) some little pieces from it and do my best to explain them

@ngn i dont o/s most of my experiments these days, so i get you. if you ever wanna chat about implementation i am forever experimenting.

@ngn IMHO, the more the merrier!

@ThomasLackner are you aiming for max performance?

@ngn yes and no. it has to be fast enough to work on an esp32 (for my use case). that means it has to be lean and mean. my first goal is to distill an "essence" of the interpreter that is very simple. i am trying to find an almost Forth-like koanic inner loop, simplifications. in other words, it must be fast, but hopefully by virtue of simplicity

@ThomasLackner you're talking about xxl, right?

@ngn that one was really plagued by performance issues.. i would be using some of the same ideas but a new base. more like pattern matched plus a "tree" that contains all state.. like an apter tree that contains all values. does that make sense?

@ThomasLackner "apter tree"? something to do with the person with that surname?

@ThomasLackner very interesting, i must read all of this

@ThomasLackner so this is how variables and "paths" (eg a.b.c:0, i don't know what the correct term is) would be represented in your new experiments?

in ngn/k i used a hierarchy of dicts because oK, kona, and k4 appear to do that. "a.b.c" compiles to a call to ".`a`b`c", and "a.b.c:0" compiles to a tetradic "." call (not yet on tio). but a flat "apter tree" does look like it would be more efficient

Ahh outstanding

Aaron Hsu also did a great talk on tree representation as vectors; not sure if it's different to the Apter tree route

This one patreon.com/posts/tree-wrangling-23034676