@ngn yeah, using char as int speeds up the copying quite a lot. btw, is it cost too much to implement an adaptive int list type? i.e. a list of integers whose type depends on the largest/smallest value in it?
@ksi depends on how much is too much. detecting overflows is difficult in c - it may require asm and cost some performance. casting the current result to a wider type and continuing in another loop adds complexity.
@ngn yes, so i guess i meant in a append-only way like the list buffer you mentioned. or only support (char$1 2 3) + int$10, whenever the type can be known in advance. therefore the user is responsible for providing the type of results. i am not particularly into the idea of (char$3)+(char$127)=(`int$130)
@ngn yes, so i guess i meant in a append-only way like the list buffer you mentioned. or only support (char$1 2 3) + int$10, whenever the type can be known in advance. therefore the user is responsible for providing the type of results. i am not particularly into the idea of 0xff+0x01=256i
@ngn i guess the only difference that matters is which type should a number literal have. i was thinking something like assigning number literals the smallest possible type unless instructed otherwise. so, !5 is 0 1 2 3 4 but actually 0x0001020304
I guess one alternative to wrap-around overflows is to use saturating arithmetic =P. Although if going down the route of examining the largest/smallest value in a list, might as well use some more advanced compression (rather than sticking to fixed machine-width integers, use e.g. 5-bit integers, or 20-bit integers or whatever).
