Implement a prefix:<delete> macro

[masak]

I keep coming up with new simple-ish macros to define. This one would also be an excellent specimen in examples/, and not too far-fetched in the short term, either.

I want to emulate mostly Python's del statement. More precisely,

• Let's skip being able to delete lexical names. I know Python values that kind of dynamism, but I don't. I prefer being able to statically assume that a declared variable exists along all paths.
• Let's also skip being able to delete object properties, for similar reasons. I prefer not to muck around with static properties.
• Deleting an array element should be possible, and should have the same effect as a corresponding 1-element splice. (Aka the removeElements of Implement splice, kinda #238.)
• Deleting a dictionary entry should also be possible, and should have the same effect as using a .delete method on the dictionary. (Do we have this? Should we?)

I will file a separate issue about array slices, and the opportunity to do delete on those too. (Update: Filed as #291.)

It hasn't escaped my notice that #214 has a story about handling long chains of accessors only to do something specific with the rightmost tip. I just skimmed that issue, and solidify doesn't strike me as a perfect match for what we want to do here. But I sense there's something that would satisfy both the original needs of #214 and the prefix:<delete> macro. Will revisit this point when I have the requisite brainpower.

Should prefix:<delete> return something sensible? In both Perl 5 and Perl 6, the return value is the thing deleted, but I'm not sure I see the allure. Tempted to just return None.

[masak]

Tempting opportunity: implement delete by taking an lvalue() of the expression and calling .delete on it.

This method (which isn't mentioned in #214 but which I realized yesterday we'll want to have for exactly these things) would work on Array/Dict/(other data structure) elements/entries, but not on lexical slots or object properties.

[masak]

Given an a without a .b, what should delete a.b[c] do?

• Throw an exception, because .b doesn't exist?
• Do nothing and consider that a success; after all, a.b[c] already does not exist since a.b doesn't?

I think I want the first option, which is the slightly more Pythonic of the two — in general, I want assumptions that don't hold up to be flagged to me as errors instead of swept under rugs.

Also, per #229, we can (should) still get the laissez-faire behavior by writing it delete a?.b[c]. (Look, another force-multiplier!) This is what convinced me we should be strict by default.

[masak]

...even though #229 doesn't exactly have the same semantics here, but it's close enough. #229 says "at any point, when something is missing, immediately give back none and don't look further". Here, with prefix:<delete>, what we want the semantics to be is "at any point, when something is missing, immediately declare success and don't look further". Since we're not expecting a value from an evaluation, we don't care about the none. But there is clearly still some commonality here.

[masak]

"at any point, when something is missing, immediately declare success and don't look further"

I mean, what this is is just a Maybe monad, of course. *handwave handwave*

And something about @229-style optional chains could be configurable, so that normal expression evaluation can get none, and the delete operator can get silent success. Everyone happy.