On Tuesday, 17 December 2019 at 09:13:52 UTC, Walter Bright wrote:
> On 12/16/2019 9:31 AM, Steven Schveighoffer wrote:
> I know supporting iq tokens is not complicated. It's just unnecessary. We can always add it later as necessary without breaking things.

Well they would be a tremendous addition for metaprogramming facilities that are using mixins, since they will increase by a lot mixin code readability.

Best regards,
Alexandru.

On Tuesday, 17 December 2019 at 09:20:06 UTC, Jacob Carlborg wrote:
> On Monday, 16 December 2019 at 12:55:17 UTC, Patrick Schluter wrote:
>
>> Yes, probably. The issue I had with the transformation as string is what should the code below print?
>>
>> import fn;
>>
>> int a, b = 20;
>>
>> string inter = i"$(a+b)";
>>
>> for(a=0; a<10; a++)
>>    fn(inter);
>>
>>  ---
>>  module fn;
>>
>>  void fn(string s)
>>  {
>>    writef(s);
>>  }
>>
>> prints
>> 202020202020202020
>>
>> or
>>
>> 212223242526272829
>>
>> and that's the difference between CT evaluation and RT evaluation.
>
> It's difficult to say as your code doesn't compile. As it's written the code will fail to compile because you cannot have a for-loop at module scope. The line where `inter` is declared would fail to compile as well because `a` and `b` cannot be read at compile time. I don't see how that would be any different compared to this code:
>
> module foo;
> int a, b = 20;
> int c = a + b; // fails to compile as well
>
> If all of this code would be wrapped in a function, then it would successfully compile. `inter` would be evaluated to "20" and the code would print:
>
> 20202020202020202020
>
> I don't see how it would behave any differently than if you replaced `string` with `int` and removed `i"$"`.
>
> For the result to be `212223242526272829` `i"$(a+b)"` would need to be a macro.
>
Yes, and that was the point of the exercice. Transforming the interpolated "string" into a string evaluates the values of the variables at the moment of that transformation. From then on, there is no interpolation possible as it a simple string.
I suppose that what aliak leant in his comments was that the string then could still be used for interpolation.

hypothetic scenario of what I interpreted what aliak wanted (and it won't compile, it's just for illustration)

int apple;
...
  string my_is = i"apple=${apple}";

...

  apple = 36;
  writeln(my_is);

would print "apple=36"

with this DIP, when you do this

int apple;
...
  string my_is = i"apple=${apple}".format;

...

  apple = 36;
  writeln(my_is);

will print "apple=0" because my_is will contain the string "apple=0"

The basic thing here is what Walter said above:

interpolated strings are not string literals, they can't be. They are code.

On Monday, 16 December 2019 at 09:34:00 UTC, Walter Bright wrote:
> On 12/15/2019 2:33 AM, Alexandru Ermicioi wrote:
>> On Sunday, 15 December 2019 at 04:20:59 UTC, Walter Bright wrote:
>>> object.d is getting more and more bloated over time. This is not a solution to imports, and is not a good trend.
>> 
>> A bit other topic, but this can be fixed by splitting object.d in multiple modules in same package, and auto import that package, just like how it is done in java with java.lang package.
>> 
>> For example, object.d could be split into several modules under d.lang package.
>> 
>> This will also clean existing bloatware, since we could move typeinfo, object definition and other stuff into separated modules.
>
> The reality is that compilation time is more proportional to the number of files than the size of the files. Splitting up object.d into multiple modules that must still be loaded will make things slower.

I doubt someone will complain, about splitting object module into smaller packages based on performance reasons, and certainly splitting object.d won't trigger tens of files now. Though as said before it will increase readability. I personally can live with few more miliseconds for compilation time if readability is increased in druntime/phobos.

Best regards,
Alexandru.

On Tuesday, 17 December 2019 at 06:15:03 UTC, mipri wrote:
> On Tuesday, 17 December 2019 at 05:37:53 UTC, Jab wrote:
>> On Monday, 16 December 2019 at 22:48:30 UTC, mipri wrote:
>>> Well-written database code in these languages is therefore
>>> written as if string interpolation is not a feature of the
>>> language:
>>>
>>>   $db->query("INSERT INTO names VALUES (?)", "Bob");
>>
>> This would push the complexity onto the query implementation.
>> As now it has to be able to parse the string.
>
> What?
>
> This is how query implementations work right now. Yes, the DBMS
> needs to be able to parse SQL.
>
> Have you spoken to a database without an ORM before?

