On Sunday, 17 March 2019 at 16:50:13 UTC, Jonathan Marler wrote:
> On Sunday, 17 March 2019 at 14:20:20 UTC, Rubn wrote:
>> Seems you've done everything but write a DIP, I don't really see why this feature should be exempt from the process. Even if the process isn't the greatest, that isn't reason enough for it to circumvent it.
>
> I'll have to disagree with you here. I'm not sure if you've written a DIP but I have.
>
> I started DIP 1011 about 2 years ago.  After about a year, it was forwarded to W&A and I got a response from Andrei that contained a fair number of errors.  To me it seemed that he didn't take enough time to read/understand the proposal (I've heard this isn't the first time this has happened). The proposal itself is pretty simple, but the ramifications of the change weren't so clear.  A discussion between the leadership and the points they had questions about would have been very helpful early on to know where to put effort into researching the proposal.  However, that's not how the DIP process is written to work.  After Andrei's response I attempted to discuss their concerns but everything was filtered through the DIP manager Michael Parker and they never responded to my comments and questions.  We left off with them providing an example library implementation asking me to comment on it. I did so, explaining that their example was incorrect and had little bearing on the DIP itself as they had implemented different semantics than what the DIP was proposing, but then they never responded.  That was about a year ago, and the DIP is still considered to be in "Formal Review".

That does smack of my experience with DIP1016. I've added DIP1011 to the list of DIP related stuff for the dconf AGM[1]

> In my opinion the DIP process is broken.  I don't want to introduce a potentially good feature for D into a system where I believe it will actually harm the chances for the feature rather then help them.  If the process is fixed however, I will gladly create a DIP and would look forward to really hashing out the feature and seeing how it could best be implemented.

I hope to get the DIP process fixed at the AGM, but for making progress on the topic of interpolated strings it would really help if you have a draft (or steal/polish that one from the DIP PR queue) so that we have something concrete to discuss (i.e. get (part of) a community round done).

> I believe if I use the current DIP system as it exists to introduce it, it will actually make it more likely to fail than if I didn't write a DIP at all at this point.
>
> Please understand, I don't shy away from good, robust work and research.  I'm a highly motivated mathematician, who loves optimizing and finding elegant solutions.  That's what I like spending my time on.  Researching language proposals is exactly the type of work I like to do. I spend alot of time reading and researching other languages and the features they bring to the table. I would very much enjoy contributing to a DIP process that fosters collaboration and feedback that results in more consensus and communal understanding.

This really does highlight the problems with organisation we really want to be getting all the best work you can provide and if that is bottlenecked on the current DIP process then we definitely need to look at why it is and how to fix it.

[1]: http://dconf.org/2019/talks/agm.html

On Sunday, 17 March 2019 at 14:01:36 UTC, ag0aep6g wrote:
> Either way, you likely got yourself an HTML injection.
>
> That might be the crux of string interpolation: It looks nice in simple examples, but is it still nice when you need to encode your variables for the output?

One way to deal with these cases would be to have an alternate string interpolation syntax for format string, eg:

    fi"SELECT $field FROM $table"

is lowered to

    "SELECT %s FROM %s", field, table

Other alternatives have been suggested (eg interpolation creating delegates that can be passed at compile time), but I think the above solution is the most KISS and elegant.

It encourages robust design, where the only argument parsed is the first one and every other argument is sanitized by default.

On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
> https://github.com/dlang/dmd/pull/7988

By the way, quick question, how does the PR handle this case?

    i"$a $b" ~ i$"c $d"

On Sunday, 17 March 2019 at 18:32:55 UTC, Jonathan Marler wrote:
>>> foreach (i; 0 .. 10)
>>> {
>>>     mixin(interp(`$( i ~ ")" ) entry $(array[i])`));
>>> }
>>
>> That doesn't look nice, does it?
>
> Not sure if you realize this but you're criticizing how the library solution looks, which was one of my main points :)

