State

Persistence is a pretty central issue in programming in general. Let's assume I'm writing a family of scripts that will be used to interact with a particular set of issues, say (oh) invoicing. One of the things I've been mulling over is that if there is information missing for a given job, then invoicing can't proceed until that information is filled in. The action of filling in is thus a blocking action.

So far, so good.

But once I've come up with some actions, I have two options: toss it all, or save it to state. The benefit to saving to state is that if the state is human-readable, I can always write addenda to the state (say, filling in the missing values) that the script can then read in next time. And of course the state can be shared between processes and so forth.

Is that worth enshrining in the language? I honestly don't know. State is similar in this aspect to configurations, and naturally the database is also a form of state (or that is, can be used to save it). With state comes the concept of sessions, which can get arbitrarily complex.

How much goes into a language like this? I want to put everything in that's general enough that it recurs in different problem domains, and it seems that things like configuration, state, command line handling, and so forth meet that criterion.

So a state tag is going to declare persistent values of some kind. This will be the second collection of tags that require an extensible structure (the first being the database tags), because state could be:

• A node written to a file
• Something else in a file
• Some database structure
• Some combination of other persistent structures
• Anything else

So we need a driver system. Especially the "some combination of other persistent structures" deserves some careful thought, too.