and don't solve the spacing issue, also: I see an →, so I type one in my search box, but can't find anything since it's not an arrow, but a fake replacement of ->
Or I press Shift+Right to select it, but can't, need to repeat it 3 times because again, it was a long arrow, not a single symbol. Then, of course, they could do a replacement in y our comments where you meant literal symbols, not an arrow...
You make it sound like reducing the big O complexity is a dumb thing to do in research, but this is really the only way to make lasting progress in computer science. Computer architectures become obsolete as hardware changes, but any theoretical advances in the problem space will remain true forever.
No, my point was the opposite, I agree with you. But the commercial focus on throwing hardware at the problem seems to have gotten entirely out of hand.
I have had treesitter crashes in the past editing markdown, causing helix to segfault, but the particular bug that caused my crashes has been fixed since years.
Although I'm more of a functional programmer and ADT addict, I still find this language appealing. Reading the manual, it feels like a lot of correct design decision have been made, contrary to languages like C++. Most notably for me: 1) Memory allocation and reference is restricted, leading to less problems with memory management. 2) Syntax is more flexible, allowing for higher levels of abstraction.
But entirely definable in user code, so an effect is essentially a set of possibly impure operations you can perform (like I/O or exception throwing), and a function that exhibits that effect has access to those operations. Of course the call sites then also exhibit that effect, unless they provide implementations of the effect operations.
TCO (tail call optimization) is often confused with TCE (tail call elimination), the latter is a runtime guarantee whereas the former is a compiler's best effort attempt to statically optimize tail calls.
Thanks! So you are implying that `TCO :: Maybe TCE`?
I am trying to think of a situation where a functional language compiler does not have enough information at compile time, especially when effects are witnessed by types.
I'm not a compiler dev, but I know that many functional programming languages struggle with this in the same manner if the target platform does not support TCE itself, and therefore require trampolining.
I like that there is plenty of room for comments, and the multiline extension is also cool. The backslash almost looks like what I would write on paper if I wanted to sneak something into the previous line :)
