Re: CALL-ME vs. Callable

[Brandon Allbery]

I feel like you're focusing on the wrong thing somehow. The issue is not
that what nqp is doing is somehow wrong. The issue is that the thing it is
doing is necessarily an implementation detail, and as such should be
isolated from the language level and any failures/errors exposed as
language level instead of leaking implementation details the programmer
should not have to care about. The Perl 6 way to do this is to wrap it in a
role that is documented at language level; in this case, I don't think it
is necessary for that role to translate errors between levels (this often
is needed in other such isolation-layer roles), since most (possibly all)
of the errors become language level compile time errors.

On Mon, Nov 14, 2016 at 5:08 PM, Aaron Sherman  wrote:

> I guess I wasn't clear in what I was asking:
>
> What, exactly, was it that NQP was doing? What were the inputs and what
> was the behavior that you observed? So far, all I have to go on is one
> example that you feel is not illustrating the broken behavior of NQP that
> you want to work around with a change to the way Callable and calling work.
> I'm not suggesting that the latter is bad, but it seems to be a patch
> around a problem in the former...
>
>
>
>
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
>
> On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery 
> wrote:
>
>>
>> On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman  wrote:
>>
>>> So, you said that the problem arises because NQP does something
>>> non-obvious that results in this error. Can you be clear on what that
>>> non-obvious behavior is? It sounds to me like you're addressing a symptom
>>> of a systemic issue.
>>
>>
>> That's pretty much the definition of LTA. The programmer did something
>> that on some level involves a call (in the simple example it was explicit,
>> but there are some implicit ones in the language), and got a runtime error
>> referencing an internal name instead of something preferably compile time
>> related to what they wrote. The fix for this is to abstract it into a role
>> that describes "calling"/"invoking" instead of having a CALL-ME that the
>> user didn't (and probably shouldn't) define suddenly pop up out of nowhere.
>> That isn't the part that's difficult, aside from "so why wasn't it done
>> that way to begin with?".
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: CALL-ME vs. Callable

[Aaron Sherman]

I guess I wasn't clear in what I was asking:

What, exactly, was it that NQP was doing? What were the inputs and what was
the behavior that you observed? So far, all I have to go on is one example
that you feel is not illustrating the broken behavior of NQP that you want
to work around with a change to the way Callable and calling work. I'm not
suggesting that the latter is bad, but it seems to be a patch around a
problem in the former...




Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery 
wrote:

>
> On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman  wrote:
>
>> So, you said that the problem arises because NQP does something
>> non-obvious that results in this error. Can you be clear on what that
>> non-obvious behavior is? It sounds to me like you're addressing a symptom
>> of a systemic issue.
>
>
> That's pretty much the definition of LTA. The programmer did something
> that on some level involves a call (in the simple example it was explicit,
> but there are some implicit ones in the language), and got a runtime error
> referencing an internal name instead of something preferably compile time
> related to what they wrote. The fix for this is to abstract it into a role
> that describes "calling"/"invoking" instead of having a CALL-ME that the
> user didn't (and probably shouldn't) define suddenly pop up out of nowhere.
> That isn't the part that's difficult, aside from "so why wasn't it done
> that way to begin with?".
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Brandon Allbery]

On Mon, Nov 14, 2016 at 5:00 PM, Jon Lang  wrote:

> So what is the assuming method, and why is it in a callable role? What was
> the logic behind that decision?


It's perfectly sensible: it's how you implement partial application (which
as sadly usual is mis-called "currying"). (foo) is a
callable (and a Callable; note however that some-callable is not
necessarily a Callable!) which, when invoked, invokes
some-callable(foo, <*parameters
to invocation here*>).


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: CALL-ME vs. Callable

[Jon Lang]

So what is the assuming method, and why is it in a callable role? What was
the logic behind that decision?

On Nov 14, 2016 1:38 PM, "Brandon Allbery"  wrote:

> This should probably have been cc-d to the list.
>
> Callable claims to be the thing we want. What it actually is, is a mix-in
> that adds the assuming method. I am not sure these can be conflated.
>
> Note that the current docs actually do claim it is what I want. This is
> because I first brought this up in IRC while the documentation for
> Callable was being written, and it got modified to match my then current
> musings because nobody who actually works on the spec was around. I had in
> fact specified that this was a "would be nice" but that I wasn't sure if it
> would actually work; I have since concluded that it likely won't, and needs
> to be a distinct role. Which is part of why I brought this up: the current
> doc does not match what currently happens, and may not actually be
> implementable without breaking the spec (that is, 6.d would have a
> fundamental conflict with 6.c over the meaning of Callable).
>
> On Mon, Nov 14, 2016 at 4:30 PM, Jon Lang  wrote:
>
>> Okay, let's go with that. What does Callable do, and why is it called
>> that?
>>
>> On Nov 14, 2016 1:09 PM, "Brandon Allbery"  wrote:
>>
>>>
>>> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman  wrote:
>>>
 I do think, though that if the concern is really with "the 4 cases
 when nqp hauls a CALL-ME out of its bowels" then that's what should be
 addressed...