I mean $( i ~ ")

> And it's a contrived example to demonstrate an example that would be hard for a library to parse.

It's hard to parse even for a library? That sounds bad. Is it required to be hard to parse?

On 3/18/19 8:12 AM, Kagamin wrote:
> On Sunday, 17 March 2019 at 18:32:55 UTC, Jonathan Marler wrote:
>>>> foreach (i; 0 .. 10)
>>>> {
>>>>     mixin(interp(`$( i ~ ")" ) entry $(array[i])`));
>>>> }
>>>
>>> That doesn't look nice, does it?
>>
>> Not sure if you realize this but you're criticizing how the library solution looks, which was one of my main points :)
> 
> I mean $( i ~ ")

Yeah, you could write it I think just like the language solution:

mixin(interp(`$(i)) entry $(array[i])`));

You'd still have to deal with the stray parentheses as a string, but I'm sure there are other expressions inside the escapes that are more likely to be in the wild which would require a lexer/parser. It may not be a full one, though, we don't need to make AST out of it.

> 
>> And it's a contrived example to demonstrate an example that would be hard for a library to parse.
> 
> It's hard to parse even for a library? That sounds bad. Is it required to be hard to parse?

If you look at the PR that he created, it's super-simple. It uses the already existing parser/lexer in the front end.

The point he's making is that we'd have to DUPLICATE that for a library solution.

-Steve

On 3/18/19 5:07 AM, Olivier FAURE wrote:
> On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
>> https://github.com/dlang/dmd/pull/7988
> 
> By the way, quick question, how does the PR handle this case?
> 
>      i"$a $b" ~ i$"c $d"

Hm... it would be good for the feature to handle this (and treat it as i"$a $b$c $d". I'm assuming that i$"c is a typo and you meant i"$c.

-Steve

On Monday, 18 March 2019 at 12:12:12 UTC, Kagamin wrote:
> On Sunday, 17 March 2019 at 18:32:55 UTC, Jonathan Marler wrote:
>>>> foreach (i; 0 .. 10)
>>>> {
>>>>     mixin(interp(`$( i ~ ")" ) entry $(array[i])`));
>>>> }
>>>
>>> That doesn't look nice, does it?
>>
>> Not sure if you realize this but you're criticizing how the library solution looks, which was one of my main points :)
>
> I mean $( i ~ ")
>

Yeah, like I said you wouldn't write that in real code. It's an example to demonstrate something that would be hard for a library to parse.

>> And it's a contrived example to demonstrate an example that would be hard for a library to parse.
>
> It's hard to parse even for a library? That sounds bad.

Yeah it is bad. Hence why I listed it as a CON of the library solution. But it's very easy if it's implemented in the compiler since is has access to the parser.

> Is it required to be hard to parse?

The problem is knowing when right-paren ')' characters are supposed to be a part of the code or when they are being used to end the code. For the parser this is easy to determine, but without it, you now have to go through all the tokens/grammar nodes to see where these right-paren characters can appear (i.e. string literals, function calls, templates, etc). You could implement a simple heuristic where you support as many right-paren in your code as there are left-paren characters, which will get you most of the way there, but now you've put an arbitrary limitation on the code that can appear inside these interpolated expressions. The point is, a language solution doesn't have this problem. It doesn't need to put any limitations on the code, and it doesn't have to come up with a mechanism to know when paren characters are or are not apart of the code. This problem is non-existent for an implementation inside the compiler.

On 18.03.19 00:21, kinke wrote:
> As long as the embedded expressions are always separated by a string literal in the resulting tuple, incl. an empty one (`i"$(a)$(b)"` => `"", a, "", b`), these embedded expressions can be identified (and appropriately transformed etc.) by an odd index.

I see. Like this:


    void writelnToHTML(S ...)(S stuff)
    {
        static foreach (i, thing; stuff)
        {
            if (i % 2 == 0) write(thing);
            else write(thing.toHTML);
        }
        writeln;
    }
    writelnToHTML(i`<html><body>
        <title>$(title)</title>
        <name>$(name)</name><age>$(age)</age>
        <a href="$(link)">$(linkName)</a>
        </body></html>
    `);

That's pretty good. It's not quite foolproof; one might put arguments before/after the interpolating, messing up the arrangement. But other than that it seems nice.

On Monday, 18 March 2019 at 09:07:26 UTC, Olivier FAURE wrote:
> On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
>> https://github.com/dlang/dmd/pull/7988
>
> By the way, quick question, how does the PR handle this case?
>
>     i"$a $b" ~ i$"c $d"

Also, recursive use of interpolated strings. Does this work or fail with a compiler error like "can't find symbol c":

int a = 2, b = 5;
enum code = text(i"mixin(\"int c = $(a + b)\"); writeln(i\"a = $a, b = $b, c = $c\");");
mixin(code);

On Mon, Mar 18, 2019 at 04:30:26PM +0000, Meta via Digitalmars-d wrote:
> On Monday, 18 March 2019 at 09:07:26 UTC, Olivier FAURE wrote:
> > On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
> > > https://github.com/dlang/dmd/pull/7988
> > 
> > By the way, quick question, how does the PR handle this case?
> > 
> >     i"$a $b" ~ i$"c $d"
> 
> Also, recursive use of interpolated strings. Does this work or fail with a compiler error like "can't find symbol c":
> 
> int a = 2, b = 5;
> enum code = text(i"mixin(\"int c = $(a + b)\"); writeln(i\"a = $a, b =
> $b, c = $c\");");
> mixin(code);
[...]

I'd expect you'd have to escape the $ in the nested interpolated string. I forgot what the escape was, perhaps `$$`?


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin