why do people still accept CSP? It is simple to do some things in it, bit please just give me concurrentML with "simple" channels for that kind of work , and proper channels for any kind of hard stuff. I have had to write things in go that took me days to get straight that would have been 20 trivial lines in any concurrentML implementation.

if a ranges are inclusive, you get used to it. if it is arbitrary it is awful.

the hardest part was what came next: the code generation. despite producing c# instead of MSIL. The features I use are: static and dynamic traits, pattern matching, and a concurrentML.

It is actually quite simple when you don't have to do closure conversion yourself.

it is not an either or.

AMA I guess

with CAS, making a multicore cml is not too hard.

a classic example of something that is trivial in cml but requires a mediator in CSP or go is two fibers swapping values atomically where a fiber can pull out at any time. in cml it is about 20 lines of code that can be in a library. it composes with other events.

in csp it is a "server" that manages the swap which means you lose the sectability.

Evert time you want to have any kind of protocol, cml wins.

I had a weird introduction to programming. I spent my first half year doing php, and them went all in on scheme and sml. Which is nice in many ways, but I do have a hard time accepting many of the completely braindead (subjective opinion, of course) choices of most of the popular languages.

I do think clojure is a pretty nice compromise. Rich has good taste, obviously. Clojure's core.async could be less async and more CML in my taste. Wrapping a simpler async api in cml is easy. Implementing CML on top on core.async is either very hard or full of compromises.

i rarely write gui stuff and I find async is rarely what I need. in f# I at least have the option to use hopac.

I sometimes wonder where we would be now if people would have gone "Wow, mr Reppy! concurrentML is so cool!" in 1993.

instead we got pthreads and collective amnesia and later we got go's girly times and channels which are only half way there.

I have already started. Not only is the concat faster (which means the derived operations in the rrb tree will be faster), but the derived operations can be done directly since the relaxation is going to be between 16 and 32 elements. A remove will just be a copy 16 out of 17 times.

This will mean that indexing might be slower in the b tree (it will be higher since the fill ratio is lower) part of the tree, and there might be slightly more of the relaxed nodes, but sweet jeebus this is a simplification.

A simplification that makes correctness easier and speeds up all other operations.setting the minimal amount of elements to 24 will still make concat faster, and will make memory waste almost the same (I can use c# inline arrays without feeling too bad).

I have both a fast b+tree and am Rrb tree. Why didn't I think of this before?!

If you have a relaxed root, you know the size of every subtree. If the the subtree is dense you can easily calculate the shift, meaning you get dense radix tree subnodes with fast lookup.

This gets you the benefits of a relaxed b tree, but no issues with accidentally having too deep shifts since they are relative to where the dense subtree starts.

This could be done to a rrb tree as well, which would mitigate the issues you are seeing, but would still lead to an arbitrarily deep tree if the concatenation isn't done properly.

The only tradeoff would be slower indexing on relaxed trees because more nodes would end up unbalanced, but at the same time concatenations, insertions and removals would probably be faster.

I will try to implement this.

Edit: no, seriously. This is a splendid idea. The b tree concat is faster than the rrb tree "full" merge. And simpler. And storing the tree subtree height in a byte somewhere means we can go from relaxed to dense and then do a proper radix tree search. (I have one of those rrb tree implementations that probably fails, btw. It has a proper concat, but the improper one is so much faster. I know. I am ashamed.)

https://rikspucko.koketteriet.se/bjoli/PersistentMap/src/bra...