March 18, 2019
On Monday, 18 March 2019 at 16:48:59 UTC, H. S. Teoh wrote:
> 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 `$$`?
>
\$ would be consistent with normal C and D quoting rules. $$ not so much.

March 19, 2019
On Monday, 18 March 2019 at 13:05:37 UTC, Steven Schveighoffer wrote:
> If you look at the PR that he created, it's super-simple. It uses the already existing parser/lexer in the front end.

Hmm... the pr seemingly doesn't support full nested language: the string is lexed as a normal double quoted string. This is different from, say, javascript, where interpolated strings support nesting without escapes and thus can't be lexed without parsing all their content.

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

If they supported full nested language, but they don't. So I see no reason to assume that they should be difficult to parse.
March 19, 2019
On Sunday, 17 March 2019 at 10:40:28 UTC, Nick Treleaven wrote:
> On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
>>     text("a is", a, ", b is ", b, " and the sum is: ", a + b)
>>
>> Ironically, his example had a mistake, but it was hard to
>> notice.
>
> Maybe he wrote that on the forum. In a text editor syntax highlighting would make the mistake clearer, but it can still happen. The interpolated syntax is definitely clearer.

Yep. At the time I pointed out I wouldn't have made the same mistake in Emacs.

March 19, 2019
On Tuesday, 19 March 2019 at 10:11:27 UTC, Atila Neves wrote:
> On Sunday, 17 March 2019 at 10:40:28 UTC, Nick Treleaven wrote:
>> On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
>>>     text("a is", a, ", b is ", b, " and the sum is: ", a + b)
>>>
>>> Ironically, his example had a mistake, but it was hard to
>>> notice.
>>
>> Maybe he wrote that on the forum. In a text editor syntax highlighting would make the mistake clearer, but it can still happen. The interpolated syntax is definitely clearer.
>
> Yep. At the time I pointed out I wouldn't have made the same mistake in Emacs.

For me, even with syntax highlighting it's still hard to spot the mistake. So it's good to get your perspective which is that you know syntax highlighting would have prevented this mistake in your case.

Off topic, I enjoyed your talk on emacs, I'm a long time user myself.

March 19, 2019
On Tuesday, 19 March 2019 at 08:13:16 UTC, Kagamin wrote:
> On Monday, 18 March 2019 at 13:05:37 UTC, Steven Schveighoffer wrote:
>> If you look at the PR that he created, it's super-simple. It uses the already existing parser/lexer in the front end.
>
> Hmm... the pr seemingly doesn't support full nested language: the string is lexed as a normal double quoted string. This is different from, say, javascript, where interpolated strings support nesting without escapes and thus can't be lexed without parsing all their content.
>
>> The point he's making is that we'd have to DUPLICATE that for a library solution.
>
> If they supported full nested language, but they don't. So I see no reason to assume that they should be difficult to parse.

Your absolutely right here. Thanks for taking time to look at the code by the way. The current implementation isn't finished. I just wanted to start out with something easy to explore the feature. So today the language solution has the limitation that parens inside the code need to be balanced. But that limitation can be fixed with a bit more work. I just need to combine the current 2 pass interpolation logic into one-pass, but that would require some extra changes in the parse code and at this stage I wanted to minimize turmoil. So it's a temporary compromise. The final solution wouldn't have this limitation.

1 2 3
Next ›   Last »