On Thursday, 12 December 2019 at 22:02:22 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 12 December 2019 at 21:40:33 UTC, Paul Backus wrote:
>> Is there any actual difference between mixing in a bare expression vs. an immediately-called lambda function that evaluates to the same expression? Forcing string mixins to represent lambdas in particular seems needlessly restrictive.
>
> The idea is to prevent writing to variables outside the mixin. So, @pure and const params would perhaps be enough to enable that?

Why is that a desirable goal in the first place? The whole point of a string mixin is that it's the same as if you'd typed the code yourself. It's the tool you reach for when you need maximum expressive power, and nothing else will do.

If what you actually want is a pure const lambda, there's nothing stopping you from writing one and sticking your mixin inside it.

On Thursday, 12 December 2019 at 22:17:59 UTC, Paul Backus wrote:
> If what you actually want is a pure const lambda, there's nothing stopping you from writing one and sticking your mixin inside it.

Just basic software engineering. No external entity should be able to access anything in the calling context that has not been explicitly exported.

It does not scale well as it can lead to bugs that are hard to locate.

So, it is an attempt to mitigate the problematic "macro" aspect of mixins and make the construct hygenic.

On Thursday, 12 December 2019 at 22:25:25 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 12 December 2019 at 22:17:59 UTC, Paul Backus wrote:
>> If what you actually want is a pure const lambda, there's nothing stopping you from writing one and sticking your mixin inside it.
>
> Just basic software engineering. No external entity should be able to access anything in the calling context that has not been explicitly exported.
>
> It does not scale well as it can lead to bugs that are hard to locate.
>
> So, it is an attempt to mitigate the problematic "macro" aspect of mixins and make the construct hygenic.

I agree, which I why I try to use string mixins in my own code as little as possible.

Nevertheless, it is occasionally very useful to be able to do unhygienic macro-like things. If it were up to me, I'd add AST macros to D and use those, but as it is, string mixins are the only available tool for the job. I would very much prefer not to have that tool taken away, sharp though it may be.

On Thursday, 12 December 2019 at 23:13:42 UTC, Paul Backus wrote:
> only available tool for the job. I would very much prefer not to have that tool taken away, sharp though it may be.

Oh, I only meant it for the string-interpolation interface, not in general.

On Thursday, 12 December 2019 at 22:02:22 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 12 December 2019 at 21:40:33 UTC, Paul Backus wrote:
>> Is there any actual difference between mixing in a bare expression vs. an immediately-called lambda function that evaluates to the same expression? Forcing string mixins to represent lambdas in particular seems needlessly restrictive.
>
> The idea is to prevent writing to variables outside the mixin. So, @pure and const params would perhaps be enough to enable that?

So interpolate#"{foo++}" should fail to compile? As should interpolate#"{foo}" where foo is of a type with a non-const toString()?

I see what you're trying to do, but IMO there are too many cases where the outlined restrictions cause undue problems.

--
  Simen

On Friday, 13 December 2019 at 12:37:31 UTC, Simen Kjærås wrote:
> So interpolate#"{foo++}" should fail to compile? As should interpolate#"{foo}" where foo is of a type with a non-const toString()?

No, I don't think the first one would fail.

It would:

    mixin("pure_lambda(foo++)")

So similar to

   const tmp = foo++;
   pure_lambda(tmp);

non-const toString() would fail if interpolate builds a string, but not if it builds a tuple.

> I see what you're trying to do, but IMO there are too many cases where the outlined restrictions cause undue problems.

Well, it will not cause a problem for the tuple that Walter's DIP create. So it certainly is no worse than the proposed DIP?

On Thursday, 12 December 2019 at 14:28:52 UTC, jmh530 wrote:

> If it is anything like AST macros, then I wouldn't expect Walter to be that supportive of it...

I think one of the reasons AST macros are not liked and that this idea will not be liked either is because there's basically no visual indication on the calling side that some code will be mixed in.

--
/Jacob Carlborg

On Thursday, 12 December 2019 at 11:39:46 UTC, Ola Fosheim Grøstad wrote:

> This is getting close to AST macros... but you should be able to put constraint on the resulting AST.

I agree. Therefore I think it would be much better to implement AST macros. Yet again we have an issue that AST macros can solve but Walter and company prefers to have specialized features instead of generic ones.

--
/Jacob Carlborg

On Friday, 13 December 2019 at 13:17:24 UTC, Jacob Carlborg wrote:
> On Thursday, 12 December 2019 at 11:39:46 UTC, Ola Fosheim Grøstad wrote:
>
>> This is getting close to AST macros... but you should be able to put constraint on the resulting AST.
>
> I agree. Therefore I think it would be much better to implement AST macros.

Since D is not changing much anymore it could be the right time to introduce AST macros.

Although I think it should follow this route:

1. refactor the compiler so that as much as possible is done as lowerings
2. create a minimal IR that (1.) can lower to
3. implement the lowerings as AST macros to the IR
4. add AST macro features to the language

So it cannot happen over night...

On 14/12/2019 2:17 AM, Jacob Carlborg wrote:
> On Thursday, 12 December 2019 at 11:39:46 UTC, Ola Fosheim Grøstad wrote:
> 
>> This is getting close to AST macros... but you should be able to put constraint on the resulting AST.
> 
> I agree. Therefore I think it would be much better to implement AST macros. Yet again we have an issue that AST macros can solve but Walter and company prefers to have specialized features instead of generic ones.
> 
> -- 
> /Jacob Carlborg

I've talked about this before with async, but I'm partial towards having a specialized string like q"" that will always be mixed in i.e.

[handler.]async {
	<brace matched text>
}

expands to:

mixin(handler("<brace matched text>"));

Or something like that, with a default handler being available based upon scope.

It would be preferable to be able to lookup declarations available in the callee's scope to do reflection on it.