www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP1027 - Easy String Interpolation implementation

reply Walter Bright <newshound2 digitalmars.com> writes:
Several people asked for an implementation to try out, so here it is:

https://github.com/dlang/dmd/pull/15722
Oct 22 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here 
 it is:

 https://github.com/dlang/dmd/pull/15722


I posted instructions for those wanting to try it out here:
https://forum.dlang.org/post/vthbbsubmxihmulthplo forum.dlang.org
Oct 22 2023
prev sibling next sibling parent reply Juraj <zero vec4.xyz> writes:
On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here


Thank you,
I have tried it out, and indeed had fun.
Here are some of the examples of the 'fun' I encountered.

Juraj

```d

import core.stdc.stdio; // I can not bother with phobos right now

void main() {
     {
         int area_id = 51;
         int pod_to_drop_id = 69;

         eject_pods(i"medbay$area_id", pod_to_drop_id);
     }

     {
         string user = "root";
         string file = "stuff";

         delete_files_silently(i"/tmp/dummy_$user/$file", 
"/tmp/something_else");
         // Even better would be, to drop some tables form 
database....
     }

     {
         string name = "John";
         int anxlvl = 9000;
         string suggestion_msg = "Refer to the file and line 
number to save him!!!";

         log_error(2, i"$name's anxiety level is rising to level 
$anxlvl, suggestion:'$suggestion_msg'");
     }
}


void eject_pods(string area_name, int start_pod_idx, int count = 
1) {

     enum SACRILEGE_VULCAN_AREA_NAME = "medbay%s"; // Spock 
insisted on %s so we have to keep it, Scotty

     if (area_name == SACRILEGE_VULCAN_AREA_NAME) autodestruct();

     for (int i = 0; i < count; i++) {
         printf("Dropping from %s pod : %d\n", area_name.ptr, 
start_pod_idx + i);
     }
}


void delete_files_silently(string some_param, string[] filepaths 
...) {

     foreach (string fp; filepaths) {

         printf("Deleting file %s\n", fp.ptr);

         try {
             // delete_file(fp);
         }
         catch(Exception ex) {
             // Who cares, silence is gold.
         }
     }

}


void log_error(int level, string message, string file = __FILE__, 
int line = __LINE__, string[] more ...) {
     printf(i"[${%02d}level] $(file.ptr):${%04d}(line) 
$(message.ptr)\n");
}

void autodestruct() {}

```
Oct 22 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2023 3:17 AM, Juraj wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here


 
 Thank you,
 I have tried it out, and indeed had fun.
 Here are some of the examples of the 'fun' I encountered.


Yes, we've seen these before in the other threads, and I replied to them there.
Oct 22 2023
parent reply Juraj <zero vec4.xyz> writes:
On Sunday, 22 October 2023 at 17:46:16 UTC, Walter Bright wrote:


 Yes, we've seen these before in the other threads, and I 
 replied to them there.


Sorry for being repetitive, but as you made an implementation 
only after the DIP was rejected, I figured it would be beneficial 
to show some real examples.
I think they show in action one of the key reason why the DIP was 
rejected.

The last reply I was able to find, regarding this issue, was 
about logs not showing the correct file or number was a 
'nothing-burger', I can not disagree more.

Anyway, all these silent bugs are not present in Adams 
implementation.
They end up as errors, as they, IMHO should (implicit conversion 
to a GC string being another option).
Oct 23 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2023 1:34 AM, Juraj wrote:

 Sorry for being repetitive, but as you made an implementation only after the
DIP 
 was rejected, I figured it would be beneficial to show some real examples.


Thank you for posting them. Consider some more examples:

```
import std.stdio;

void main()
{
     writefln("hello %d", "betty"); // compiles just fine (exception at runtime)
     writeln("hello %s", "betty");  // compiles and runs!
}
```

I've made many mistakes like that. (Sorry, Betty!) I bet a lot of people have. 
There's no problem fixing them, as it's pretty obvious when a format string is 
in the output.

