3 ms·

In the Lisp world one often hears disdain for strings, and advice to get one's data in to some other representation so that it's safer, more expressive, and eas

In the Lisp world one often hears disdain for strings, and advice to get one's data in to some other representation so that it's safer, more expressive, and easier to work with. Coming from that background, it's interesting to hear of TCL (which I do not personally know how to program in) embracing strings. It would be interesting to read an article that goes in to some depth about the sorts of useful things that TCL's focus on strings makes possible or easy that would be difficult or unnatural to do in other languages.

kevin_thibedeau 6y ago
Tcl hasn't been string focused since 8.0 was released 20 years ago. Tcl objects are convertible to and from strings. That conversion can be deferred so a string representation hangs around but it still only uses strings as needed. Nobody says Lisp is string based because everything can be printed as an s-expr.
- isr 6y ago
  Umm, sorry, no. First of all, lisp sexps have nothing to do with strings (which is why noone says that), whereas in tcl, every data structure has something to do with strings. In tcl, semantically, everything is a string. Yes, the native internal representations of compound structures like lists and dicts are actually very efficient, but you can refer to those structures as if they were a string at any point. And that will often cause the internal representation to switch to a string, and dump the more efficient "native" rep aside. And that can happen when you don't really intend for it to happen (the infamouse "shimmering" problem). Thats the biggest flaw I've found in years of hacking with tcl. It makes it hard to write funcs which take polymorphic data types. Is this a list of lists (where each sublist contains strings) or a list of strings (where each string may have whitespace) You end up creating your own dynamic typing system sometimes. I know I have, and so have others (see the wiki). There is SO much to love about tcl. It really is a lisp smashed into shell. And its so dynamic that you can do really powerful things in it. Its really a lisp,, where the standard data structure is the string, not a linked list. And any func can be an f-expr (basically, sort of a runtime macro, which older lisps used to have). I had a lot of fun redoing things like quasiquote (from lisp) in tcl. Yes, you really can generate tcl code as a template rather than manipulating strings. Combine some sort of diy tagging system with ensembles (so that your code will run specialised funcs all automatically chosen based on your initial tag name). The OO system is basically a toolbox for building any kind of OO system you want on top of it (almost akin to CLOS-inspired systems, in that regard) Stackable io channels so that you can build a virtual filesystem with a various features all composed together (FUSE-like done beautifully, from a scripting lang perspective) Great stuff. It really is a lisp/shell kind of thing, but sometimes its so dynamic that it shoots itself in the foot (shimmering, etc). I wish they had decided to dump backwards compatibility post 8.0, and tried addressing some of horrible warts in the language and runtime, eg: - the syntax rules are simple, but result in non-trivial code looking F UGLY (emphasis on the F). A couple of extensions to that syntax would have made the world of difference. How much more complicated would, say, 15 syntax rules be instead of 12? - shimmering. NO. Stop it. - not everything makes sense as a string rep (filehandles?) - the standard commandset (really each is a DSL in its own right) needed to be revised long ago so that they were more consistent with each other (contrast list cmds with others) Basically, maintaining backwards compatibility has killed tcl, even though it has so many nice features and potential greatness hidden inside. (eg: jimtcl, a hidden gem) Ok, I'm ranting now, I'll stop :-)
blacksqr 6y ago
If you like the "Unix Way" idea that programs should be able to handle input and output in a high-level string representation so that it is trivial to share data among a multitude of independently written programs, then you'll love Tcl. Tcl not only allows you to share string representations of data between different programs, but also internally between different modules of the same program, easing issues of interoperability, scalability and deployability in wildly different systems and environments.
- pmoriarty 6y ago
  "Tcl not only allows you to share string representations of data between different programs, but also internally between different modules of the same program, easing issues of interoperability, scalability and deployability in wildly different systems and environments" So how does that differ from just passing around a JSON blob or something?
  - blacksqr 6y ago
    JSON is a typed data format, where details of formatting and interpretation of types is left to the implementation. If you're not using Javascript, encoding and extracting the type information can be tricky unless you know the source well and understand the type formalisms it uses. Thus JSON isn't as handy as a universal data exchange format.
    - pmoriarty 6y ago
      I'm still trying to wrap my head around what you're getting at... is it closer, then, to XML with an XML schema?
      - bodhiandpysics1 6y ago
        There is no schema!

