Mailing List Archive

Pre-{Pre-RFC} - match/case syntax
I'm nowhere near ready yet to consider writing even a Pre-RFC on
match/case syntax, because far too much is still open for design. But I
thought I'd remind people here who enjoy a good language design debate,
that the thing exists and is being experimented on as a CPAN module:

https://metacpan.org/pod/Syntax::Keyword::Match

E.g. from the SYNOPSIS:

use v5.14;
use Syntax::Keyword::Match;

my $n = ...;

match($n : ==) {
case(1) { say "It's one" }
case(2) { say "It's two" }
case(3) { say "It's three" }
case(4), case(5)
{ say "It's four or five" }
default { say "It's something else" }
}

There's a lot of design work still to be done on this; several of the
big questions are sat as "Wishlist" RT tickets on the queue:

https://rt.cpan.org/Dist/Display.html?Name=Syntax-Keyword-Match


I'd encourage anyone who would express an interest in commenting on any
future (Pre-)RFC on the design of such syntax, should probably begin by
taking at least a quick look at the module and some of those issues
now, and ideally help me work them out on CPAN before we even get it
to the RFC stage.

Ideally we'd proceed with the in-core implementation much like the
(very successful, if I may say so) try/catch migration which went from
stable CPAN module to proper in-core implementation very quickly. That
was possible precisely because it had all that time as a CPAN module to
work out all the exciting design questions first. It'd be nice to do
the same process here.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
Den 25.06.2022 00:17, skrev Paul "LeoNerd" Evans:
> I'm nowhere near ready yet to consider writing even a Pre-RFC on
> match/case syntax, because far too much is still open for design. But I
> thought I'd remind people here who enjoy a good language design debate,
> that the thing exists and is being experimented on as a CPAN module:
>
> https://metacpan.org/pod/Syntax::Keyword::Match
>
> E.g. from the SYNOPSIS:
>
> use v5.14;
> use Syntax::Keyword::Match;
>
> my $n = ...;
>
> match($n : ==) {
> case(1) { say "It's one" }
> case(2) { say "It's two" }
> case(3) { say "It's three" }
> case(4), case(5)
> { say "It's four or five" }
> default { say "It's something else" }
> }
>
> There's a lot of design work still to be done on this; several of the
> big questions are sat as "Wishlist" RT tickets on the queue:
>
> https://rt.cpan.org/Dist/Display.html?Name=Syntax-Keyword-Match
>
>
> I'd encourage anyone who would express an interest in commenting on any
> future (Pre-)RFC on the design of such syntax, should probably begin by
> taking at least a quick look at the module and some of those issues
> now, and ideally help me work them out on CPAN before we even get it
> to the RFC stage.
>
> Ideally we'd proceed with the in-core implementation much like the
> (very successful, if I may say so) try/catch migration which went from
> stable CPAN module to proper in-core implementation very quickly. That
> was possible precisely because it had all that time as a CPAN module to
> work out all the exciting design questions first. It'd be nice to do
> the same process here.
>
By coincidence I watched this earlier today:
https://www.youtube.com/watch?v=raSRNIoUYig and it felt kind of
accurate. I also agree that many of the features presented belong
together. I agree with the whole list/array part is challenging to get
just right (It made me start thinking of perhaps it is time introducing
a native list and/or a range object with methods mirroring the operators
instead).

Thanks for your work and also the great way of slowly (but fast)
introducing new features to Perl via ::Keyword et al. Fast prototyping
which people can get a feel with fast seems to be a good approach.
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
On 2022-06-24 3:17 p.m., Paul "LeoNerd" Evans wrote:
> my $n = ...;
>
> match($n : ==) {
> case(1) { say "It's one" }
> case(2) { say "It's two" }
> case(3) { say "It's three" }
> case(4), case(5)
> { say "It's four or five" }
> default { say "It's something else" }
> }

I consider that the best part of this is you specify inline the exact comparison
operator or sub to use, the "==" in this case, meaning that the semantics of the
matching is completely explicit, rather than some implicit complicated logic.

This should be generic and configurable in the same way map/grep/sort etc are.

-- Darren Duncan
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
On Mon, 27 Jun 2022 02:11:08 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> This should be generic and configurable in the same way map/grep/sort
> etc are.

I'm not sure I follow this bit. How are those configurable now?

Can you suggest some examples?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
On Mon, Jun 27, 2022 at 11:11 AM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2022-06-24 3:17 p.m., Paul "LeoNerd" Evans wrote:
> > my $n = ...;
> >
> > match($n : ==) {
> > case(1) { say "It's one" }
> > case(2) { say "It's two" }
> > case(3) { say "It's three" }
> > case(4), case(5)
> > { say "It's four or five" }
> > default { say "It's something else" }
> > }
>
> I consider that the best part of this is you specify inline the exact
> comparison
> operator or sub to use, the "==" in this case, meaning that the semantics
> of the
> matching is completely explicit, rather than some implicit complicated
> logic.
>
> This should be generic and configurable in the same way map/grep/sort etc
> are.
>

