5 ms·

> The same problem is more frequently discussed in the context of hash tables. If I look up a key in a hash table and I get a null value, is that because there

> The same problem is more frequently discussed in the context of hash tables. If I look up a key in a hash table and I get a null value, is that because there is no value stored for that key, or is it because null is the value stored for that key? People would like accessing the table to be convenient while distinguishing these two cases, and python doesn't allow that. You can choose from some different behaviors: Or, you can create a second null-like type in the language, name it 'undefined' perhaps, and return that when the key doesn't exist. Of course, that may be considered kicking the can down the road as now you will have to trust developers to be competent enough to never store 'undefined' in the hash table, which I suppose is the reason you didn't mention JavaScript's solution to the problem.

masklinn 7y ago
The actual fix is to have a completely separate wrapper type (usually an option type) which signals in a type-safe and unambiguous manner that the key was missing. Then you don’t have the issues of in-band signalling.
- thaumasiotes 7y ago
  This isn't really different from the multiple values approach. For example, python could have table accesses return (None, True) for a None value that was present, (None, False) for a value that wasn't present, (5, True) for a 5 value that was present... Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.) This works, but it's unpopular because it makes every table access more difficult.
  - masklinn 7y ago
    > This isn't really different from the multiple values approach. If you ignore most of what I said then it’s not. > Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.) It’s neither type-safe nor unambiguous. > This works For low value of works. Which I guess is all you can ask for in a dynamically typed langage (eg Erlang uses this pattern to fairly good effect, but it has very good support for it). But it should not be confused with an actual solution to the issue. It can make things less bad (again given good support for this pattern which Python does not have), not actually good.
    - thaumasiotes 7y ago
      > It’s neither type-safe nor unambiguous. How'd you get here? It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe, and it's fully unambiguous.
      - masklinn 7y ago
        > It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe Yes. > and it's fully unambiguous. No, you have any random value flagged as not present (in fact you can forget about or ignore the flag entirely), and no clue if that means anything.
        thaumasiotes 7y ago
        Can you provide an example of what you mean by "ambiguity"?
thaumasiotes 7y ago
> Or, you can create a second null-like type in the language, name it 'undefined' perhaps, and return that when the key doesn't exist. No, this isn't a solution. This is like terminating C strings with 0 characters, or terminating TSV fields with tabs. It sounds like it makes sense, until you ask "what if the terminator occurs within the data?" Eventually someone's going to need to store undefined. It's no different than null. If it were a competence issue (which it isn't), we'd be saying that storing null in the hash table was a mistake, not something to work around with null2.
Izkata 7y ago
Javascript's solution is actually obj.hasOwnProperty(key) and the "in" operator ("in" checks the inheritance tree, hasOwnProperty doesn't). Checking for undefined is better known/easily discoverable but hasn't been the right way to do it since at least IE 5.5 / Firefox 1.

masklinn 7y ago

The actual fix is to have a completely separate wrapper type (usually an option type) which signals in a type-safe and unambiguous manner that the key was missing. Then you don’t have the issues of in-band signalling.

thaumasiotes 7y ago
This isn't really different from the multiple values approach. For example, python could have table accesses return (None, True) for a None value that was present, (None, False) for a value that wasn't present, (5, True) for a 5 value that was present... Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.) This works, but it's unpopular because it makes every table access more difficult.
- masklinn 7y ago
  > This isn't really different from the multiple values approach. If you ignore most of what I said then it’s not. > Is that multiple values? (Yes.) Or a wrapper type? (Also yes, it's a tuple, a collection of values.) It’s neither type-safe nor unambiguous. > This works For low value of works. Which I guess is all you can ask for in a dynamically typed langage (eg Erlang uses this pattern to fairly good effect, but it has very good support for it). But it should not be confused with an actual solution to the issue. It can make things less bad (again given good support for this pattern which Python does not have), not actually good.
  - thaumasiotes 7y ago
    > It’s neither type-safe nor unambiguous. How'd you get here? It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe, and it's fully unambiguous.
    - masklinn 7y ago
      > It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe Yes. > and it's fully unambiguous. No, you have any random value flagged as not present (in fact you can forget about or ignore the flag entirely), and no clue if that means anything.
      - thaumasiotes 7y ago
        Can you provide an example of what you mean by "ambiguity"?

thaumasiotes 7y ago

> Or, you can create a second null-like type in the language, name it 'undefined' perhaps, and return that when the key doesn't exist. No, this isn't a solution. This is like terminating C strings with 0 characters, or terminating TSV fields with tabs. It sounds like it makes sense, until you ask "what if the terminator occurs within the data?" Eventually someone's going to need to store undefined. It's no different than null. If it were a competence issue (which it isn't), we'd be saying that storing null in the hash table was a mistake, not something to work around with null2.

Izkata 7y ago

Javascript's solution is actually obj.hasOwnProperty(key) and the "in" operator ("in" checks the inheritance tree, hasOwnProperty doesn't). Checking for undefined is better known/easily discoverable but hasn't been the right way to do it since at least IE 5.5 / Firefox 1.