Sorry I forgot to go back and edit this after I changed it. It be more complicated as instead of just using "?" it would have to be able to know about and parse printf-style formatting.

>>>   printf(gettext("Hello, %s!"), name);
>>
>> This would usually be a warning/error in C/C++ compilers as you
>> aren't using a constant string for the format.
>
> https://www.gnu.org/software/libc/manual/html_node/Translation-with-gettext.html

Ok? I've literally never seen this function used in any software. Probably for a good reason.

>> Ultimately this doesn't really help with localization either.
>> What if you need to change the order? Languages have different
>> ways of formatting. Maybe not the best example, but say you
>> have "$year-$month-$day", but in a different location it is
>> more common to do "$month-$day-$year". The gettext() can't do
>> anything about that, cause it'll always have to be "%d-%d-%d",
>> it can't rearrange the order.
>
> "This doesn't help."
>
> is not supported by
>
> "I can think of a specific objection that internationalization
> libraries definitely have specific support for."
>
> OK, what about all the other cases? What if you format a date
> using a locale-aware formatter and then just make that one of
> the inputs to your format string, rather than the individual
> components of the date?
>
> It's still a better localization story than normal string
> interpolation, which just has to be ripped out. You can't fix
> normal string interpolation by using a locale-aware date
> formatter, because the resulting string is still not something
> you can look up in a translation database.

The date was just illustrating the problem. Sentence structures in languages change, the order isn't the same in every language. If your using printf, localization probably doesn't matter. Your going to have more problems with localization using printf. If localization matters, there's better methods for achieving it than using printf and something like gettext().

>> What happens if you want to implement your own type and pass it
>> in? The DIP doesn't mention it at all.
>
> If you're passing the i"" string to a D routine like format()
> or writef(), then you get all the custom formatting that you
> want, as normal. If you're passing it to a C routine or
> something else, obviously you have to provide types that the C
> routine can understand.

That's the problem. This is intended to be used for printf() as well, but to do that you have to do something like this then:

    printf(i"blah blah ${myType.toString.toStringz}");

It becomes useless here. You are going to have to use something else anyways because it starts to fall apart when you try and support an old method like printf.

On 2019-12-17 11:14, Patrick Schluter wrote:

> Yes, and that was the point of the exercice. Transforming the interpolated "string" into a string evaluates the values of the variables at the moment of that transformation. From then on, there is no interpolation possible as it a simple string.
> I suppose that what aliak leant in his comments was that the string then could still be used for interpolation.
> 
> hypothetic scenario of what I interpreted what aliak wanted (and it won't compile, it's just for illustration)
> 
> int apple;
> ...
>    string my_is = i"apple=${apple}";
> 
> ...
> 
>    apple = 36;
>    writeln(my_is);
> 
> would print "apple=36"
> 
> with this DIP, when you do this
> 
> int apple;
> ...
>    string my_is = i"apple=${apple}".format;
> 
> ...
> 
>    apple = 36;
>    writeln(my_is);
> 
> will print "apple=0" because my_is will contain the string "apple=0"

I don't see how lowering to a tuple will change anything. It's not possible to store expressions. If you have the expression `3 + 4` than that will be evaluated and `7` is what's left. Unless the expression is wrapped in a lambda.

> The basic thing here is what Walter said above:
> 
> interpolated strings are not string literals, they can't be. They are code.

Of course they can. They can be whatever we decide them to be.

-- 
/Jacob Carlborg

On 12/17/19 5:14 AM, Patrick Schluter wrote:
> Yes, and that was the point of the exercice. Transforming the interpolated "string" into a string evaluates the values of the variables at the moment of that transformation. From then on, there is no interpolation possible as it a simple string.
> I suppose that what aliak leant in his comments was that the string then could still be used for interpolation.
> 
> hypothetic scenario of what I interpreted what aliak wanted (and it won't compile, it's just for illustration)
> 
> int apple;
> ....
>    string my_is = i"apple=${apple}";
> 
> ....
> 
>    apple = 36;
>    writeln(my_is);
> 
> would print "apple=36"
> 
> with this DIP, when you do this
> 
> int apple;
> ....
>    string my_is = i"apple=${apple}".format;
> 
> ....
> 
>    apple = 36;
>    writeln(my_is);
> 
> will print "apple=0" because my_is will contain the string "apple=0"
> 
> The basic thing here is what Walter said above:
> 
> interpolated strings are not string literals, they can't be. They are code.

