Harald Hanche-Olsen <[EMAIL PROTECTED]> writes: > + Raymond Toy <[EMAIL PROTECTED]>: > > | There was a unicode version of cmucl done several years ago, but > | unfortunately it's rotted quite a bit. I have tried a little to > | bring it up-to-date, but since I'm illiterate, unicode doesn't help > | me. > > Rather than reviving that, wouldn't it make more sense to port the > (fairly recent) unicode support from sbcl? I believe that work was > done by Christophe Rhodes, who is also on this list. He may be able > to comment on the feasibility of such a port. Searching for the > string "sb-unicode" in the sbcl sources should give an idea where > changes will be necessary. I count 38 files in the sbcl distribution > containing this string, so it's probably not done in an afternoon.
Er, hi. <waves nervously>. It's not done in an afternoon, no, and ironically it would be mildly non-trivial because cmucl doesn't support (vector nil) as strings. I believe it took of the order of 40 distinct cvs revisions to take a non-Unicode sbcl to one which had support for #x110000 characters and latin-1 and utf-8 external formats, and to that you'd need to add the time to implement more than one representation for strings. Additionally, more external formats have been added since that branch was merged, and development is ongoing. In traditional CMUCL time-units, I suspect it takes of the order of one Wizard-month (or two Christophe-months) to do such a port. Non-Wizards have to learn about bootstrapping cross-compiles reliably and gdb debugging, because it's highly probable that things will go wrong. (Portions of this development came from Eric Marsden, Teemu Kalvas and Robert J. Macomber, and probably others I've forgotten.) Cheers, Christophe (Just to raise the question: people wondering about porting SBCL's Unicode to CMUCL might be advised to perform the inverse calculation, of what CMUCL features are needed in SBCL to switch in that direction.)
