The talk went well, thanks. Going to post here with a link to my blog recap, which in turn has a link to the video for anyone interested.
Let me see if I can explain what I’m talking about in simpler terms.
Let’s say I want to add two numbers, right? If my programming language has “numbers” and “adding”, I’m a happy camper. I can do something like 1 + 3 and expect to get back 4. Now imagine it didn’t have “add”. Imagine it only had loops, and increments, and numbers.
I could implement “add” myself, by doing something like
loop(3,increment(1)). Ultimately, I’m going to get the same answer. But it’s harder for the programmer, and it may have other negative effects.
The problem comes down to the question of “are the abstractions that I’m used to using in the domain that I’m trying to model, in this case, legislation, available to me in the tool I’m using to do the modelling, in this case, a programming language?”
For example, laws have “rules” in them. What kind of rules? Well, more specifically, they have defeasible rules. Just because one rule says “if you are a minor you can’t write a will” doesn’t mean that there isn’t some other rule that overrides it by saying “notwithstanding being a minor, a member of the military can make a will”.
So “defeasible rules” is a thing that exists in legislation. Whether or not it exists in a programming language matters for what the experience of writing the code is like.
There is a language called Flora-2 that has defeasibility, where I might encode those two sections like this:
@rule1
?X[can_make_will->\false] :-
?X:Person[is_minor->\true].
@rule2
?X[can_make_will->\true] :-
?X:Person[is_military->\true].
overrides(rule2,rule1).
If I wanted to write that code in an identical language without defeasibility, it would look more like this:
?X[can_make_will->?Value] :-
if ?X:Person[is_minor->\true,is_military->\false]:
?Value = \false,
if ?X:Person[is_minor->\true,is_military->\true]:
?Value = \true.
That’s not as good, because now my code doesn’t know anything about where the rules came from, and it can’t explain itself in terms of what the rules say. It also makes the code harder to maintain, because I don’t know where Rule 1 is, and I don’t know where Rule 2 is.
So that’s an example about how whether or not the programming langauge has “defeasibility” as a feature is important, because defeasibility is a feature of legal language.
To generalize that, we can say that the features present in the modelling language should model the important features of the legislative text. “Important” here means the presence or absence of that feature in the coding language is going to have some corresponding positive or negative effect on the quality of the encoding, the capabilities of the software, the efficiency of the encoding process, or something else the programmer cares about.
Some of the things that I know are important are:
- disjunctions (languages without an “OR” operator require a lot of duplicate code)
- defeasibility (languages without exceptions require reformulation that makes it harder to write the code, harder to explain the code, and harder to maintain the code)
- dates and times
- math, and arithmetic
- logical implication
- etc…
So what I’m wondering is if anyone has done a survey of the logical/computational features present in legislation, that I could use as a starting point to discover what else might be worth looking for.
Let me know if that helps, or if I have just made things worse. 
