develooper Front page | perl.perl5.porters | Postings from June 2022

Re: A troubling thought - smartmatch reïmagined

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 26, 2022 14:10
Subject:
Re: A troubling thought - smartmatch reïmagined
Message ID:
YrhovbZilg5WhQ9T@etla.org
On Sat, Jun 25, 2022 at 09:13:17PM +0100, Paul "LeoNerd" Evans 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.

You have this:

    It is now possible to classify any given scalar value into exactly one
    of the following five categories:

    undef
    boolean
    initially string
    initially number
    reference


    ...

    I'd also like to suggest a rule that given any pair of scalars of
    different categories, the result is always false.

I don't think that that categorisation handles "big integers" well.
(Or bigrats, or similar).

In that BigInts are stored as references with overloading, and attempt to
behave like a scalar, even though they aren't really.

If I read your table/plan correctly, a BitInt would be matched as a reference,
hence a number "~~" BigInt matchup would fail.


I'm not sure if there's a slightly more complex bounded plan that can handle
this well. The start seems to be "take your 5 categories, and add a 6th which
is objects with overloading..." but it's then unclear if one is only
permitted to consider objects with overloaded "not-so-smartmatch", or also
objects that can overload C<eq> and C<==> comparison.


But I don't know if this start is a rabbit hole that never terminates. Or if
there is an almost-as-simple way of categorising scalars that is

* simple (enough)
* consistent
* handles "big" integers and "big" numbers as if they are numbers
* doesn't special case specific core classes of big integers and big numbers

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About