Option and Null in Dynamic Languages

Another way of seeing the same thing is: Type-theoretically speaking, MRV is using a product type (two values) to emulate a sum type (one value of two possible forms); why not just use a sum type?

    1> X = #{"a" => 1}.
    #{"a" => 1}
    2> maps:find("a", X).
    {ok,1}
    3> maps:find("x", X).
    error

Further, in idiomatic Erlang, you don’t bother with a branch for each case of the option type; you just do the following:

    {ok, Val} = maps:find("a", X).

  from itertools import chain
  
  def getOpt(d, k):
      return [d[key]] if key in d else []

  def values_in(keys, d):
      return list(chain(*[ getOpt(d,key) 
                           for key in keys ]))

  def values_in(keys, d)
    keys.flat_map {|k| d.has_key?(k) ? [d[k]] : []}
  end

  def values_in(dict, keys):
      marker = object()
      return [x
              for x in (dict.get(k, marker)
                        for k in keys)
              if x is not marker]

        //Let's define some object
        var obj = {a: true, b: true, c: true, d: true, hasOwnProperty: true}

        //Now let's make them falsy in different ways
        obj.a = undefined; //set to undefined
        obj.b = null; //set to null
        obj.c = false; //set to false
        delete obj.d; //delete key
        delete obj.hasOwnProperty //delete key, but present in prototype

        console.log(obj.a) //--> undefined
        console.log(obj.b) //--> null
        console.log(obj.c) //--> false
        console.log(obj.d) //--> undefined
        console.log(obj.hasOwnProperty) //--> [Function]

        console.log('a' in obj) //--> true
        console.log('b' in obj) //--> true
        console.log('c' in obj) //--> true
        console.log('d' in obj) //--> false
        console.log('hasOwnProperty' in obj) //--> true

        console.log(obj.a == null) //--> true
        console.log(obj.b == null) //--> true
        console.log(obj.c == null) //--> false
        console.log(obj.d == null) //--> true
        console.log(obj.hasOwnProperty == null) //--> false 

        for(var key in obj) {
          console.log(key) //--> prints a, b, c
        }

        local tab = {a = true, b = true, c = true}
        
        -- by default there are none, but we can defined a fallback metatable similar to a prototype method like js's obj.prototype.hasOwnProperty

        setmetatable(tab, {__index={c='meta c', d='meta d'}})

        -- if it is important that a key is explicitly set to false, do so, otherwise simply remove it
        tab.a = false --set to false
        tab.b = nil --set to nil
        tab.c = nil --set to nil, present in fallback table
        tab.d = false --set to false, present in fallback table

        print(tab.a) --false
        print(tab.b) --nil
        print(tab.c) --meta c
        print(tab.d) --false

This is especially important in Lua, because any value can be a key, you would have to be sure to delete the key otherwise it could not be garbage collected. local tab1 = {1,2,3,4,5} local tab2 = {} tab2[tab1] = true for k,v in pairs(tab2) do tab[k] = nil end

If this worked like JavaScript, then tab2[tab1] would return nil, but tab1 could not be garbage collected until tab2 is. Because JavaScript objects can only have strings for keys, this is less of an issue.

So, sure, you got rid of null from the language. Does your program handle the case where it was handed a negative number correctly? All positive values? All unicode?

Consider, in the Ariane Rocket incident, they were using a dependently typed language. Didn't magically prevent errors in assembly.

So, fine, we'll make our programs where they handle all cases... Rapid prototyping probably just flew out the window. As did worrying about actual honest to goodness use cases.

A great quote by Knuth I saw once was where he acknowledged that tex would choke on mile wide documents. But who cares?