On 10 September 2013 16:52, Bennie Kloosteman <[email protected]> wrote: > My main preference of UTF8 ( or even ASCII and the old encodings ! ) is > since there is no good solution lets get one thats fast and memory efficient > to make a solid case for the language. Blowing 40-50% of heap space on 0x00 > just leaves a bitter taste in my mouth.
All anyone really needs to be O(1) is the generation and the application of offsets, for doing run-length encoding of font faces, or pagination. The number associated with that offset doesn't need to have meaning except in association with the string you took it from. However, it would be useful to say "no longer than x", for truncating strings into fixed-size buffers or truncating user-provided strings for error messages, even if the meaning of x only places a bound on the actual number of characters involved. Of course, I would like the result of such a truncation to be valid Unicode, I don't think I can ask for sensible text in ~O(1). You can certainly do that with utf-8. And we've already discussed this to death on this list, right? > And if you think benchmarks are not > important look at what Linux benchmarks for linux style apps did to > MicroKernels and the not so worthy contenders ( Minix , Herd and Mach) If it was the benchmarks that did it, the benchmarks (along with the reliability benefits) would have been able to win people back. Really, it was about hardware support (which is still *the* problem in esoteric-os space). If benchmarks were really what people cared about, there'd be a lot more C, C++ and common-lisp programmers. Current platform choices declare quite loudly that people don't care quite so much about having super memory-efficient strings. --- Nevertheless, if you want to have strings on top of a utf-8 encoded byte array representation, that is one thing to argue. Alternatively, it is reasonable to ask to be able to describe such things within the language. Where does BitC stand, Shap? Is having such a thing available from the safe subset of the CLI critical to BitC, or are you comfortable with unsafe, with machine-checkable proofs possible? Or is this entirely wishlist? -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
