4 ms·

Well you could always do something like base64, which might be a fine work-around in some situations.

• tyingq 10y ago
  I mentioned it mostly because the actual tcl interpreter originally had this issue. When it was fixed, the language became much more useful. Base64 wouldn't help much dealing with existing binary files, for example. Or network protocols, or unicode, and so forth.
  • to3m 10y ago
    If fixed properly, it would open the door to non-string types - like, you could have a type that's entirely opaque to tcl, just a void * or whatever, accessed only through functions. This might even actually end up being a step up compared to "proper" tcl... This would push the line count over 600, but I bet it would still come in at less than a nice round 1,000, while making the thing a lot more useful. (I have a side project that's starting to feel like it might need a scripting language. And I always liked tcl. Must... resist... rabbit holes...)
    • tyingq 10y ago
      Probably a rabbit hole, but tcl strings are sort of dual typed. Normally, they are arrays of unicode, including multibyte. But tcl offers a keyword "binary" to treat them as arrays of single bytes. http://wiki.tcl.tk/1181 http://wiki.tcl.tk/1181
• deleted 10y ago
  [deleted]