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 <a...@ajs.com> 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 <allber...@gmail.com> > wrote: > >> >> On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman <a...@ajs.com> 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, xmonad http://sinenomine.net
