@mflatt Out of curiosity, have you experimented at all with using records to implement racket’s cons cells? I’m curious how much it would affect performance, esp. with the faster list? check. If it’s not much slower, I wonder if something like using unrolled lists could make up the difference for common cases.

I haven’t tried that. I’d be sad to lose the two-word representation of pairs on Chez Scheme, but I’m not sure how much that matters

How does the layout of records differ? Is there an initial tag or something?

Yes, there’s a tag word

If you do something like have 2, 4 and 8 element list cons cells, I think you’ll end up saving memory overall, since most cons cells are probably list cells.

Also, if you enforce the condition that small list cells come before bigger ones, you can always assume that once you hit an 8 element cell, the rest are either null or an 8 element cell, so you don’t even have to check the tag while iterating past that small initial section.

Or possibly 3 and 7 so the size would be a nice round number.

Oh, I see what you mean. I haven’t learned/thought about that enough to know how cdr and similar operations work out

(lcons2 a rst) -> rst, (lcons3 x y rst) -> (lcons2 y rst), etc.

Admittedly, that is the weakness. Ideally, people would use things like map fold etc, or in-list, which can be implemented much more efficiently. You could probably do a compiler pass to transform loops iterating through with cdr.

I suppose it wouldn’t really be viable for existing racket code.