www.digitalmars.com         C & C++   DMDScript  

D - Interpolation in strings

reply Piotr Fusik <Piotr_member pathlink.com> writes:
Hello,

I miss the interpolation of variables inside strings, such as the one found in
Perl.
For example:
"I've got $n items"
works exactly like:
"I've got " ~ n ~ " items"

This simply makes things shorter and more readable.

The question is what expressions should be allowed. Perl interpolates only
variable values and indexing of arrays and hashes. I think that allowing object
member access (using '.') would be good, as long as no space is allowed around
the '.'. E.g.
"First element of a is $a[0]"
"foo.bar=$foo.bar"
Or, wrap any expression in brackets, e.g.
"a+b=${a+b}"

I would prefer the interpolation to be done by default inside every
double-quoted string. If you want the dollar sign, use \$. This shouldn't be a
problem in practice, since the interpolation is syntax-checked at compile-time.

Well, that certainly needs discussion, because it's an important feature.
Mar 11 2004
next sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Piotr Fusik wrote:
 Hello,
 
 I miss the interpolation of variables inside strings, such as the one found in
 Perl.
 For example:
 "I've got $n items"
 works exactly like:
 "I've got " ~ n ~ " items"
 
 This simply makes things shorter and more readable.
 
 The question is what expressions should be allowed. Perl interpolates only
 variable values and indexing of arrays and hashes. I think that allowing object
 member access (using '.') would be good, as long as no space is allowed around
 the '.'. E.g.
 "First element of a is $a[0]"
 "foo.bar=$foo.bar"
 Or, wrap any expression in brackets, e.g.
 "a+b=${a+b}"
 
 I would prefer the interpolation to be done by default inside every
 double-quoted string. If you want the dollar sign, use \$. This shouldn't be a
 problem in practice, since the interpolation is syntax-checked at compile-time.
 
 Well, that certainly needs discussion, because it's an important feature.
 
 

int n = 300; // For lack of a better number char[] aDString; aDString = "I've got " ~ n.toString() ~ " items."; // Are there toStrings on primitives? Alternatively you could make a printf() like function to insert variables into string and return a string. At any rate, it's *not* that difficult, leaves you with a more verbose and organized code where you can immediatly spot the variable being inserted into the string. Cheers, Sigbjørn Lund Olsen
Mar 11 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Sigbjørn Lund Olsen wrote:

<snip>
 Alternatively you could make a printf() like function to insert 
 variables into string and return a string.

Given a means of passing forward the dreaded variable argument list, it would be straightforward to make a wrapper for sprintf to do this. As long as you have an upper bound for the length of the resulting string. But when D finally gets its own decent I/O system, it would probably extend to working with strings. See thread "Possible solution for D's I/O system" from 2-3 Mar, especially my contribution. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Mar 12 2004
prev sibling parent reply Piotr Fusik <Piotr_member pathlink.com> writes:
aDString = "I've got " ~ n.toString() ~ " items.";
// Are there toStrings on primitives?

Unfortunately not...
Mar 13 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
On Sat, 13 Mar 2004 12:58:15 +0000 (UTC), Piotr Fusik
<Piotr_member pathlink.com> wrote:

aDString = "I've got " ~ n.toString() ~ " items.";
// Are there toStrings on primitives?

Unfortunately not...

from ChangeLog for .80: Added overloads for basic types for std.string.toString().
Mar 13 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Piotr Fusik wrote:
 Hello,
 
 I miss the interpolation of variables inside strings, such as the one found in
 Perl.
 For example:
 "I've got $n items"
 works exactly like:
 "I've got " ~ n ~ " items"
 
 This simply makes things shorter and more readable.

