From: Fred C. <fc...@al...> - 2009-11-28 14:35:04
|
On Nov 28, 2009, at 4:09 AM, Pascal J. Bourguignon wrote: > ... > Search about unicode combining characters for example. > http://en.wikipedia.org/wiki/Combining_character > > A single character may need several unicode code points to be > represented. So already, you cannot use a scalar to represent unicode > characters in general. Then if you want to store the code points in a > vector, that means that the index of the vector doesn't necessarily > match the index in the string, so string indexing may not be O(1). > > Of course, the problem is even more complex when you try to fit the > unicode model into the lisp model of characters and strings. Right - but this has nothing to do with the complexity of characters in lisp. There are a virtually unlimited number of different ways to encode information. >> [...] I just want the things contained within the strings to be >> bytes (values 0-255) and not altered by any processing except the >> specific calls to alter them (no hidden automatic changes please). > > You need to implement your own type to do that, don't use lisp > character and string, they're more sophisticated. As mentionned, you > can still have "strings" in source files compiled to your own type of > strings, with reader macros. That's what I was asking about - where can I read about the sophistication of strings in lisp? ... > > Are you aware that there are several implementation of Common Lisp, > and that clisp is just one implementation of lisp, written in C (hence > the name, c lisp)? I am - but I want one that has all of the features of portability, an outstanding team of people behind it, with a long history, open source, the ability to interface to C if need be, willingness to talk to (email with) people like me, in most standard linux distributions, etc. > The point here is that, on 32-bit platforms, clisp is rather more > limited in memory than most other implementations. Check array-total- > size-limit for example. (On 64-bit platforms, there's enough > addressing space to use all the available RAM). All the RAM will not be enough for many of the things I ultimately need to do. When you work with multi-terabyte disks, and you are trying to do analysis linking things across the entire disk to other such things, you need multiple terabytes of memory - which I obviously need to do with file systems. I just want a way to not have to write everything for file systems, RAM, databases, etc. just to get better performance at smaller sizes. Since everybody presumably will run into these limits on their programs at some point, I was thinking that a virtual RAM that extends to disk storage (and ultimately multiple disks across infrastructure) built into lisp would be easier (for me) that doing it myself... and for everyone who ultimately will have to do it themselves as their problems grow in size. > If you need to go to the limit of your addressing space, then sbcl or > ecl might be better choices than clisp. > > Also, since you seem to have needs for performance, while this is more > difficult to evaluate, it is possible that ecl or sbcl who compile to > native code (ecl going thru gcc), could produce faster code than clisp > (on the other hand, clisp mustn't be discarted a-priori, since it has > now a JIT compiler, and even with a VM, performance can be good for > some things. Right - the JIT compiler is extremely helpful since I don't know in advance what my program may have to do. I also do a substantial number of things with eval by building up expressions as I go. That's one of the reasons I prefer an interpretive language - but I still want the performance of compiled code - which is why clisp fits so well for so many things. FC - This communication is confidential to the parties it is intended to serve - Fred Cohen & Associates tel/fax: 925-454-0171 http://all.net/ 572 Leona Drive Livermore, CA 94550 Join http://tech.groups.yahoo.com/group/FCA-announce/join for our mailing list |