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.


<snip>

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.


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.

-- 
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"


<snip>

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 

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.

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)


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)



Well, Python also uses + for string concatenation. Maybe D could use   for
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?
      


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
    




Not that I agree with the original idea, but the $x could be staticly 
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