More readable: not to my eyes, but I haven't worked with Perl. My biggest criticism to this idea is that it would make it harder to parse strings. It would be more work for those writing D compilers, tools to analyze D code, syntax highlighting tools, etc. I think the only language that I've written in that allows this is PHP (which I just started learning a few weeks ago). I'm not used to this concept and I'm not convinced that it's particularly helpful. I'd likely have a different view if I'd used it for a long time. I think it's an interesting idea, but I'm afraid it would enable new exotic problems. -- Justin http://jcc_7.tripod.com/d/
Mar 11 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
J C Calvarese wrote:
 Piotr Fusik wrote:
 
 Hello,

 I miss the interpolation of variables inside strings, such as the one 
 found in
 Perl.
 For example:
 "I've got $n items"
 works exactly like:
 "I've got " ~ n ~ " items"

 This simply makes things shorter and more readable.

Shorter: yes. More readable: not to my eyes, but I haven't worked with Perl. My biggest criticism to this idea is that it would make it harder to parse strings. It would be more work for those writing D compilers, tools to analyze D code, syntax highlighting tools, etc. I think the only language that I've written in that allows this is PHP (which I just started learning a few weeks ago). I'm not used to this concept and I'm not convinced that it's particularly helpful. I'd likely have a different view if I'd used it for a long time. I think it's an interesting idea, but I'm afraid it would enable new exotic problems.

In PHP it's helpful until you realize that due to this 'liberal' design and other pieces of 'liberal' design it could compromise your code's security. It's better now that register_globals is off by default, but still not completely safe. While it makes a whole lot of sense to be very careful and not trust any input in a publically available script, it's surprising how many PHP coders actually do, and leave their scripts wide open to various forms of SQL (or other) insertion attacks. Also any 'client' can switch the dreaded register_globals back on, and surprisingly many idiots (including webspace providers & ISPs) populate this planet and do. As a consequence I *never* use "" to delimit strings anymore (nor should anyone), effectively forcing myself to use the concatenation operator when I want to insert a variable into a string. Of course, there's more checking to be done since it's a weakly typed language, etc etc etc. PHP isn't really a very good language. Like Perl and other scripting languages it seems to have been designed with 'getting the job done FAST' first in mind, and everything, including resource use, speed, *security* and more last. Cheers, Sigbjørn Lund Olsen
Mar 12 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Sigbjørn Lund Olsen" <sigbjorn lundolsen.net> wrote in message
news:c2rugj$29j$1 digitaldaemon.com...
 In PHP it's helpful until you realize that due to this 'liberal' design
 and other pieces of 'liberal' design it could compromise your code's
 security. It's better now that register_globals is off by default, but
 still not completely safe. While it makes a whole lot of sense to be
 very careful and not trust any input in a publically available script,
 it's surprising how many PHP coders actually do, and leave their scripts
 wide open to various forms of SQL (or other) insertion attacks. Also any
 'client' can switch the dreaded register_globals back on, and
 surprisingly many idiots (including webspace providers & ISPs) populate
 this planet and do. As a consequence I *never* use "" to delimit strings
 anymore (nor should anyone), effectively forcing myself to use the
 concatenation operator when I want to insert a variable into a string.
 Of course, there's more checking to be done since it's a weakly typed
 language, etc etc etc.

This does sound like a disastrous problem, but since D strings would not be interpreted at runtime, it shouldn't be a problem. Embedding $n is an interesting idea. I don't know if it adds enough utility, though.
Mar 12 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Walter wrote:
 "Sigbjørn Lund Olsen" <sigbjorn lundolsen.net> wrote in message
 news:c2rugj$29j$1 digitaldaemon.com...
 
In PHP it's helpful until you realize that due to this 'liberal' design
and other pieces of 'liberal' design it could compromise your code's
security. It's better now that register_globals is off by default, but
still not completely safe. While it makes a whole lot of sense to be
very careful and not trust any input in a publically available script,
it's surprising how many PHP coders actually do, and leave their scripts
wide open to various forms of SQL (or other) insertion attacks. Also any
'client' can switch the dreaded register_globals back on, and
surprisingly many idiots (including webspace providers & ISPs) populate
this planet and do. As a consequence I *never* use "" to delimit strings
anymore (nor should anyone), effectively forcing myself to use the
concatenation operator when I want to insert a variable into a string.
Of course, there's more checking to be done since it's a weakly typed
language, etc etc etc.

This does sound like a disastrous problem, but since D strings would not be interpreted at runtime, it shouldn't be a problem.

