« first day    last day (777 days later) » 

12:44 AM
@chrispsn he also posted a challenge about that in the orchard
12:54 AM
Where's the discussion re: Rust gone?
@chrispsn To TNB
1:48 AM
@chrispsn same approach, but aaron brought in the notion of ordering inside the children of an element by having not just a parent vector but a "left vector" - i.e., what is the node directly to the left of a given node's index? so the same thing but better.
that's one of the benefits - this one tree subsumes calling contexts, bound names, the parse tree, information about loaded modules, defined types, etc..

i picture it all being in the same tree, so the same operations can manipulate all of it.

for instance, think of all the tree manipulation that is done by an optimization pass of a compiler/interpreter - all becomes much more simple and uniform
screwed up the reply attribution there but that was for you @ngn
@ngn in xxl i used a set of nested malloc()'d contexts that held information about the program state, bound stuff, etc. the tree would do that instead. it also makes the notion of general lists a lot easier to implement. (i dunno about your experiments, but for me, general lists perform a lot differently in context than vectors do, and that always complicated xxl.)
@ngn so in my mind, to employ the pattern matching, you'd say something like:

```23.5 is "mynumber"; {x*2} is "double"; {x*2.5} is ["double", "`float"]```

which would cause the tree to resolve instances of "double" differently if the left argument is a float or not.

kinda a contrived example but you get my point
9 hours later…
11:22 AM
@ThomasLackner and what would just "double" resolve to? for instance when you give it another name, will it stop working for floats?
5 hours later…
4:48 PM
@ngn if you could remove those bindings, i guess it would revert to calling whatever previous non-typed version of "double" was defined. if not that, an error. (in mathematica symbols that dont resolve in that way are left as-is and you get a half-resolved version of your code back from the interpreter. can be an interesting but confusing experience.)
5:02 PM
@ThomasLackner tbh, i doubt pattern matching would bring any practical performance benefits, but what do i know. do you have a benchmark?
i guess once i get to that stage i'll have to design one. i came across the problems in XXL just casually while working with imported csv files and tables. that kinda stuff has to work reliably so probably a good starting point

i dont think pattern matching itself will be that fast, btw - i just think it will make it much easier to implement optimizations in practice.. still thinking about it!
6 hours later…
10:37 PM
i put in a private bitbucket repo the current ngn/k binary and its tests - my golfs, project euler 100, and various k exprs. no source yet, it would be too shameful. it's not significantly different from what's on tio.run/#k-ngn now, only small fixes and speed-ups. if anybody wants to try it on their own pc (x86_64 linux only), please tell me your bitbucket username.
11:20 PM
i'll take a look if you'd like. im "tlack" there. probably wont have time in the next few days but it will happen
@ThomasLackner you should be able to see it now

« first day    last day (777 days later) »