None of them resulted in memory unsafe code, and why would they? The generated 
strings are still checked for memory safety like any other code.

The result isn't type unsafe, either. The tuple elements are checked for type 
safety just like any other arguments.

Of course, printf isn't 100% checkable for memory safety (though D's checks
plug 
most of those holes), so it's a bit unfair to blame DIP1027 for that. I did 
suggest that D's printf format checker could be enhanced to modify the
arguments 
to make it memory safe, but that elicited no interest.

The fundamental issue here is that format strings are typed as strings. That 
issue is not going away. It is transferable to any attempt to use tuples as 
function arguments. There's a strong desire to use tuples a lot more in D (by 
adding the ability for functions to return tuples). Placing too much weight on 
this complaint would seem to seriously cripple use of tuples.

The complaint is also transferable to mixins. After all, mixins can generate 
arguments that are incorrect. mixins take string arguments, too, and it is up
to 
the user of the mixin to ensure the string is formed properly.



 Anyway, all these silent bugs are not present in Adams implementation.


Adam strongly criticized my review of YAIDIP because that was not how his 
implementation worked. I spent several hours studying YAIDIP, and can't help 
being annoyed at the waste of time. I don't know how his implementation works, 
because there is no specification for it.

I await Adam writing a specification for it so I can review it.
Oct 23 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 23 October 2023 at 19:25:35 UTC, Walter Bright wrote:

 Adam strongly criticized my review of YAIDIP because that was 
 not how his implementation worked.


Not true. I criticized your review of YAIDIP because you were 
wrong about what YAIDIP said.

I then implemented YAIDIP, exactly as written, to clear up 
further misconceptions:

https://github.com/dlang/dmd/pull/15714

This PR is *still* YAIDIP implemented, exactly as written.

Though YAIDIP has its own flaws, including ones fixed in DIP1036, 
so I then adjusted the patch to fix those in a *separate* PR 
(15715), which is a better proposal.

I'm no longer interested in YAIDIP, I consider it dead. Its flaws 
are addressed in PR 15715 (a very minor modification to the 
previous patch). But the document and PR are still there to be 
examined anyway.


 I don't know how his implementation works, because there is no 
 specification for it.


The newest one's implementation is crystal clear, fully 
operational in a trivial patch to the compiler, along with 
several usage examples.

You're just making excuses now.
Oct 23 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 23 October 2023 at 20:37:00 UTC, Adam D Ruppe wrote:

 On Monday, 23 October 2023 at 19:25:35 UTC, Walter Bright wrote:

 [...]


 Not true. I criticized your review of YAIDIP because you were 
 wrong about what YAIDIP said.

 [...]



For others reading, here's the new one, Dip1036e :

https://github.com/dlang/dmd/pull/15715
Oct 23 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2023 10:01 PM, Imperatorn wrote:

 For others reading, here's the new one, Dip1036e :
 
 https://github.com/dlang/dmd/pull/15715


It's not a specification, it's a code PR.
Oct 24 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 24 October 2023 at 18:15:25 UTC, Walter Bright wrote:

 On 10/23/2023 10:01 PM, Imperatorn wrote:

 For others reading, here's the new one, Dip1036e :
 
 https://github.com/dlang/dmd/pull/15715


 It's not a specification, it's a code PR.


Just posting the link for those who don't know what's being 
discussed
Oct 24 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2023 1:37 PM, Adam D Ruppe wrote:

 Not true. I criticized your review of YAIDIP because you were wrong about what 
 YAIDIP said.


Since you abandoned it, there's no point in rebuttal.



 I don't know how his implementation works, because there is no specification 
 for it.


 The newest one's implementation is crystal clear, fully operational in a
trivial 
 patch to the compiler, along with several usage examples.


Please write a specification for it. There's not even a grammar for it, and the 
pull request has no test cases.