Why wouldn't they be interpreted at runtime? After all he's talking about inserting variables. I realize it's just syntactic sugar of the sort: "$a is a variable inserted into this string." meaning a.toString ~ " is a variable inserted into this string." as it is now (and personally I'm perfectly happy with that, even though I quite like C++'s insertion operators which hides the toString so to speak in normal usage)... You can't use concatenation to implicitly call toString like Java's println will, though, because it'll be ambiguous due to array and string concatenation being the same thing. Does the programmer intend for the integer to be converted to a string representation, or kept in its binary form when concatenating? I doubt the compiler would know, unless there was another operator, and I'm guessing we don't want nor need two operators for concatenation. But it'd certainly be interpreted at runtime. I agree, that it's unlikely to cause any problems in D, simply because a lot of the dodgy runtime framework of PHP isn't present. To sum it up, really, the problem with PHP is as follows: First and most importantly, PHP is so simple that most people writing PHP code are idiots, who do not consider for a second that they are writing executable code that will run in the use of serving web pages - a publically available and accessible spot. Most PHP coders seem to trust benevolent use, which is ridiculous for code that is run on request by anybody on the internet. PHP does not require initialization of variables before use. PHP is also loosely typed, so type conversion is always implicit. The register_globals setting, while now off by default, is still on (for backwards compatability and ease of coding) in many installations. For those who don't know it, register_globals creates variables named after HTTP and ENV data, so that http://www.foobar.com/?authorized=1 would make a variable $authorized which evaluates to boolean true. But essentially, in PHP if register_globals is on, any client can create variables with arbitrary names and content. The eval() function takes a string and runs it as if it were code. Most PHP scripts interface with databases for data retrieval and storage, using SQL. All this compiles into a nice slush where ignorant programmers create scripts for public invocation, where anyone can create a variable of arbitrary content, name and type, which is then inserted into strings (by said incompetent programmers) no questions asked, and then expedited into an eval() or an SQL query. Lamentable results ensue. Luckily, all of that has nothing to do with D.
 Embedding $n is an interesting idea. I don't know if it adds enough utility,
 though.

Well, *I* don't think so. Having different ways of doing the same thing is all very nice, but to a limit. Having $n mean 'concatenate surrounding string(s) with variable n' just adds another character we need to escape in literal strings and makes it harder to follow the flow of the code when skimming through someone elses code. And all of that for the sake of not having to type out " ~ n.toString ~ "... If the programmer resents typing so much he could even make himself a utility function template (this might not compile, never done much of templates, but I think you'll get the gist of it): template ToString(T) { char[] s(T variable) { return T.toString(); } } + some aliases for instantiating this with specific types... or a void* function or somesuch that will allow you to do something like this: s(var) ~ " is a variable put into this string." *looks at the above argument and code* I really ought to go to bed, oughtn't I? Cheers, Sigbjørn Lund Olsen
Mar 12 2004
parent reply Piotr Fusik <Piotr_member pathlink.com> writes:
No offence, but your opinion about PHP is really offtopic here.
Programming is much about doing complicated things efficiently.
Of course, you could live without the words "bookstore" and "buy", but think
about saying "I went to a place where people sell books, gave my money and took
a book" instead of "I bought a book in a bookstore".
Mar 13 2004
parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Piotr Fusik wrote:

 No offence, but your opinion about PHP is really offtopic here.

"Luckily, all of that has nothing to do with D." So, yes, it is somewhat off-topic, a little spurious rant in reply to J.C. Calvarese, and imo quite harmless. But only somewhat. When PHP is brought into the discussion, I don't see why I shouldn't be able to say why I don't like it in PHP. As I hope I made clear in my posts, the reason why I don't see any need for this is D has little to do with my dislike for it in PHP, because as I wrote in the reply, other flaws in PHP's design open up these nasty security pitfalls only in a combination which can't happen in D. It's simply because I feel it would be superfluous, and make code harder to browse. Not because I believe it will generate the problems PHP has - it won't.
 Programming is much about doing complicated things efficiently.
 Of course, you could live without the words "bookstore" and "buy", but think
 about saying "I went to a place where people sell books, gave my money and took
 a book" instead of "I bought a book in a bookstore".