Wow, I don't think that the first item can be done with the DIP. But that would be really cool (I'm thinking of periodic logging features).

I tried this, still prints 5 apples and 6 bananas:

    int apples = 5;
    int bananas = 6;
    auto as = AliasSeq!("%s apples and %s bananas", apples, bananas); // essentially what an interpolated string will evaluate to
    writefln(as);
    ++apples;
    ++bananas;
    writefln(as);

It seems that AliasSeq doesn't store the alias (ironically), but the value of the expression at the time.

Is there a way that this could work? I mean, aside from storing lambdas for everything?

-Steve

On Tuesday, 17 December 2019 at 16:43:32 UTC, Jacob Carlborg wrote:
> On 2019-12-17 11:14, Patrick Schluter wrote:
>
>> Yes, and that was the point of the exercice. Transforming the interpolated "string" into a string evaluates the values of the variables at the moment of that transformation. From then on, there is no interpolation possible as it a simple string.
>> I suppose that what aliak leant in his comments was that the string then could still be used for interpolation.
>> 
>> hypothetic scenario of what I interpreted what aliak wanted (and it won't compile, it's just for illustration)
>> 
>> int apple;
>> ...
>>    string my_is = i"apple=${apple}";
>> 
>> ...
>> 
>>    apple = 36;
>>    writeln(my_is);
>> 
>> would print "apple=36"
>> 
>> with this DIP, when you do this
>> 
>> int apple;
>> ...
>>    string my_is = i"apple=${apple}".format;
>> 
>> ...
>> 
>>    apple = 36;
>>    writeln(my_is);
>> 
>> will print "apple=0" because my_is will contain the string "apple=0"
>
> I don't see how lowering to a tuple will change anything. It's not possible to store expressions. If you have the expression `3 + 4` than that will be evaluated and `7` is what's left. Unless the expression is wrapped in a lambda.

Which was my point. An interpolated string cannot be stored in a simple string as some people requested in the thread before (not you). It is only feasible if the istring is evaluated at runtime with an interpreter who knows the current values of the variables used. Interpreted languages like python, perl, javascript etc. might get away with it but compiled languages have to transform it in its code representation.

>
>> The basic thing here is what Walter said above:
>> 
>> interpolated strings are not string literals, they can't be. They are code.
>
> Of course they can. They can be whatever we decide them to be.

On 17.12.19 18:12, Steven Schveighoffer wrote:
> I tried this, still prints 5 apples and 6 bananas:
> 
>      int apples = 5;
>      int bananas = 6;
>      auto as = AliasSeq!("%s apples and %s bananas", apples, bananas); // essentially what an interpolated string will evaluate to
>      writefln(as);
>      ++apples;
>      ++bananas;
>      writefln(as);
> 
> It seems that AliasSeq doesn't store the alias (ironically), but the value of the expression at the time.
> 
> Is there a way that this could work? I mean, aside from storing lambdas for everything?

alias as = AliasSeq!("%s apples and %s bananas", apples, bananas);

On Tue, Dec 17, 2019 at 05:37:53AM +0000, Jab via Digitalmars-d wrote:
> On Monday, 16 December 2019 at 22:48:30 UTC, mipri wrote:
[...]
> >   $db->query("INSERT INTO names VALUES (?)", "Bob");
> 
> This would push the complexity onto the query implementation. As now it has to be able to parse the string.
[...]

The database engine *already* does this.  It's standard SQL syntax, and you don't have to write a single bit of code to make this work, just hand it off to the database backend and your job is done.


T

-- 
"640K ought to be enough" -- Bill G. (allegedly), 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.

On 12/17/19 12:19 PM, ag0aep6g wrote:
> On 17.12.19 18:12, Steven Schveighoffer wrote:

>> Is there a way that this could work? I mean, aside from storing lambdas for everything?
> 
> alias as = AliasSeq!("%s apples and %s bananas", apples, bananas);

:facepalm:

Thanks!

That is pretty cool. Coupled with a logging function:


    import std.experimental.logger;
    int apples = 5;
    int bananas = 6;
    //equivalent to: alias msg = i"$apples apples and $bananas bananas";
    alias msg = AliasSeq!("%s apples and %s bananas", apples, bananas);
    logf(msg);
    ++apples;
    ++bananas;
    logf(msg);

This works pretty well, shows the filename/line numbers, and reevaluates the log message each time.

Another cool use case.

-Steve