Front page | perl.perl5.porters |
Postings from June 2022
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