If that were the level of expressive difference, yes, you would be right. But it's not 'bookstore' compared to 'a place where people sell books'. More like 'sound' compared to 'audio'. You want two different ways of expressing precisely the same thing, a short form of concatenating a variable into a string. I'd prefer it otherwise, to have a unified way of doing this, enabling easier browsing of 'foreign' code. And, at any rate, Walter will decide :-) Cheers, Sigbjørn Lund Olsen
Mar 13 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Piotr Fusik wrote:

 Hello,
 
 I miss the interpolation of variables inside strings, such as the one found in
 Perl.
 For example:
 "I've got $n items"

If you want Perl, you know where to find it. This 'group is about D, a language in which quotation marks have an established purpose: to delimit a string _literal_. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Mar 12 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Stewart Gordon wrote:
 Piotr Fusik wrote:
 
 Hello,

 I miss the interpolation of variables inside strings, such as the one 
 found in
 Perl.
 For example:
 "I've got $n items"

<snip> If you want Perl, you know where to find it.

And if Perl has a killer feature that D could benefit from I think we should let someone suggest it. It's not like he's endlessly extolling the virtues of that paragon of programming languages, C#. (Ominous music plays...)
 
 This 'group is about D, a language in which quotation marks have an 
 established purpose: to delimit a string _literal_.

He's making a suggestion for an improvement to D. He's not asking us to join a Perl fan club. While I think that the benefits don't outweigh the costs of the proposal, I still think it's still an interesting idea. I'm glad it was suggested.
 
 Stewart.

-- Justin http://jcc_7.tripod.com/d/
Mar 12 2004
parent reply Piotr Fusik <Piotr_member pathlink.com> writes:
He's making a suggestion for an improvement to D. He's not asking us to 
join a Perl fan club.

Thanks. That's exactly what I meant. I see that there was much misunderstanding here: the feature should be treated just as a syntactic sugar! It does not make D a scripting language. If you don't get "syntactic sugar": you can write ++i instead of (i=i+1), even though both are semantically the same. I looked at sources written in C, C++, Java, C#, Perl, D, Python... and I think that saving some characters is really worth trouble. Compare this: "x=$x y=$y z=$z" with this: "x="~x~" y="~y~" z="~z Which one is easier to write and read?
Mar 13 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Piotr Fusik wrote:
 Compare this:
 "x=$x y=$y z=$z"
 with this:
 "x="~x~" y="~y~" z="~z
 Which one is easier to write and read?

The trouble with this is that D is a statically compiled language; it isn't dynamic like Perl is, so it can't realistically inspect string literals like that without making the compiler horribly weird and convoluted. If D were to incorporate this, string literals wouldn't necessarily literal values at all, but expressions! So now what happens when you say: x=1; a="$x"; x=0; b=a; Is b equal to "1" or "0"? This has to be compiled into native assembly, so there's no way to find a value called 'x' at runtime. (also, I would argue that the whole interpolation concept is flawed because of this ambiguity) ("x=%s y=%s z=%s", x, y, z) isn't so bad. :) -- andy
Mar 13 2004
next sibling parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
Comments imbedded:

     x=1; a="$x";
     x=0; b=a;
 
 Is b equal to "1" or "0"?

If it were me designing things, b would equal "1". If this feature were included, then it would only make sense IMHO to evaluate the string-expression at compile-time and at first occurance, so: a = "$x"; ---> a = "" ~ x ~ ""; Which seems do-able... except now one has to wonder what gets to convert x to a string if it isn't already. If we had the static passback idea I presented once, it might not be such a big deal, but as things are, its darn near impossible.
 ("x=%s y=%s z=%s", x, y, z) isn't so bad. :)

