in reply to Existing module for PerlX::Maybe except for hash existence?

This is a rant, slightly off-topic.

I find distinguishing between "a parameter was not provided" and "a parameter was given as undef" icky. Both are saying "The caller does not provide a defined value", but there is no hint why you need two different ways to say that, and what different behaviors you would expect. Do you expect undefined behavior when you pass an undef value? Probably not. And where does that stop? I recall a suggestion (by Ovid?) to add another special value "uninitialized", so if you say my $v = undef; then $v would be not uninitialized but undefined, and if you say my $v; then $v is both undefined and uninitalized. This "uninitialized" would be the scalar equivalent of the value of a non-existing hash key. Sooner or later someone will call for a builtin function which resets a variable to the uninitialized state...

When I define the signature of a subroutine I need to specify what values I expect, and what behavior will result. I can offer one default value for convenience. But ... why would I want to provide two different ways of not passing a value? If these two ways mean different things to the subroutine, then there must be a better way to describe the resulting behavior.

I understand PerlX::Maybe as a necessary evil to cope with icky interfaces which make a decision between "undefined" and "not provided", but you are looking for something "on the receiving side for subroutines and objects" to which I would like to reply: Please don't.

Replies are listed 'Best First'.
Re^2: Existing module for PerlX::Maybe except for hash existence?
by haukex (Archbishop) on Feb 25, 2025 at 15:20 UTC

    I tend to agree that differentiating between "argument not passed" and "argument is undef" is tricky, and from experience with my own modules there is a simple situation where it is problematic: un-setting individual arguments later. You can say function(%defaults, option=>undef) to override $defaults{option} back to undef, but removing a key from %defaults is not really a viable option when, just for example, the defaults and overriding options come from JSON files.

[reply]
[d/l]
[select]
      This point also seems to be evidence for treating "not existing" and "not defined" as the same, since passing an explicit `undef` there would restore that `function` to "use a default value for `option`".
[reply]
Re^2: Existing module for PerlX::Maybe except for hash existence?
by cavac (Prior) on Feb 24, 2025 at 16:18 UTC

    Both are saying "The caller does not provide a defined value", but there is no hint why you need two different ways to say that

    My guess is that it's the difference "the caller does not have/want a value for this" and "the caller forgot to specify the value"

    Take one example: A program called SchrödingersCat needs a command line flag to specify if the cat is alive or dead. But when called with a value of "undef", the caller provides a valid value of "we don't know if the cat is alive or dead". See Tom Scott's video on Null Island: The Busiest Place That Doesn't Exist

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
    Also check out my sisters artwork and my weekly webcomics
[reply]
      Take one example: A program called SchrödingersCat needs a command line flag to specify if the cat is alive or dead. But when called with a value of "undef", ...

      A nice example, indeed. Just one question: How do you pass an undefined value as a command line flag?

      See Tom Scott's video....

      Thanks: Another example which underpins my point. The video explains the difference between NULL, "NULL" and 0 when read from a database. So yes, a database has NULL as the equivalent of an undefined value. But a database has no notion of "this field does not exist": If a field is in a table definition, then it exists for every single record. So, again, it has only one special value, not two.

[reply]

      Your example fails.

      There are three states: Alive, dead, superposition.

      There's no need to differentiate between not provided and undef. Both would be considered superposition.

      And you mention command-line arguments where it's not even possible to pass undef, completely defying your point.

      Your example supports haj, not you.

[reply]

In Section Seekers of Perl Wisdom