Thanks for your feedback, all.
Elizabeth, I've posted this on problem-solving, as suggested, as
https://github.com/Raku/problem-solving/issues/308 . Thanks!
yary, definitely good feedback, and I agree that I've probably attached
these things to the wrong object(s); that part of the proposal never felt
quite right to me, but I don't know enough to know what I'm missing. I've
amended the document slightly (see intro to the Iterating section over on
problem-solving) to include part of your suggestion, but feel free to
re-make your point over there.
Clifton:
- I assumed that the "when False" construct would match False against the
topic, but maybe I'm wrong.
- Regardless, I've incorporated all your suggestions into the document.
- My only query would be, would it work just as well to say "when not
.block-fine"?
- Your point about not limiting the smartmatching is very much a part of
the point I was trying to make. More options for everyone :) .
Thanks all!
On Mon, 13 Dec 2021 at 09:53, Clifton Wood <clifton.w...@gmail.com> wrote:
> 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>
>>
>>