I'd prefer the comparison operator per case so I can for example call isa
on an exception object to check if it's an exception object or just a
string.
That can be done using given/when from feature "switch", but as this says
it's experimental I haven't used it.
The section
https://perldoc.perl.org/perlsyn#Experimental-Details-on-given-and-when
this to explain why. To me it reads like "don't use it before v5.18". I
guess it wasn't declared non-experimental at or shortly after v5.18 because
it uses the experimental smartmatch underneath, although not mandatory.

Syntax that doesn't need to to write $_:

given|match|for|foreach ($foo) {
when|case (== 3) {
}
when|case (eq 'bar') {
}
when|case (->isa('X::File::NotFound') {
}
}

PS: I don't care what the keywords are called so I included some which are
already mentioned.
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
Op 27-06-2022 om 11:14 schreef Paul "LeoNerd" Evans:
> On Mon, 27 Jun 2022 02:11:08 -0700
> Darren Duncan <darren@darrenduncan.net> wrote:
>
>> This should be generic and configurable in the same way map/grep/sort
>> etc are.
> I'm not sure I follow this bit. How are those configurable now?
>
> Can you suggest some examples?
>
Map/grep/sort can take a sub which does the comparison/filter. Darren
makes a good observation that that is actually quite similar to your
proposed match/case, where you give the operator. I think what Darren
means is that it may make sense to think about both extending your
proposal to sort and friends and apply a more generic approach to
match/case:


    @x = sort : <=> @x; # we need a better syntax than this


and a generic comperator to match/case:


match ($n : sub($a, $b) { $a==$b })
      case(1) { say "It's one" }
      case(2) { say "It's two" }

...

or maybe

match (sub($a) { $a==$n })
      case(1) { say "It's one" }
      case(2) { say "It's two" }

...


However, apart from sort using the spaceship operator -- which would
admitedly  be very cool and rather useful, I myself do not see enough
value in both operators. So while it would be more generic, I doubt it's
actually useful enough. There may be value with oveloading and custom
infix operators though.


HTH,

M4



HTH,

M4
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
Hi there,

On Fri, 24 Jun 2022, Paul "LeoNerd" Evans wrote:

> ... a lot of design work still to be done on this; several of the
> big questions are sat as "Wishlist" RT tickets on the queue:
>
> https://rt.cpan.org/Dist/Display.html?Name=Syntax-Keyword-Match

Amongst other things

> 135129: I rather dislike option 1

Agreed. It would violate the Principle Of Least Surprise if the
compilation could result in an execution order which was in any way
different from the order in which it's written in the source. Were
that possible, I should never use it.

> 135128: We can clearly do much better here.

Maybe, but I'm not convinced that it's necessary.

My feeling is all that's needed is something which behaves as nearly
as possible to the way that, in C, the 'switch' statement behaves.
The casual coder should be able to, er, use it without pain. If it
got any more fraught than that I'd probably stick to if/elsif/else
which, although ugly, has after all managed well enough for decades.

Whatever it turns out to be, Heaven forbid that it's 'smart'.

Please try to keep separate the concepts of looping and branching.

--

73,
Ged.
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
On 2022-06-27 2:14 a.m., Paul "LeoNerd" Evans wrote:
> On Mon, 27 Jun 2022 02:11:08 -0700
> Darren Duncan <darren@darrenduncan.net> wrote:
>
>> This should be generic and configurable in the same way map/grep/sort
>> etc are.
>
> I'm not sure I follow this bit. How are those configurable now?
>
> Can you suggest some examples?

I mean that in the place where you had the "==" you can put a sub ref for an
inline definition of a comparison function so users can make it behave any way
they want, like how they write "sort <sub ref> <list>" etc, rather than the "=="
being only substitutable with a small list of pre-defined operators. -- Darren
Duncan
Re: Pre-{Pre-RFC} - match/case syntax [ In reply to ]
On 2022-06-27 6:12 a.m., Martijn Lievaart wrote:
> Op 27-06-2022 om 11:14 schreef Paul "LeoNerd" Evans:
>> On Mon, 27 Jun 2022 02:11:08 -0700
>> Darren Duncan <darren@darrenduncan.net> wrote:
>>
>>> This should be generic and configurable in the same way map/grep/sort
>>> etc are.
>> I'm not sure I follow this bit. How are those configurable now?
>>
>> Can you suggest some examples?
>>
> Map/grep/sort can take a sub which does the comparison/filter. Darren makes a
> good observation that that is actually quite similar to your proposed
> match/case, where you give the operator.

Martijn is spot on as to what I meant, as stated above.

> I think what Darren means is that it
> may make sense to think about both extending your proposal to sort and friends
> and apply a more generic approach to match/case:
>
>     @x = sort : <=> @x; # we need a better syntax than this

I actually was NOT suggesting that sort and friends are altered in any way, not
that extending them would necessarily hurt, but rather that sort and friends can
be used as inspiration for the new match feature.

> and a generic comperator to match/case:
>
> match ($n : sub($a, $b) { $a==$b })
>       case(1) { say "It's one" }
>       case(2) { say "It's two" }
> ...

Yes, this above example is exactly what I had in mind about generic and
configurable.

Having the shorthand of "==" in place of the sub for common scenarios is also
nice, but the general form like above is what's most important if the feature
itself wants to keep things simpler.

-- Darren Duncan