Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: No. In that case I want unsigned integers to be the "primitive type" and would I want normal integers to be an lrecord. Buffer positions could then still be represented by that new "unsigned integer type". With an lrecord lisp type you could have 32-bit integers. I am not even sure I want the lisp code to see the distinction. Maybe (probably?) such a thing will be extremely ugly to implement, I don't know. Maybe an even better idea would be to this for characters. lrecord integers. Of course you could also argue for lrecord chars, presumably the actual value of chars will not be used that often, presumably less then integers. Did anybody ever do profiling on this? Maybe putting characters in lrecords for Mule is the way to go. Maybe even with the ugly small-character/big-character thing I reposed for unsigned/signed integers above. I think it is less of a crime if the internal representation of stuff changes depending on the Mule switch without changing any lisp visual limits. Ok we do better as I thought then. I thought some operations on mule buffers become O(n^2)? Or am I confusing things here. I am not a fan limiting the integer range and I hope some other solution can be found but if really makes implementing that much easier I won't loose any sleep over it. Jan