`with` across function calls

[luckoverthere]

On Saturday, 19 January 2019 at 00:23:40 UTC, Nicholas Wilson 
wrote:
> On Friday, 18 January 2019 at 23:10:12 UTC, luckoverthere wrote:
>> On Friday, 18 January 2019 at 12:35:33 UTC, Nicholas Wilson 
>> wrote:
>>> q.enqueue!(f!(args))(arg_set1)(arg_set2);
>>>
>>> and the function within that needs `g` also needs `f`. The 
>>> expected usage is a whole lot of those calls all in one spot 
>>> with different `f`, `args`, `arg_set1`, `arg_set2` I really 
>>> don't want the user to have to repeat themselves anymore than 
>>> absolutely necessary.
>>
>> Isn't that the usual argument between using globals and not 
>> using them. It's a lot cleaner when using them, especially 
>> when it is some sort of data that needs to be passed to 
>> basically everything. But then you deal with the joys of 
>> globals.
>>
>> The use case for this is very narrow and the implementation is 
>> error prone.
>
> How do you know? I don't think it would be all that much more 
> complex than default arguments.

Default arguments don't change. In every context you look the 
function will behave the same way no matter where it is used. 
It'd be no different than adding an overload. With the with 
statement though, it'd not obvious where it might be used.

>> Having to go through and check functions to see which one's 
>> have altered behavior in a with statement isn't going to be 
>> fun.
>
> grep?  ^f? Also again, this isn't any worse than default 
> arguments.

You can't grep or find because the with statement removes it all 
entirely. That's sort of my point, you'd have to look at every 
function definition to see which ones get modified. At the call 
point you have no indication that the behavior is different. It's 
not the same as default arguments. You can tell at call point the 
number of parameters being passed to the function, and the 
behavior is the same everywhere that function is used. The two 
are absolutely different. The behavior of your suggested feature 
changes based on scope and context.

>> In the general case this doesn't make any sense,
>
> That is a bold claim: have a watch of Martin's keynote.

Why did you split my sentence in half? You agree with me in the 
reply to the example given with this sentence.

>> It'd be the very specific case of an API that needs to pass 
>> around some sort of state-like object a bunch of functions.
>>
>> The rationale is also pretty weak, you want reduce the number 
>> of arguments you have to pass in this one specific use case.
>
> The case of dealing with contexts is hardly unique to me.

Contexts is the specific use case, not you.

>> Honestly from the looks of that function call, it might be 
>> better just finding a better way of implementing whatever it 
>> is you are trying to implement.
>
> Its globals or this, and I'd rather not use globals. More 
> specifically, in
>
> q.enqueue!(f!(args))(arg_set1)(arg_set2);
>
> arg_set1 is the shape of the kernel dispatch and (if `q` is an 
> out of order Queue) the dependency list of enqueue and other 
> things that need to finish before the (user supplied) kernel 
> `f` executes.
>
> arg_set2 relates to Parameters!f
>
> there is no logical room to put it, it belongs in neither of 
> the two argument lists.

Even if you were to use a global or this new proposed "with" 
feature, that function call is atrocious. That is what I meant by 
finding a better way of implementing what you are trying to do.