It's not about reversing, but about checking whether reverse iteration works. This is required to perform proper truncation (for limited length fields) as well as visual editing for a cursor to go through the text.
It can additionally be an indication as to whether regular expression matching works, though that is usually handled by a library, and not the core string types.
My contention was always that if a "string" does not reverse text, then it's no better than an "array<char>". The existence of a "string" type implies it should do more.
I chose LLVM from the start since I knew some of the challenges that interested me couldn't be done at the C level -- or rather it'd be more complicated at that level than at the LLVM level.
When I started Leaf it was to scratch an itch. It was really only when the motivation dropped that I tried to find ways to use it, to renew my interest in pursuing it.
Perhaps that did not come across in the article well. When I set out to do Leaf that was the goal of the work. It's wasn't a diversion to some other goals. Over time my priorities changed, and I was trying to force myself to follow Leaf to follow them.
Had I wanted to make a game from the start I would most certainly not have made a language first! That would be crazy. And that's my comments about sunk costs -- just because I have Leaf, it'd still be crazy to do this other projects in it.
Okay, they are classified but I don't see that anything in the setup, or pip package management, seem to actually use them. Are they somehow used in actual package management, or just search qualifiers?
That is not an actual migration guide. It's merely a meta-doc saying what types of things you need to pay attention to. I was looking for a specific list of things that would have to be migrated. The docs mention of reading the release notes for each versino of Python 3 isn't very helpful.
The `iter` form of the `readline` doesn't load the entire stream first, whereas the second form you posted does. This makes a significant difference when reading data from another program.
I saw that migration guide, but it has very few details about what is actually involved in migration. It doesn't include API change details.
The simple syntax changes I did prior to running 2to3 as they came up on the first run I tried. The semantic changes that didn't come up in 2to3 is what I was more bothered about.
#1 has a big influence on my argument. I think it was Python and NodeJS library systems that made it super simple for people to publish libraries. There are a lot of trivial libraries out there, and many of questionable quality. Sometimes using a library ends up as more work than writing the bits of code myself.
It's not like I'm going to decide to write a new 20k line library for my project, but if something is only a few hundred lines of code it's definitely easier to just rewrite.
Those are some of the points I'm considering as well when doing the memory management for Leaf. My desire to have predictable destructors is tough to reconcile in a tracing GC.
I'm uncertain of what you mean with "copying the data over" in reference to large data. Surely it's still just the pointer being copied? Or are you speaking of things like `std::vector` in C++ that are value-copied by default?
In my quest for a memory management scheme on Leaf it's your final point which is primarily forcing my decision: the compatibility with other memory managers. In this article I just wish to provide counterpoint to those people trying to convince me that tracing GC is a better approach. In the end, it's the need to right libraries and be compatible that prevents me from using a complex GC.
There's no value in a String type if it doesn't behave for text. One can simply use a "Array<char>" to convey proper semantic meaning.