Re: [Chicken-hackers] CR #1142 and upcoming changes

[Peter Bex]

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