Perl has strong support for that: 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;
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.];
if (/pattern/) { whatever(); }
if (qr|pattern|}) { whatever(); }
s/pattern/replacement/;
s|pattern|replacement|;
echo abc | sed -e 's/abc/def/'
echo abc | sed -e 's#abc#def#' $str = q 7Hello, world.7;
> 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'
Hence the saying: the only thing that can parse Perl is Perl :)
It also seems <https://github.com/Camelcade/Perl5-IDEA/blob/2023.1.1/plugin...> that one can have line comments in there, too
my $str = q #what is happening here
7Hello, world.7;How on earth would you create syntax highlighters and other tools for this 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(
command (
"]
[0]: except satirical/joke languages
[1]: https://www.eecis.udel.edu/~vsaxena/courses/ece697A/docs/OCE...
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.
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.
No idea if it'd survive Tcl or not.
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".
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".
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.