Binding contexts

[Timon Gehr via Digitalmars-d]

On 03.06.2016 18:36, Vladimir Panteleev wrote:
> On Friday, 3 June 2016 at 15:14:59 UTC, Timon Gehr wrote:
>>> https://github.com/dlang/dmd/pull/3361
>>> ...
>>
>> Interesting. Not sure about this. It seems it should work by analogy
>> with this:
>>
>> struct Test{
>>     int x=2;
>>     int foo(){ return x; }
>>     int call(alias a)(){ return a(); }
>>     pragma(msg,Test().call!foo);
>> }
>>
>> So I have implemented it. :)
>> https://github.com/tgehr/d-compiler/commit/ea7cdcc43dce8fd05b64b872e83ac28905b81dff
>>
>
> Hah, very cool :)
> ...

There's also this commit:
https://github.com/tgehr/d-compiler/commit/dc34b0b2529300a05fc00c0fc54d006bc96aa790

I noticed during your nice talk at DConf that I lacked support for lazy 
void parameters. This was fixed before the end of the talk. :)

>> However, there are some funny cases:
>>
>> struct A{
>>     int x;
>>     this(int x){ this.x=x; }
>>     int fun(){ return x;}
>>     int[] caller(T)(T t){
>>         int[] r;
>>         r~=T.fun();
>>         r~=(x++,t).fun();
>>         return r;
>>     }
>> }
>> struct B{
>>     alias fun = A.fun;
>> }
>>
>> pragma(msg, A(2).caller(B())); // [2,3]
>> pragma(msg, A(2).caller(A(10))); // [2,10]
>>
>> I.e. this code exhibits 'special' behaviour when the passed type is A.
>
> Maybe when I don't follow your argument, but it acts exactly as before
> when the passed type is A. ...

You are right, the behavior in question is not actually newly 
introduced. It's probably fine.

>> It must work by default, otherwise libraries can accidentally not
>> support it. I think it should just be inferred. I.e. if the template
>> instance needs access to the context, that requirement is propagated
>> to the caller, otherwise it isn't. The arguments that Kenji raises
>> against it seem to be DMD-specific, no?
>
> I must admit that I don't fully understand Kenji's explanation either.
> ...

Well, one argument seems to be that it is clearly possible to create 
somewhat weird situations if both inference and introspection happen at 
the same time. I handle all forward reference issues in an unified 
manner and therefore shouldn't run into major problems there.

>> I share it. The main limitation that needs fixing is capture of
>> multiple contexts. Unfortunately I have not gotten around to
>> implementing multiple contexts and context inference myself so far.
>
> Yeah, multiple contexts would be the crown jewel. I've been told,
> though, that the idea that things can have at most one context pointer
> is very deeply rooted into DMD. I think Walter Bright is also not a fan
> of the idea, if I understand correctly his main counter-argument is that
> for untemplated function pointers, when it has 0 contexts it's just a
> function pointer, when it has 1 context it's a delegate, when it has 2
> or more contexts, it's something else, what is it - how would you
> describe its type in language syntax?
>

It should still be a delegate. One context pointer suffices to address 
an arbitrary amount of data. We can just put a void*[n] with all 
remaining contexts inside the stack frame context.