4 ms·

One of the greatest things in Tcl is that I do not need to worry about escaping quotes in strings because of the {} syntax. Working with filenames with spaces i

by gaudat 3y ago

One of the greatest things in Tcl is that I do not need to worry about escaping quotes in strings because of the {} syntax. Working with filenames with spaces is a breeze. And lists being first class citizens instead of an afterthought like in shell scripts. Too bad I only learned it use it because it is the only scripting language the big EDA suites support.

hoosieree 3y ago
The fact that I learned Tcl because of Vivado is probably why I don't like it. I'll probably never like it, but I can at least admit it has some nice features that make sense for an embedded scripting language. But I've never seen anything more vile[0] than Cadence's "Ocean" scripting language[1]. It has such contempt for the user. For example, when learning you might notice command( is ok but command ( is a syntax error. You then might conclude that the language is trying to be strict and help you write correct programs. But then you realize that "] is magic syntax which closes all previous strings, and it just gets worse from there. [0]: except satirical/joke languages [1]: https://www.eecis.udel.edu/~vsaxena/courses/ece697A/docs/OCEAN+Reference.pdf https://www.eecis.udel.edu/~vsaxena/courses/ece697A/docs/OCE...
- dfox 3y ago
  That is because SKILL is really an scheme under the hood. And somebody had the bright idea of making the syntax more "user friendly" (read: more like C) by inventing a rule that "foo(bar)" parses as "(foo bar)" while "foo (bar)" parses as "foo (bar)". IIRC there also is another similar rule for when expression is parsed as infix. Right bracket with the meaning of close all was used in some lisps because somebody did not like the long runs of closing parens at the end of definitions.
  - hoosieree 3y ago
    Yup. Ease at the cost of simplicity comes at the cost of ease.
IshKebab 3y ago
Lists are not first class citizens. They are semicolon separated strings. Exactly the same as Bash lists but with a different separator.
- pwg 3y ago
  This has not been correct since Tcl 8.0 debuted circa 1999. 8.0's Tcl_Obj system allowed for lists to be proper O(1) integer indexed arrays while also retaining compatibility with 7.x's "specially formatted strings". And even for 7.x where lists were just "specially formatted strings" they were not simply "semicolon separated" strings, the special formatting was more complex than "semi-colon delimiter".
  - IshKebab 3y ago
    Nope. Semantically they are still semi-colon separated lists. The fact that recent official TCL engines include performance optimisations does not change that fact, nor does it fix most of the issues with "everything is a string". > they were not simply "semicolon separated" strings, the special formatting was more complex than "semi-colon delimiter". Yes of course it needs quoting so that semicolons can be included. Thanks for pointing out one of the downsides of "everything is a string".
    - pwg 3y ago
      > Nope. Semantically they are still semi-colon separated lists. Double nope. Tcl lists, even when they were specially formatted strings in 7.x versions, were never "semi-colon separated lists". For all but the simplest lists the special formatting was and is much closer to LISP s-exprs, only using {} instead of () for the formatting delimiter. Which was how Tcl's lists, just like LISP lists, can represent nested list structures, which plain semi-colon separators cannot. > The fact that recent official TCL engines include performance optimisations does not change that fact, nor does it fix most of the issues with "everything is a string". But it does mean that in modern Tcl versions, your code does not have to pay the price of parsing that special string more than once, removing the biggest issue with "everything is a string" (the performance issues in 7.x versions). > Yes of course it needs quoting so that semicolons can be included. Thanks for pointing out one of the downsides of "everything is a string". That is no more a downside of "everything is a string" than needing to quote an ASCII double quote (") in a C string literal because double quotes delimit the literal itself is a downside of C string literals. The special characters in any language will need some method of quoting to be used as themselves in positions that they would otherwise be interpreted as part of the language grammar.
remram 3y ago
Spaces wouldn't need to be escaped within quotes either. Now how do you write a filename with a } in it?
- dmd 3y ago
  Trivial. First, "package require delorean". Travel back in time to when the parents of the person who created that file met... the rest is left as an exercise for the reader.
- NoMoreNicksLeft 3y ago
  In my personal life, I've discovered to name some files with (the most common) punctuation. I've taken to using the full-width unicode variants. These work on Mac, Windows, and Linux. They don't seem to cause problems for any software that can handle utf-8 correctly. Looks like there are curly braces in the full-width stuff... it'd be \uff5d looks like. No idea if it'd survive Tcl or not.
adrianmonk 3y ago
> do not need to worry about escaping quotes in strings because of the {} syntax Perl has strong support for that: https://perldoc.perl.org/perlop#Quote-Like-Operators https://perldoc.perl.org/perlop#Quote-Like-Operators You can basically use any character as a delimiter except whitespace. All of these lines are equivalent: $str = 'Hello, world.'; $str = q{Hello, world.}; $str = q[Hello, world.]; $str = q(Hello, world.); $str = q<Hello, world.>; $str = q|Hello, world.|; $str = q!Hello, world.!; $str = q#Hello, world.#; $str = q%Hello, world.%; $str = q=Hello, world.=; $str = q 7Hello, world.7; Note that when you use a letter or number (actually any character that's legal in an identifier), you need a space after the "q". You can also do it with other types of quotes, like double quotes (that support variable interpolation). These are equivalent: $var1 = 'abc'; $var2 = "Value of var1 is $var1."; $var1 = 'abc'; $var2 = qq[Value of var1 is $var1.]; And you can also do it with regular expression matches: if (/pattern/) { whatever(); } if (qr|pattern|}) { whatever(); } and substitutions: s/pattern/replacement/; s|pattern|replacement|; sed also has something similar: echo abc | sed -e 's/abc/def/' echo abc | sed -e 's#abc#def#'
- mdaniel 3y ago
  $str = q 7Hello, world.7; whew, I would not want to be in the business of lexing perl > sed also has something similar: I also recently learned that one can do the same in the "pattern match" case (not just with `s`) by using a backslash, as in: printf 'a/b/c\nd/e/f\n' | sed -ne '\_a/b/c_p' the man page says "any character" and sure enough, `\ a/b/c p` works also
  - wernsey 3y ago
    Sheesh, me neither. How on earth would you create syntax highlighters and other tools for this language?
  - yellowapple 3y ago
    > whew, I would not want to be in the business of lexing perl Hence the saying: the only thing that can parse Perl is Perl :)
smrtinsert 3y ago
The real power was unlocked with uplevel, upvar and switch regexp for a variety of reasons. I miss sane language extensibility. It was meh in clojure by comparison and too much in scala.

by gaudat 3y ago

hoosieree 3y ago

The fact that I learned Tcl because of Vivado is probably why I don't like it. I'll probably never like it, but I can at least admit it has some nice features that make sense for an embedded scripting language. But I've never seen anything more vile[0] than Cadence's "Ocean" scripting language[1]. It has such contempt for the user. For example, when learning you might notice command( is ok but command ( is a syntax error. You then might conclude that the language is trying to be strict and help you write correct programs. But then you realize that "] is magic syntax which closes all previous strings, and it just gets worse from there. [0]: except satirical/joke languages [1]: https://www.eecis.udel.edu/~vsaxena/courses/ece697A/docs/OCEAN+Reference.pdf https://www.eecis.udel.edu/~vsaxena/courses/ece697A/docs/OCE...

dfox 3y ago
That is because SKILL is really an scheme under the hood. And somebody had the bright idea of making the syntax more "user friendly" (read: more like C) by inventing a rule that "foo(bar)" parses as "(foo bar)" while "foo (bar)" parses as "foo (bar)". IIRC there also is another similar rule for when expression is parsed as infix. Right bracket with the meaning of close all was used in some lisps because somebody did not like the long runs of closing parens at the end of definitions.
- hoosieree 3y ago
  Yup. Ease at the cost of simplicity comes at the cost of ease.

IshKebab 3y ago

Lists are not first class citizens. They are semicolon separated strings. Exactly the same as Bash lists but with a different separator.

pwg 3y ago
This has not been correct since Tcl 8.0 debuted circa 1999. 8.0's Tcl_Obj system allowed for lists to be proper O(1) integer indexed arrays while also retaining compatibility with 7.x's "specially formatted strings". And even for 7.x where lists were just "specially formatted strings" they were not simply "semicolon separated" strings, the special formatting was more complex than "semi-colon delimiter".
- IshKebab 3y ago
  Nope. Semantically they are still semi-colon separated lists. The fact that recent official TCL engines include performance optimisations does not change that fact, nor does it fix most of the issues with "everything is a string". > they were not simply "semicolon separated" strings, the special formatting was more complex than "semi-colon delimiter". Yes of course it needs quoting so that semicolons can be included. Thanks for pointing out one of the downsides of "everything is a string".
  - pwg 3y ago
    > Nope. Semantically they are still semi-colon separated lists. Double nope. Tcl lists, even when they were specially formatted strings in 7.x versions, were never "semi-colon separated lists". For all but the simplest lists the special formatting was and is much closer to LISP s-exprs, only using {} instead of () for the formatting delimiter. Which was how Tcl's lists, just like LISP lists, can represent nested list structures, which plain semi-colon separators cannot. > The fact that recent official TCL engines include performance optimisations does not change that fact, nor does it fix most of the issues with "everything is a string". But it does mean that in modern Tcl versions, your code does not have to pay the price of parsing that special string more than once, removing the biggest issue with "everything is a string" (the performance issues in 7.x versions). > Yes of course it needs quoting so that semicolons can be included. Thanks for pointing out one of the downsides of "everything is a string". That is no more a downside of "everything is a string" than needing to quote an ASCII double quote (") in a C string literal because double quotes delimit the literal itself is a downside of C string literals. The special characters in any language will need some method of quoting to be used as themselves in positions that they would otherwise be interpreted as part of the language grammar.

remram 3y ago

Spaces wouldn't need to be escaped within quotes either. Now how do you write a filename with a } in it?

dmd 3y ago
Trivial. First, "package require delorean". Travel back in time to when the parents of the person who created that file met... the rest is left as an exercise for the reader.
NoMoreNicksLeft 3y ago
In my personal life, I've discovered to name some files with (the most common) punctuation. I've taken to using the full-width unicode variants. These work on Mac, Windows, and Linux. They don't seem to cause problems for any software that can handle utf-8 correctly. Looks like there are curly braces in the full-width stuff... it'd be \uff5d looks like. No idea if it'd survive Tcl or not.

adrianmonk 3y ago

> do not need to worry about escaping quotes in strings because of the {} syntax Perl has strong support for that: https://perldoc.perl.org/perlop#Quote-Like-Operators https://perldoc.perl.org/perlop#Quote-Like-Operators You can basically use any character as a delimiter except whitespace. All of these lines are equivalent: $str = 'Hello, world.'; $str = q{Hello, world.}; $str = q[Hello, world.]; $str = q(Hello, world.); $str = q<Hello, world.>; $str = q|Hello, world.|; $str = q!Hello, world.!; $str = q#Hello, world.#; $str = q%Hello, world.%; $str = q=Hello, world.=; $str = q 7Hello, world.7; Note that when you use a letter or number (actually any character that's legal in an identifier), you need a space after the "q". You can also do it with other types of quotes, like double quotes (that support variable interpolation). These are equivalent: $var1 = 'abc'; $var2 = "Value of var1 is $var1."; $var1 = 'abc'; $var2 = qq[Value of var1 is $var1.]; And you can also do it with regular expression matches: if (/pattern/) { whatever(); } if (qr|pattern|}) { whatever(); } and substitutions: s/pattern/replacement/; s|pattern|replacement|; sed also has something similar: echo abc | sed -e 's/abc/def/' echo abc | sed -e 's#abc#def#'

mdaniel 3y ago
$str = q 7Hello, world.7; whew, I would not want to be in the business of lexing perl > sed also has something similar: I also recently learned that one can do the same in the "pattern match" case (not just with `s`) by using a backslash, as in: printf 'a/b/c\nd/e/f\n' | sed -ne '\_a/b/c_p' the man page says "any character" and sure enough, `\ a/b/c p` works also
- wernsey 3y ago
  Sheesh, me neither. How on earth would you create syntax highlighters and other tools for this language?
- yellowapple 3y ago
  > whew, I would not want to be in the business of lexing perl Hence the saying: the only thing that can parse Perl is Perl :)

smrtinsert 3y ago

The real power was unlocked with uplevel, upvar and switch regexp for a variety of reasons. I miss sane language extensibility. It was meh in clojure by comparison and too much in scala.