Tim,
Love the suggestions, but some of the syntax is a little confusing. Let me
see if I can reword these a bit:
First off, the good:
BEGIN {} COMPILE ENTER {}
CHECK {} COMPILE LEAVE {}
INIT {} RUNTIME ENTER {}
END {} RUNTIME LEAVE {}
DOC * DOC * (No change)
ENTER {} ENTER {} (No change)
LEAVE {} LEAVE {} (No change in syntax)
Great! These remove a lot of the ambiguity of things.
KEEP {} LEAVE { .success and do {} }
UNDO {} LEAVE { .success or do {} }
Took me a minute to realize you are using &?BLOCK as the topic here. Yes,
you did mention this from the start, but I am a firm believer that code
should be as intuitive as possible, and this is not. I would almost
prefer that this were spelled out, precisely for this reason.
FIRST {} ENTER { once {} }
Not bad!
> NEXT {} LEAVE .iter-done { when False {} }
Here's the first I have serious issues with. For one thing "when False {}"
is a no-no. It will NEVER evaluate. You'd have to use "when False.so.not".
Having this here just makes things too confusing.
I think a better rewrite would be:
LEAVE { when .iter-done.not { } }
Which sums things up more concisely.
> LAST {} LEAVE .iter-fine { when True {} }
Same thing, here. Better written as:
LEAVE { when .iter-fine { } }
> PRE {} ENTER { assert {} }
POST {} LEAVE { assert {} }
Also good
> CONTROL {} LEAVE .block-done { when X::Control {} }
Again, the compound use of a method and a when block makes things too
confusing. Better written as:
LEAVE { when .block-done ~~ X::Control { } }
> CATCH {} LEAVE .block-fine { when False {} }
Same situation with the nested when. Better written as:
LEAVE { when .block-fine.not { } }
QUIT {} LEAVE .iter-fine { when False {} }
Same as above. Better written as:
LEAVE { when .iter-fine.not { } }
> LAST {} LEAVE .iter-fine(CX::Done) { when True {} }
Better written as:
LEAVE { when .iter-fine(CX::DONE) { } }
> CLOSE {} LEAVE .iter-done { when CX::Done {} }
Better written as:
LEAVE { when .iter-done ~~ CX::Done { } }
> COMPOSE {} COMPOSE ENTER { }
Finally, this one I'd just leave as COMPOSE since there doesn't seem to be
a corresponding LEAVE
And now, once you look at the above, you'll notice that *don't really have
to limit the smartmatching*. So these:
(CONTROL) LEAVE { when .block-done ~~ X::Control { } }
(LAST) LEAVE { when .iter-fine(CX::DONE) { } }
(CLOSE) LEAVE { when .iter-done ~~ CX::Done { } }
*could *become more useful as specialized exception handlers.
Just a thought.
Thanks for presenting these! You should definitely pass these on to
Raku/problem-solving
- Xliff
On Sun, Dec 12, 2021 at 1:52 PM Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
> I suggest making this a problem-solving issue:
> https://github.com/raku/problem-solving
>
> > On 11 Dec 2021, at 05:48, Timothy Nelson <wayl...@wayland.id.au> wrote:
> >
> > Hi all.
> >
> > I've been lurking on this list for years (and once won an "oldest
> resurrected conversation" award). I've loved Raku conceptually since the
> start, but have only recently been putting it to much use. Mostly, the
> reality is as good as the promises, but there are two areas I have been
> liking a bit less. One of these is Phasers. The idea is a great one, but
> after going to them numerous times and often not finding what I want, I've
> come to the conclusion that they need some remodelling.
> >
> > That's a big step in a language that's been around for a while like Raku
> has. Maybe this is a discussion for the Raku 2.0 standard (if there will
> be such a thing), or maybe it's something that can be introduced over time
> (or as a Slang, or something). Anyway, after thinking about them for a
> while, and having my thoughts coalesce into a document over the last few
> days, I thought I'd post the document to this mailing list and see what
> people think. I have put in a number of hours today trying to make it more
> readable, but still may not have gotten the ordering right.
> >
> > I'm fully aware that there may be drawbacks that I haven't thought of,
> but if one useful idea comes from this document, then that's a step in the
> right direction.
> >
> > Thanks all,
> > <PhasersMkIIDocumentation.pdf>
>
>
