Tabular Programming: Counting Coffee

Oft-times, it's much easier for data to undergo one transformation over another.  Output is normally
easier than input.  Rather than parse something, it can be simpler to serialize and work exclusively
with that representation of the data, depending on how unstructured and well-formatted such data is.

I keep meticulous records of my life, including what I eat, which is represented as a list of human-
readable descriptions.  For example, my coffee consumption for a day may read ``six cups of coffee''
and I'm careful enough to use a usually consistent format for such records.  The fact that I already
know roughly how much coffee I drink in a day is irrelevant; it could be interesting to know exactly
how much I drink, but this requires either laborious manual calculation, or a program for this task.

A fool's first thought would be to take my format and inscribe it into code, but I don't always know
exactly how much coffee I've drank in one day, so sometimes an entry may read, say, ``seven or eight
cups of coffee'' and such a basic human variation would make the fool's task all the more difficult.

There's only one proper way I currently see to solve such a problem: Search a trie by description to
find the proper amount of coffee described, and ask a human operator when any unknown description be
encountered.  This simple way is obviously correct, so long as the descriptions match their amounts.
It's even trivial to load that trie with the first however many basic entries, showing serialization
to be easier than parsing in this example.  I provide a Common Lisp implementation of such a program
beside two Ada implementations, one trivial and one more useful by saving answers for multiple runs.

This in a way fails to capture the extent of my coffee drinking, as I'm not bothering to count other
kinds of coffee I drink.  These descriptions are reserved for my usual French press coffee, and that
from my moka pot is recorded, say, ``four cups of Americano'' but how to count those too is obvious.

Notice how reversing each description before using it with the trie would result in storage savings,
although too small and unimportant here to justify it, but worthwhile with a larger, serious system.
Notice too how the natural numbers are that proper domain for this system, for not every description
is relevant to the question at hand, and giving to such descriptions a value of zero solves it well.

My ten-month data file is in a format suitable for the Ada implementations and trivially transformed
into a list of strings for the Lisp.  While I've grown to like Ada over Lisp, I admit that Lisp here
was more pleasant to write and use, despite its inferior trie, due purely to its image-based nature.

After a measly forty questions I had an answer.  For the uncertain descriptions, I have a confidence
convention with how I list the different figurings.  Regardless, I drink roughly six cups of coffee,
each day, though I already knew this to be true; in any case, it's fun to have more precise numbers.
.