This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
At Sun, 25 Jan 2004 19:27:58 -0800 (PST), Tom Lord wrote: > > So far as I know, the details I've heard about Bear's are such that I > would consider it to conform to the guidance. But it's not. Binary trees are O(log(n)), period. Bear's intended use cases may often involve shallow trees, but that's not to say they always will be, or that other people won't write applications that fragment the tree. You can keep a tree balanced, but you *can't* keep it constantly shallow. An algorithm that assumes O(1) access in such cases will perform poorly. > I'm not aware enough about the details of Shiro's. All I'm (sort of) > aware of is that he's dealing with a EUCJP -- which sounds very > challenging if you want to wind up with an implementation suitable for > intensive string processing. (Unicode is similarly challenging.) Gauche can be compiled with EUCJP, SJIS or UTF-8 (and extended to others with minimal effort). UTF-8 is especially useful these days as the standard for exchange on the net and is being used in more and more C libraries, which is especially relevant in the context of this SRFI. Even without a flat UTF-8 representation, hybrid representations such as trees of UTF-8 chords are very tempting. This is not to say we should encourage UTF-8 either, but I think it is wrong to discourage implementations that use it or binary trees. -- Alex