Nenad Rakocevic
Nenad Rakocevic
If it is allowed on integers, it should be allowed on all datatypes supported by `vector!`.
What happens it that the last printed line gets "eaten" by the error message, so you don't see it. Try with your first example by putting two PRINT calls before...
Thanks for the deep analysis. I will see if the checking can let the left operand be evaluated first (needs to be done both for the interpreter and compiler, in...
> E.g. it works with ops: The fact that it works in your expression above is not related to op! usage, but because the left operand is an expression with...
Encoding/decoding different locales like ISO-8859-1 is planned to be handled by the codec system.
> Another use-case that I just stumbled upon: analyzing binary data. String! has a specfic internal encoding (UCS1, UCS2 or UCS4). If a string! is constructed from a binary! with...
> OTOH, if such binary! buffer is modified, then the resulting string will likely get corrupted. We can't allow that to happen.
As a side note, `scan` does not have the same issue: ``` >> s: "ab cd ef [] ;oops" == "ab cd ef [] ;oops" >> while [not tail? s]...
I propose `transcode/next` returns an empty block when reaching the end. For `transcode/one`, it could indeed raise an error on empty input.
Notice this subtle difference in `scan/next` behavior: ``` >> scan/next "" == none >> scan/next ";klklkl" == [none ""] ```