Clarification
Although I may be missing his point I currently feel that Leonid's comments below are misleading. I am not looking for anything that is not already a part of Association functionality other than a way to define what is returned for a missing key on a per-association basis. I thought that the Block example below made this clear but perhaps not.
I am seeking a way to do something like this:
asc = <|"a" -> 1, "b" -> 2, _ -> 0|>;
asc["x"]
(* desired output: 0 *)
(* actual output: Missing["KeyAbsent", "x"] *)
Critically I am not looking for general pattern matching of Key names however; I only want a way to define one default value for missing keys.
Original ramblings
It can be very useful to define background or default value for an object that can be incremented or otherwise modified. A simple (and for me, common) use is a counter:
count[_] = 0;
++count[#] & /@ {"a", "a", "b", "a", "b", "a"}
{1, 2, 1, 3, 2, 4}
Since there are advantages to Association such as ease of copying and direct manipulation of keys and values I would like to port this method to new function. However I cannot think of a clean, practical way to define a default. (I consider directly overloading System functions such as Increment undesirable.)
I note that it is possible to increment a missing value and then clean it up afterward:
asc = <||>;
++asc[#] & /@ {"a", "a", "b", "a", "b", "a"} /. _Missing -> 0
{1, 2, 1, 3, 2, 4}
This isn't really the same as setting a default value however and it limits the way this method can be used. Somewhat better I think is to temporarily redefine Missing. This at least gives values that are up-to-date while the operation is performed.
asc = <||>;
Block[{Missing},
Missing["KeyAbsent", _] = 0;
++asc[#] & /@ {"a", "a", "b", "a", "b", "a"}
]
asc
{1, 2, 1, 3, 2, 4}<|"a" -> 4, "b" -> 2|>
This could be packaged a bit more nicely but it still feels like a bit of a kluge.
Is there an approach I am failing to consider? Or by some slim chance is there a hidden way to do this?
DownValues. And the fact that what you request is problematic in this approach is simply another facet of that: the ability to use defaults has been transferred from association itself to theLookupfunction, but thenLookupcan not be used to mutate things, bacause it knows nothing about where a given assoc is stored (and doesn't care about it). If you need mutation, why use associations? You can keep usingDownValuesin such cases. – Leonid Shifrin Jul 06 '15 at 04:05Lookupprevent other handling? I wouldn't think so. (3) Do all of the benefits of associations cease to exist for some reason? Easy copying and manipulation of values, nested associations, etc. still apply do they not? – Mr.Wizard Jul 06 '15 at 05:45Lookupprecisely because there is no default. – rcollyer Jul 06 '15 at 16:09IncrementorAddTo. I see no reason that a default in theAssociationand a specified default inLookupcannot coexist. Am I mistaken? – Mr.Wizard Jul 06 '15 at 16:15Lookupto supply a default when one existed within anAssociationwould require some tighter knitting between the two, otherwise how wouldLookupknow when to supply its default? – rcollyer Jul 06 '15 at 16:28Lookupdoesn't already have thisknittingbut I believe it does; it is not relying onMissingto detect a missing value. I believe it finds it directly. I mean thatLookupis not doing something like/. _Missing -> 0in my second example. What therefore is the complication? – Mr.Wizard Jul 06 '15 at 16:39DownValuesorSystem`Utilities`HashTableis that associations are immutable, but cheap to copy and modify. In the linked post I described why immutability is valuable (statelessness, garbage collection, etc). The ability to mutate assocs in place does exist (like with lists), but its support in the language is limited to very simple things like part assignments. Since there are no true references in Mathematica, ... – Leonid Shifrin Jul 06 '15 at 18:00Missing. There is simply no way forLookup, for example, to do some in-place modifications related to the default value. So, my point has been that what you ask for would go into directions with very weak support from the core language, and would need more work then. – Leonid Shifrin Jul 06 '15 at 18:03Lookupis the only built-in function providing the default mechanism. One can surely implement one's own handling, but that would be more work, again (3)."Do all of the benefits of associations cease to exist for some reason? Easy copying and manipulation of values, nested associations, etc. still apply do they not" - yes, they do not apply any more as long as you want your assoc to be mutable and carry a state. That's precisely the point. You have to then define a new data type that would carry that state together with the assoc, and integrate ... – Leonid Shifrin Jul 06 '15 at 18:06Mapetc for data transformations, while hash tables can not, because they are stateful. Now, while we can define e.g. the semantics ofMapacting on an assoc with a default:Map[f, AssocWithDefault[assoc, default]] -> AssocWithDefault[Map[f,assoc], f[default]], what would we do with sayMapIndexed(which is defined on assocs)? There are also other operators for which the semantics of an assoc with default isn't clear. – Leonid Shifrin Jul 07 '15 at 20:06asso /: asso[key_] := Lookup[asso, key, "NoAv"]. P.s. I'd delete everything up to "clarification" :) – Kuba Sep 28 '15 at 10:43asc = <||>;Query[++asc[#] & /@ # &]@{"a", "a", "b", "a", "b", "a"}, compared toasc = <||>; Query[++asc[#] & /@ # &, MissingBehavior -> None]@{"a", "a", "b", "a", "b", "a"}. The default setting ofMissingBehaviorisAutomatic. – SquareOne Sep 28 '15 at 13:45