When there is one, I will review it.
Oct 24 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 24 October 2023 at 18:13:58 UTC, Walter Bright wrote:

 Please write a specification for it. There's not even a grammar 
 for it, and the pull request has no test cases.


Being able to see what the tuple is is much more educational than 
a lot of handwavy documentation. It removes all the mystery. A 
lot of people seem to assume that tuple generation is far more 
complicated than it is.
Oct 24 2023
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here 
 it is:

 https://github.com/dlang/dmd/pull/15722


s/i/format!
Oct 22 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here 
 it is:

 https://github.com/dlang/dmd/pull/15722


 s/i/format!


😁
Oct 22 2023
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here 
 it is:

 https://github.com/dlang/dmd/pull/15722


 s/i/format!


You forgot /g 😎
Oct 22 2023
parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 22 October 2023 at 19:51:17 UTC, Imperatorn wrote:

 On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright 
 wrote:

 Several people asked for an implementation to try out, so 
 here it is:

 https://github.com/dlang/dmd/pull/15722


 s/i/format!


 You forgot /g 😎


I forgot to mention that baking a feature that works just fine as 
a library in the language is a terrible idea.
Oct 24 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 24 October 2023 at 11:32:19 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 19:51:17 UTC, Imperatorn wrote:

 On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright 
 wrote:

 Several people asked for an implementation to try out, so 
 here it is:

 https://github.com/dlang/dmd/pull/15722


 s/i/format!


 You forgot /g 😎


 I forgot to mention that baking a feature that works just fine 
 as a library in the language is a terrible idea.


Does that mean any string interpolation solution should be solved 
as a library or just some of them?
Oct 24 2023
prev sibling next sibling parent duckchess <duckchess chess.com> writes:
On Tuesday, 24 October 2023 at 11:32:19 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 19:51:17 UTC, Imperatorn wrote:

 On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright 
 wrote:

 Several people asked for an implementation to try out, so 
 here it is:

 https://github.com/dlang/dmd/pull/15722


 s/i/format!


 You forgot /g 😎


 I forgot to mention that baking a feature that works just fine 
 as a library in the language is a terrible idea.


Exactly. But the language currently lacks the tools to do it in a 
nice way. we'd need something like this:

```d
template FOO(T) {
     alias FOO = T;
}
pragma(msg, FOO!int); // FOO decays into int

template BAR(alias T) {
     enum BAR = T;
}
pragma(msg, BAR!42); // BAR decays into 42

// proposed new feature: automatic string mixins
template BAZ(string T) {
     mixin BAZ = T;
}
pragma(sg, BAZ!"42, 42"); // BAZ should decays into pragma(msg, 
mixin("42, 42"));
// note: mixin("42, 42") curently doesn't work either. but it 
sould be made to work so it becomes:
// pragma(msg, 42, 42);

```

would this be possible to implement in the compiler?
Oct 24 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2023 4:32 AM, deadalnix wrote:

 I forgot to mention that baking a feature that works just fine as a library in 
 the language is a terrible idea.


True, but can it work as a library feature? Consider:

```
void test {
     int x = 78;
     func("x = $x");
}
```

In order for this to work, `x` has to undergo semantic analysis in the context 
of `test`. But it will get evaluated in the context of `func`, which would be 
incorrect.

The way to evaluate it in the context of `test` is to have `func` return a 
string and then apply a mixin. (There may be another way, but I can't think of
one.)

So, it would have to be written as:

```
     mixin(func("x = $x");
```

As a general rule, things that are used a lot can benefit from syntactic sugar, 
which is what DIP1027 provides.
Oct 24 2023
prev sibling parent Andrea Fontana <nospam example.org> writes:
On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:

 On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:

 Several people asked for an implementation to try out, so here 
 it is:

 https://github.com/dlang/dmd/pull/15722


 s/i/format!


```eject_pods(format"medbay$area_formatd", 
pod_to_drop_formatd);```

:)
Oct 22 2023