Agreed. Maybe we could have something like Python's feature: x = "abc" y = "def" z = "ghi" foo = "x=%s y=%s z=%s" % (x, y z) # foo now equals: "x=abc y=def z=ghi" Then in D we could avoid the issue of who does the conversion with a syntax likened to: int i = 123; char[] foo = "i = %, i++ = %" % [toString(i), toString(i + 1)]; -C. Sauls -invironz
Mar 13 2004
next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
C. Sauls wrote:
 Comments imbedded:
 
     x=1; a="$x";
     x=0; b=a;

 Is b equal to "1" or "0"?

If it were me designing things, b would equal "1". If this feature were included, then it would only make sense IMHO to evaluate the string-expression at compile-time and at first occurance, so: a = "$x"; ---> a = "" ~ x ~ ""; Which seems do-able... except now one has to wonder what gets to convert x to a string if it isn't already. If we had the static passback idea I presented once, it might not be such a big deal, but as things are, its darn near impossible.

Conversion to string isn't a problem. You just say that instead of: a = "$x"; ---> a = "" ~ x ~ ""; you define the 'sugar expansion' like this: a = "$x"; ---> a = "" ~ x.toString() ~ ""; since toString is defined for all primitives (since 0.80 apparently) and since all objects inherit from Object all have toString(). Dunno about structs, though. Nor arrays. Cheers, Sigbjørn Lund Olsen
Mar 13 2004
prev sibling parent Piotr Fusik <Piotr_member pathlink.com> writes:
     x=1; a="$x";
     x=0; b=a;
 
 Is b equal to "1" or "0"?

If it were me designing things, b would equal "1".

I think this is obvious.
	foo = "x=%s y=%s z=%s" % (x, y z)
	# foo now equals: "x=abc y=def z=ghi"

sprintf... But personally I prefer string interpolation - I get lost when having 5 or more arguments to printf-like functions.
Mar 14 2004
prev sibling parent reply Ben Robinson <Ben_member pathlink.com> writes:
In article <c2v9t4$2nbo$1 digitaldaemon.com>, Andy Friesen says...
Piotr Fusik wrote:
 Compare this:
 "x=$x y=$y z=$z"
 with this:
 "x="~x~" y="~y~" z="~z
 Which one is easier to write and read?

The trouble with this is that D is a statically compiled language; it isn't dynamic like Perl is, so it can't realistically inspect string literals like that without making the compiler horribly weird and convoluted. If D were to incorporate this, string literals wouldn't necessarily literal values at all, but expressions! So now what happens when you say: x=1; a="$x"; x=0; b=a; Is b equal to "1" or "0"? This has to be compiled into native assembly, so there's no way to find a value called 'x' at runtime. (also, I would argue that the whole interpolation concept is flawed because of this ambiguity) ("x=%s y=%s z=%s", x, y, z) isn't so bad. :) -- andy

Mar 18 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ben Robinson wrote:

In article <c2v9t4$2nbo$1 digitaldaemon.com>, Andy Friesen says...
  

Piotr Fusik wrote:
    

Compare this:
"x=$x y=$y z=$z"
with this:
"x="~x~" y="~y~" z="~z
Which one is easier to write and read?
      

isn't dynamic like Perl is, so it can't realistically inspect string literals like that without making the compiler horribly weird and convoluted. If D were to incorporate this, string literals wouldn't necessarily literal values at all, but expressions! So now what happens when you say: x=1; a="$x"; x=0; b=a; Is b equal to "1" or "0"? This has to be compiled into native assembly, so there's no way to find a value called 'x' at runtime. (also, I would argue that the whole interpolation concept is flawed because of this ambiguity) ("x=%s y=%s z=%s", x, y, z) isn't so bad. :) -- andy


worked out and a pointer the original value be placed there instead, as a bunch of appends. You wouldn't be able to, for example form the string like ie: int x; a = "$" a ~= "x" and expect it to recognise that $x is a variable. However a = "$x" would be converted into: a = x.tostring(); at compile time. Another problem is that we've just lost another symbol. Not that I agree that D needs yet another way to build strings. It just makes things more confusing, and code harder to read. We don't need 101 ways to do the same thing. I should be either one or the other and it should be generic and powerful, as the current method is. -- -Anderson: http://badmama.com.au/~anderson/
Mar 18 2004