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: [email protected] Toolsmith, developer, gamer and life-long student. On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery <[email protected]> wrote: > > On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman <[email protected]> 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 > [email protected] > [email protected] > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
