Front page | perl.perl5.porters |
Postings from June 2022
Re: A troubling thought - smartmatch reimagined
Thread Previous
|
Thread Next
From:
Tomasz Konojacki
Date:
June 26, 2022 04:47
Subject:
Re: A troubling thought - smartmatch reimagined
Message ID:
20220626064655.AE78.5C4F47F8@xenu.pl
On Sat, 25 Jun 2022 21:13:17 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
> Preface: This is less a concrete idea, and more a rambling set of
> thoughts that lead me to a somewhat awkward place. I'm writing it out
> here in the hope that others can lend suggestions and ideas, and see
> if we can arrive at a better place.
>
> This started off as a quick email, that turned into a long email, that
> became a *very* long email that I eventually decided to turn into a
> blog post.
>
> For the full content, you can see
>
> https://leonerds-code.blogspot.com/2022/06/a-troubling-thought-smartmatch.html
>
> but as a summary:
>
> I wonder if we're going about things the wrong way, regarding strings
> vs numbers, equality test operators, smartmatch, and a bunch of other
> ideas. Maybe - maybe - now that we can distinguish strings vs numbers
> a little better, there's a way we can make a single operator Do The
> Right Thing.
>
> Comments welcome - on blog or replied here.
It turns out I was right to worry that the scalar flags changes will
give people the wrong idea that Perl has types. It doesn't and it
shouldn't. Going that way is IMO a big mistake.
Sure, the "types" are now less volatile, so it's tempting to make use of
them. But the problem is their volatility wasn't the only reason why we
shouldn't rely on them.
Explicitness is one of the Perl's great strengths. The main example of
that explicitness are our comparison operators. Each of the operators
explicitly casts both operands to some type; for example, "$foo eq $bar"
in Python would be expressed as "str(foo) == str(bar)".
Your proposal throws away that explicitness. I don't like this. Less
explicit code is harder to reason about. It requires more context to be
understood. Explicitness is what distinguishes Perl from Python,
JavaScript and PHP.
Now, to address your "undef" problem. I think your post lacks context.
If it was just about "match", it would've been trivial to fix, you could
just add "defined { }". But I believe the real problem is that you're
also planning an "in" operator ("VAR in:OP LIST", e.g.
"$foo in:eq @bar").
Let's review some of the potential solutions:
1. As mentioned in your post, new comparison operators that treat
"undef" specially, i.e. "equ", "===" and "==~". They solve the problem
well, they're explicit, but: they are a bit ugly and they suffer from
being the same thing that already exists but slightly different, which
is a cardinal programming language design sin.
2. Redefine "eq", "==", "=~" with a feature flag to treat "undef"
specially. IMO that's how they should've been designed from the
beginning, but it may be too drastic of a change now.
3. Special-case defined() like this: defined() in @bar. It's harder
to parse, but it *isn't* ambiguous, although it might feel too magical.
Also, it could be done without special syntax, with a function that
returns an object with overloaded "eq", but that would be a bit too
convoluted for my taste.
4. New operator that compares definedness: "undef in:definedness @bar".
Naturally, the name is just a placeholder :P The problem is that
operator isn't very useful outside "match" and "in". Also, it's hard to
come up with a good spelling for it.
5. Just ignore the problem for "in". "match" can have "defined {}",
while "in" won't handle undefs specially. Users can use any/grep
instead.
Personally, I don't have a strong preference for any of the options, but
I think 3. *might* be the best.
Thread Previous
|
Thread Next