String Fanaticism

[David Collier-Brown]

In article <77200033 at uiucdcsp> gillies at uiucdcsp.cs.uiuc.edu writes:
| When I worked for Xerox, we had no less than three separate
| implementations (representations) for strings, and PARC had a 4th type
| (Ropes).  We had C-type strings [completely defunct], something called
| XStrings, and also NSStrings.  The latter two string packages supported
| internationalization, multi-byte characters, and length counters.
| 
| I believe that in ten years, when we throw all our mainframes and
| glass TTYs out (except for the compute servers), the XJ311 designers
| will stand with egg on their face.  Their strings will be completely
| defunct on technical (international/WYSWYG) workstations.  These
| machines will probably allow two-byte characters, and for reasons of
| efficiency and functionality, all clients will reimplement C strings.
| The efforts of compiler vendors will go to waste.

  I think I understand why you want to disentangle C from its
current implementation of strings, but I fail to see what (the size
of?) the current suite of library functions has to do with it.
  Could you clarify, before you inadvertently get flamed?

--dave 
ps: since C is **rather** low-level, it may prove inadvisable to
    build a string mechanism which hides its implementation from the
    programmer: instead, we may want to make it easy to build
    different representations for a higher-level language, using C
    for its implementation.  I'm thinking of C++ (or maybe ++C).
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.