On Tue, Aug 19, 2014 at 10:20:56AM +0200, Felix Winkelmann wrote: > I understand your concerns, but doing all the planned changes piece by > piece will be a massive maintenance effort and the compatibility hacks > required to have something halfway working during the transition will > be even more. I also hate forcing users into upgrading - I always > detested this in other software and would like to spare those that > need a working system, for whatever reason.
To avoid doing this again soon, I think the other change you suggested should definitely be included: the reworking of internal libraries by splitting them up. Perhaps you already assumed this would be included, I don't think I have seen this mentioned yet so I wanted to put it out there. > I also don't see a reason _not_ to consider adding the features you > talk about, but it shouldn't be the main driving force. If we can > provide support for this, fine! But someone has to implement it (of > course) > > So I think: let's just see how well we get along. We should definitely > look into what would be required for bignum/unicode support, if > someone is willing to evaluate this. No problem @ bignums. I don't know much about unicode, so that should probably be looked at by someone else. A simple thing we could include would be to reject all strings that have invalid UTF-8 encoding, like Postgres does that. I always really appreciated this feature of Postgres: it ensures that you don't get invalid data in your system, and prevents pollution and getting in "character set hell", like happens all the time in MySQL: https://www.bluebox.net/insight/blog-article/getting-out-of-mysql-character-set-hell Adding rejection of non-UTF-8 strings would make the transition to a "full" Unicode system less painful (and perhaps make it possible to do it in a non-breaking way). I'm not sure how difficult this would be, though: all string mutation procedures should have a check that they won't create invalid strings by setting characters (bytes). Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers