Stepping Back

This is an essay in the Rewriting History series. Please read at least Introducing Herodotus and Rewriting History before proceeding.

The Challenge

Start moving towards Herodotus-qua-platform. Quit focusing so much on Erlang source code. The last essay was too Erlang-centric, whereas Herodotus and Thucydides are meant to be platforms themselves. Therefore, I'll be moving to a new notation for this essay, and hopefully it will hold.

The Changes

Before going on to the syntax, I'd like to explain some recent changes to the semantics. In the development of the RPS military simulation, I encountered some semantic knots of Herodotus that I thought were worth untangling. Mainly, I looked to simplify, improve, and more completely define the matching rules.

A Match Made in Heaven

The new matching rules are much more strongly defined, and are described below. The match selector is represented by Try and the value to check against by Value.

Atoms

Atoms are indivisible, distinct values, like symbols in Smalltalk or atoms in Lisp. Numbers are also treated as atoms. They are written as atom_name. They match against the three types in the following ways:

Atoms

Try == Value

Tuples

Try matches some V in Value

Lists

Try matches some V in Value

Tuples

Tuples are simple data structures. They are written as {el1, el2, el3} and any element type can be placed in them. Their meaning is roughly "all", and they match against the three types in the following ways:

Atoms

Some T in Try matches Value. This is a minor exception, but it's there for convenience. The other possible behavior is virtually useless.

Tuples

All T in Try match Value

Lists

All T in Try match Value

Lists

Lists are sequences of values. They are written as [el1, el2, el3] and any element type can be placed in them. Their meaning is roughly "any", and they match against the three types in the following ways:

Atoms

Some T in Try matches Value

Tuples

Some T in Try matches Value

Lists

Some T in Try matches Value

These new matching rules have two interesting consequences:

• There's no longer any reason to distinguish between type and context. There is now only "context".
• Simulation designers have much more control over context definition and selection.

In short, it allowed me to simplify and more easily explain the matching rules, remove a fair amount of closely similar code, reduced the amount of work to be done by a simulation designer in the simple case, and permitted much more complex and interesting queries and definitions at a stroke.

This semantic change is the most significant improvement since the shift to Herodotus/Erlang.

Just Cause

Another semantic addition to the tools available in Herodotus/Thucydides is the concept of causality. A "Follow" is a simulation construct which describes cases where one or more incident archetypes can be triggered based on specific previously triggered archetypes, one or more conditions, or both. A Follow also describes how bindings are obtained for the incident to be triggered and the requirements to be checked. Finally, a Follow encodes some information about when it begins checking said conditions, and for how many units of time.

The semantic of Following is slightly more complex than the above lets on, but this understanding is sufficient to be able to talk about it. Another feature implemented alongside Follows is time. Simulations now maintain a "current time" which can be ticked forward by clients to arbitrary points at arbitrary resolution. Backwards ticking and Follows have not been thoroughly tested and, frankly, the semantic is unclear. I recommend against combining Follows with time travel. If a simulation has need of such a feature, it can be implemented in Herodotus client code.

Syntactically Delicious

What the above semantics, along with past work, indicate is that any syntax for Herodotus must include the following:

• Fluent selection and querying
• Reasonable operations over dicts, tuples, lists, atoms, and numbers
• Fluents, including optional arguments
• Cancels
• Incidents
• History selection

And any syntax which expresses Thucydides must cover the above, plus:

• Fluent archetypes
• Incident requirements
• Incident archetypes
• Follows, including binder syntax

So, let's split the work into defining two small, specific languages:

• Herodotus Query Language (HQL)
• Thucydides Simulation Definition Language (TSDL)

Further, we'll posit that a set of simple operations on dictionaries, tuples, lists, atoms, and numbers is available to all of those languages.

The rationale for splitting the grammar this way is that HQL is meant to be used not just within a simulation or fluent definition, but also independently by client code, and the TSDL is how a client defines a simulation with archetypes, requirements, causality rules, &c. Certainly, a subset of TSDL could be defined which only considers archetypes; this can be called TADL, or Thucydides Archetype Definition Language, and would be useful to client code that doesn't wish to use Thucydides's causality mechanisms. Since Erlang is a little obtuse to the unfamiliar, a set of small, specialized domain-specific languages will be introduced.

history-name fluent-type start end args
  

history-name:fluent-type@start--end&args
  

q(history_name, {fluent_type, start, end}, args)
  

NetWorth = q({{value, q({{assets, bill}, 10})}, 10})
  

%in local client code:
hql:s(stored_query_1, fun() ->
  %...hql statements...
end)

hql:s(stored_query_2, fun(Arg1, Arg2) ->
  %...hql statements...
end)

%or in a .hql file for local or remote clients:
stored_query_1():
  %...hql statements...
  .

stored_query_2(Arg1, Arg2):
  %...hql statements...
  .
  

q(stored_query_name, args)
  

Labels: herodotus, theory

Joe Osborn 2008-04-21