>>>
>>> The main addressing of that is some kind of role to abstract it
>>> properly. I just think the current situation is bad and even if we come up
>>> with a name for the new role, it's still going to be confusing ("ok, why do
>>> we have both Callable and Invokable? ...uh wait, Callable means *what*
>>> exactly?").
>>>
>>>
>>> --
>>> brandon s allbery kf8nh   sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Brandon Allbery]

This should probably have been cc-d to the list.

Callable claims to be the thing we want. What it actually is, is a mix-in
that adds the assuming method. I am not sure these can be conflated.

Note that the current docs actually do claim it is what I want. This is
because I first brought this up in IRC while the documentation for Callable
was being written, and it got modified to match my then current musings
because nobody who actually works on the spec was around. I had in fact
specified that this was a "would be nice" but that I wasn't sure if it
would actually work; I have since concluded that it likely won't, and needs
to be a distinct role. Which is part of why I brought this up: the current
doc does not match what currently happens, and may not actually be
implementable without breaking the spec (that is, 6.d would have a
fundamental conflict with 6.c over the meaning of Callable).

On Mon, Nov 14, 2016 at 4:30 PM, Jon Lang  wrote:

> Okay, let's go with that. What does Callable do, and why is it called that?
>
> On Nov 14, 2016 1:09 PM, "Brandon Allbery"  wrote:
>
>>
>> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman  wrote:
>>
>>> I do think, though that if the concern is really with "the 4 cases when
>>> nqp hauls a CALL-ME out of its bowels" then that's what should be
>>> addressed...
>>>
>>
>> The main addressing of that is some kind of role to abstract it properly.
>> I just think the current situation is bad and even if we come up with a
>> name for the new role, it's still going to be confusing ("ok, why do we
>> have both Callable and Invokable? ...uh wait, Callable means *what*
>> exactly?").
>>
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: CALL-ME vs. Callable

[Brandon Allbery]

On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman  wrote:

> So, you said that the problem arises because NQP does something
> non-obvious that results in this error. Can you be clear on what that
> non-obvious behavior is? It sounds to me like you're addressing a symptom
> of a systemic issue.


That's pretty much the definition of LTA. The programmer did something that
on some level involves a call (in the simple example it was explicit, but
there are some implicit ones in the language), and got a runtime error
referencing an internal name instead of something preferably compile time
related to what they wrote. The fix for this is to abstract it into a role
that describes "calling"/"invoking" instead of having a CALL-ME that the
user didn't (and probably shouldn't) define suddenly pop up out of nowhere.
That isn't the part that's difficult, aside from "so why wasn't it done
that way to begin with?".

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: CALL-ME vs. Callable

[Aaron Sherman]

So, you said that the problem arises because NQP does something non-obvious
that results in this error. Can you be clear on what that non-obvious
behavior is? It sounds to me like you're addressing a symptom of a systemic
issue.


Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Nov 14, 2016 at 4:08 PM, Brandon Allbery 
wrote:

>
> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman  wrote:
>
>> I do think, though that if the concern is really with "the 4 cases when
>> nqp hauls a CALL-ME out of its bowels" then that's what should be
>> addressed...
>>
>
> The main addressing of that is some kind of role to abstract it properly.
> I just think the current situation is bad and even if we come up with a
> name for the new role, it's still going to be confusing ("ok, why do we
> have both Callable and Invokable? ...uh wait, Callable means *what*
> exactly?").
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Aaron Sherman]

Fair points, all.

I do think, though that if the concern is really with "the 4 cases when nqp
hauls a CALL-ME out of its bowels" then that's what should be addressed...



Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Nov 14, 2016 at 3:22 PM, Brandon Allbery 
wrote:

> Also...
>
> On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman  wrote:
>
>> Role-based testing seems very perl6ish. I'd suggest the role name be
>> "Invocable" with much the sort of signature as you've described.
>
>
> If it's Invokable then the method should probably be INVOKE. It still
> leaves the question of why Callable appears to be the only role named
> after what it applies to instead of what it provides.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Brandon Allbery]

Also...

On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman  wrote:

> Role-based testing seems very perl6ish. I'd suggest the role name be
> "Invocable" with much the sort of signature as you've described.


If it's Invokable then the method should probably be INVOKE. It still
leaves the question of why Callable appears to be the only role named after
what it applies to instead of what it provides.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net