Microsoft is even reportedly considering it* for inclusion in C#, now. I think every object-oriented programming language should have it.
* http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-las...
def get(obj, k, default=None):
""" safe __getitem__ obj[k] with a default """
def assoc(obj, k, v):
""" obj[k] = v returning obj """
def dissoc(obj, k):
""" safe del obj[k] returning obj without k"""
def get_in(obj, keys, default=None):
""" __getitem__ obj[k0][k1][kn] with a default. """
def assoc_in(obj, keys, v, default=lambda n: dict()):
""" __setitem__ obj[k0][k1][kn] = v. __getitem__ failures handled with default """
def dissoc_in(obj, keys):
""" Return obj asserting that obj[k0][k1][kn] does not exist. """
def update_in(obj, keys, update_fn=None, default=lambda n:dict()):
""" Update the value at obj[k0][k1][kn] with update_fn returning obj. __getitem__ failures handled by default. """
def merge_with(fn, **dictionaries):
""" Merge resolving node conflicts with fn """
def deep_merge_with(fn, **dictionaries):
""" Recursively merge resolving node conflicts with fn"""
Producing NULL (or whatever the languages equivalent is) isn't an error -- if there was an error, it would be throwing an exception, not returning NULL. The idea of "do this chain of operations propagating nulls encountered at any point" is reasonably useful.
> But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.