Re:Why Tcl?
by keithalewis on Tuesday June 20, 2023 @10:42AM
(#36404754)
You can have any type you want, as long as it's a string. :-)
Don't forget about https://core.tcl-lang.org/expect/index. Comes in very handy sometimes.
[ Parent
| on HN ]
Re:Why Tcl?
by kevin_thibedeau on Tuesday June 20, 2023 @11:56AM
(#36405948)
Tcl hasn't been string based for over 20 years. It's time for this myth to die.
If it's a myth, the myth seems driven by the TCL team itself.
https://wiki.tcl-lang.org/page/everything+is+a+string
Yes, there is some detail about internal dual representation.
Re:Why Tcl?
by kevin_thibedeau on Tuesday June 20, 2023 @12:56PM
(#36406957)
That wiki page has been around since before Tcl 8. Nobody says lisp is hampered because everything is an S-expr.
> That wiki page has been around since before Tcl 8
Maybe, but it's clearly been updated after Tcl 8. And while the page itself isn't calling it something that hampers tcl, it does cover that it's somewhat unusual, that is has implications, and so on.
Technically, all values are considered subtypes of strings, but the notion of types is quite different to those of many other languages. In particular, Tcl's types do not describe the memory storage model of their values. (They're implemented with 64-bit words and buffers and arrays and so on, but that's not what the value model describes.)
It works well as long as your goal isn't to totally eliminate boxing of values.
after using expect and TCL heavily for years, I can firmly say they suck at scale.
Ruby https://github.com/ytti/oxidized/blob/master/lib/oxidized/mo... or TextFSM https://github.com/google/textfsm
are much better options if you need to do a /lot/ of parsing