kevin_thibedeau 6y ago

Tcl hasn't been string focused since 8.0 was released 20 years ago. Tcl objects are convertible to and from strings. That conversion can be deferred so a string representation hangs around but it still only uses strings as needed. Nobody says Lisp is string based because everything can be printed as an s-expr.

isr 6y ago
Umm, sorry, no. First of all, lisp sexps have nothing to do with strings (which is why noone says that), whereas in tcl, every data structure has something to do with strings. In tcl, semantically, everything is a string. Yes, the native internal representations of compound structures like lists and dicts are actually very efficient, but you can refer to those structures as if they were a string at any point. And that will often cause the internal representation to switch to a string, and dump the more efficient "native" rep aside. And that can happen when you don't really intend for it to happen (the infamouse "shimmering" problem). Thats the biggest flaw I've found in years of hacking with tcl. It makes it hard to write funcs which take polymorphic data types. Is this a list of lists (where each sublist contains strings) or a list of strings (where each string may have whitespace) You end up creating your own dynamic typing system sometimes. I know I have, and so have others (see the wiki). There is SO much to love about tcl. It really is a lisp smashed into shell. And its so dynamic that you can do really powerful things in it. Its really a lisp,, where the standard data structure is the string, not a linked list. And any func can be an f-expr (basically, sort of a runtime macro, which older lisps used to have). I had a lot of fun redoing things like quasiquote (from lisp) in tcl. Yes, you really can generate tcl code as a template rather than manipulating strings. Combine some sort of diy tagging system with ensembles (so that your code will run specialised funcs all automatically chosen based on your initial tag name). The OO system is basically a toolbox for building any kind of OO system you want on top of it (almost akin to CLOS-inspired systems, in that regard) Stackable io channels so that you can build a virtual filesystem with a various features all composed together (FUSE-like done beautifully, from a scripting lang perspective) Great stuff. It really is a lisp/shell kind of thing, but sometimes its so dynamic that it shoots itself in the foot (shimmering, etc). I wish they had decided to dump backwards compatibility post 8.0, and tried addressing some of horrible warts in the language and runtime, eg: - the syntax rules are simple, but result in non-trivial code looking F UGLY (emphasis on the F). A couple of extensions to that syntax would have made the world of difference. How much more complicated would, say, 15 syntax rules be instead of 12? - shimmering. NO. Stop it. - not everything makes sense as a string rep (filehandles?) - the standard commandset (really each is a DSL in its own right) needed to be revised long ago so that they were more consistent with each other (contrast list cmds with others) Basically, maintaining backwards compatibility has killed tcl, even though it has so many nice features and potential greatness hidden inside. (eg: jimtcl, a hidden gem) Ok, I'm ranting now, I'll stop :-)

blacksqr 6y ago

If you like the "Unix Way" idea that programs should be able to handle input and output in a high-level string representation so that it is trivial to share data among a multitude of independently written programs, then you'll love Tcl. Tcl not only allows you to share string representations of data between different programs, but also internally between different modules of the same program, easing issues of interoperability, scalability and deployability in wildly different systems and environments.

pmoriarty 6y ago
"Tcl not only allows you to share string representations of data between different programs, but also internally between different modules of the same program, easing issues of interoperability, scalability and deployability in wildly different systems and environments" So how does that differ from just passing around a JSON blob or something?
- blacksqr 6y ago
  JSON is a typed data format, where details of formatting and interpretation of types is left to the implementation. If you're not using Javascript, encoding and extracting the type information can be tricky unless you know the source well and understand the type formalisms it uses. Thus JSON isn't as handy as a universal data exchange format.
  - pmoriarty 6y ago
    I'm still trying to wrap my head around what you're getting at... is it closer, then, to XML with an XML schema?
    - bodhiandpysics1 6y ago
      There is no schema!