CatalaLang/catala: Programming language for law specification
github.com
github.com
I don't disagree with this assumption outright, but it's certainly not obvious to me that it is correct, and the authors appear to present no arguments supporting the same.
As someone who is familiar with the process of turning statutes into code, I can appreciate what this project endeavors to do, even if the value is limited to providing clarification for software developers.
I think this is closely related to rule of law too. Per https://www.britannica.com/topic/rule-of-law
> In particular, laws should be open and clear, general in form, universal in application, and knowable to all.... The law should... comprise determinate requirements that people can consult before acting, and legal obligations should not be retroactively established.
What are the benefits of ambiguous laws?
That they can deal with the massive amounts of ambiguity & blurred lines / grey areas the world has to offer. Too many of our everyday concepts can’t be expressed rigorously for a formal encoding & determinate decision process - a famous example being obscenity’s famed “I know it when I see it” definition - and many are highly context dependent.
And they are ambiguous: "beyond reasonable doubt" is what, as a percentage, in your view?
Freedom and flexibility. Reality is infinitely complex, trying to encode real world problems 100% accurate into code can only work by rounding a lot, with the result of oversimplification with the result of lots of "unjust" rulings, when you do not take the intent of the law into account, but only the words. We have this problem already (a lot) many things that seem very wrong but are legal by the letters of the law.
(Mobsters being released because of formalities for example, even though everyone knee they were guilty)
However, a lot of ambiguity, underspecification, and just plain sloppiness in language is there for no good reason and causes problems, and it would obviously be a good thing to get rid of that.
100% agreed. When clear (and simple) rules are possible, vague rules just create opportunities for shady things. And yes, we have many, many laws that could be made simpler and therefore more clear. And if a programming language can help with that, that would be awesome.
Whose freedom is more important? The people's, or their rulers? If you believe in enlightened rulers, you may legitimately conclude the latter, but for the rest of us, we'd rather the government be properly constrained. After all that's why laws are written down to begin with, it's why there is such a thing as the professional lawmaker.
Vague law is usually not written due to some deep philosophy of law making, after all. Nobody really tries to defend it in practice. It's almost always a result of lazy or politically contentious lawmaking when the people writing the laws don't really know what they want in the first place, so trying to divine their intent will never get you far.
It does, because if laws want to cover every case, they need to be so verbatim and rule out so many possibilities, that in the end, every action is encoded in law, which will result in people only doing things that are explicitely allowed. That limits a lot.
Simple example, despite being an adult, I like to climb trees. And sometimes also in parks. So I had discussions with officials or or wannabe officials about: is this allowed? It turns out, there is no rule allowing it. But there is also usually no rule forbidding it. But most people default to, if it is not explicitely allowed, it must be forbidden (which is a very german thing, but is not unique to us).
Michael de Montagne, a old french philosopher who is also quoted around this thread, put it way better in words. I try to find the passage.
I think this is truly awesome.
Every law should be written in a language like this, and presented publicly with syntax highlighting and consistent formatting rules.
Then it should be made part of the school curriculum to learn the law language.
I believe it would greatly improve everyone's ability to read laws and be confident about their understanding of them, which would be a huge boon for society.
For instance in the U.S., the Westlaw search engine for legal cases is such a tool, it can parse legal citations and turns them into hyperlinks. It rankes cases given a query based on a state-of-the art machine learning based IR method, and it is aware of cases in the ranking that are currently overturned by higher courts (shown as red flags) or being reviewed (shown as yellow flags).
The software can also predict the outcome of a legal case and recommend courses of action that makes winning more likely. It includes ruling statistics about all sitting judges.
Curiously, lawyers like to see the world as static, they do not like e.g. search results to differ between sessions, but of course cases get decided dynamically every day, which must necessarily also change the search results for any given query.
If people want to see what is the state of the art in AI and the law, I recommend you have a look at "AI & the Law" (ICAIL, the annual conference and the journal of the same name).
The judiciary should keep it up-to-date.
In reality, laws are already written in a relatively normal language, and the words almost always mean exactly what they mean in plain English. The only problem is that the legal concepts they describe are themselves complex, and often they end up in a tangle of references to other laws and regulations and legal precedent etc.
So instead of full-on jargon, legal texts get enshrined phrases, which practitioners can essentially skip over, but which also retain some meaning in plain English (though often sounding antiquated).
The CEO (a lawyer) claimed that the lawyers who wrote these things would deliberately and unnecesarily overcomplicate them so that they could maximize billable hours.
I think they could quite easily have been templated using a DSL but that DSL would need frequent maintenance. These types of contracts did evolve as new types of clauses and legal constructs popped up and gradually evolved from "new" to "standard" to "boilerplate".
The problem than becomes that anyone who wants to understand the contract now has to read not just the contract as written, but also all of the definition of the DSL itself. This can actually be OK if the DSL is very commonly used, such as a DSL for contracts between two parties which sign new contracts every day.
But it is a huge waste of time for parties which rarely sign contacts, and is often used as an explicit moat to keep laymen from participating. If I give you a contract to sign that isn't even written in plain English, you will have no choice but to hire a lawyer specialized in understanding this contract DSL to advocate for you.
I imagine (savvy) lawyers actually love DSLs that purport to make contracts concise.
A DSL is an extra layer of abstraction above that. If you agree to a contract written in some DSL, then you must also agree to the way that DSL translates into plain English. To significantly compress a legal contract that is not deliberately written to obfuscate its meaning, the DSL has to pack a lot of precise meanings into every term, making it very dense and hard to parse unless you're well-versed in it.
The customers in our case did not actually look at the DSL - it was entirely internal. We decompiled the legal document into the DSL so that we could then represent the contract in more understandable ways.
As a fun exercises, try to find how many definitions of “child” there are in the US law and how many times it’s used undefined.
Note that the legal system is indeed a huge mess, but that happens because of many other reasons - not a problem with the wording or vagueness of the law, but with the explicit (malicious) intentions of law-makers, judges, police and others involved in the whole process.
For your example of "child": how often does it actually cause a problem in practice? How many people have been improperly punsihed/set free because of a poor interpretation of the word "child" in a specific law? This is far more relevant than every law taking up valuable space to define what such a common word means.
This is the real advantage of codifying law into a programming language. You can have validation and assertion that is automated. And a strict structure, free from ambiguity.
As an additional advantage, multilingualism becomes more accessible, with the codified program/definition acting as the lingua franca of law. Thus, someone who only knows English could make sense of Japanese laws by reading it.
The text of the law is meant to be understood by the people that it applies to, i.e. everyone living in the locality which passed said law. Expressing law in a formal language goes directly against that goal. Imagine if a EULA you get presented with, instead of being a wall of repetitive text, would be a wall of code with symbols you at best remember from some class you took in 8th grade.
For one, it'd make them a lot shorter. You could use inheritance or composition to refactor out repetitive boilerplate, which is 90% of what EULAs are. The thing you see would only be the places where it deviates from a base EULA that you could study once.
For another, it would catch bugs automatically. I have caught bugs in contracts drafted by lawyers a bunch of times, just by reading them carefully. For example numbers that are stated in both words and digits but they don't match. References to clauses that no longer exist. Statements that are contradictory.
A properly written language could be compiled to English for people who for some reason can't read the "real" language. But a well written PL for law would be quite readable.
All of the rest of what you mention could be achieved with plain language contracts exactly as well. Nothing prevents the software industry from getting together and producing a base EULA that all others refer.
Except of course for the fact that it would be utterly impossible to convince companies to agree to such an endeavor, whether in code or plain language or any other way. Especially since the purpose of EULAs is not to be clear, but to confuse end users with verbiage.
And I have heard lawyers explain that sometimes ambiguity, in contracts at least, is a good thing as it reduces the amount of a priori negotiation for low probability events. The the low probability event happens and the contract is ambiguous then you negotiate at that time and maybe sue.
And for laws, I think a bit of flex in the system probably would be a good thing. Give some scope for local judgment an autonomy to the people closest to the situation.
How many improperly punished people is good enough? How many cases go to Supreme Court because the amount of needless ambiguity just adds up, one word at a time?
> This is far more relevant than every law taking up valuable space to define what such a common word means.
Right? Why do many laws redefine it?
And no, cases don't often make it to the Supreme Court because the wording of the law is ambiguous. They make it to the SC because the parties disagree on legal principles and on whether laws are unconstituional or not.
> Right? Why do many laws redefine it?
I would have to see some specific examples to judge for myself. Still, this seems to be the opposite problem compared to what was raised earlier. So which is it? Do we want laws to be more explicit about their exact definitions of words, or more implicit?
I'm not from your legal system, and yet even I know that's not right: they make it the SC because the 'losing' party disagrees with a lower judge's decision that's already been made, and makes an argument compelling enough in appealing it that it needs to be reconsidered. (A few times, to get as far as the SC, probably.) That almost has to be because of some 'ambiguity' - the lower judge decided one way and the appeal is 'well no I don't think that's the correct reading'.
But cases that go to the Supreme Court of the United States are often cases where the "ambiguity" is on how the US constitution should be interpreted and applied.
In a practical sense you're not going to be able to codify the US constitution into code. It's even a well received "feature" that constitutions are sometimes a bit ambiguous, see: https://en.wikipedia.org/wiki/Living_Constitution
Also, appeals essentially mean that at least one of the parties believes that a judge made a mistake in the way they applied the law, not necessarily that the law itself is ambiguous. A judge can fail to apply a perfectly unambiguous law, or at least a plaintiff can believe that they did, and can bring enough evidence that their belief has some merit.
I don’t see how those are exclusionary principles. Also, I have never heard about this case, but after some simple googling I learned that the Supreme Court indeed had to figure out the definition for children in a particular law: https://berkeleysolicitors.ie/supreme-court-determines-defin...
> Still, this seems to be the opposite problem compared to what was raised earlier.
No, it is the same problem I mentioned before: some laws define it in a contradictory way; some laws don’t define it. I told you it’s a fun exercise!
> Do we want laws to be more explicit about their exact definitions of words, or more implicit?
I want laws to make sense. Inconsistency doesn’t make sense and only brings troubles. Vagueness is good. Ambiguity is bad.
Common law has like 800 years of tech debt. It's turtles all the way down. And by turtles I mean precedent, and not all of them are compatible.
None of what I've described is malicious. It's just what happens when law meets the messiness of the real world.
Which is why it is the common standard in German law to define every possibly unclear term either in the relevant section of the law itself or in an introduction article.
The latter is better than the former, but it also makes it even harder to interpret sections with no definition.
I don't see how a language is going to solve this. This isn't really an issue of language, it's an issue with ambiguity in the very intent itself. That's why we have judges, who interpret that intent.
Relying on ambiguity is admitting there are no laws, and we rely on the common sense of the people in thr judicial system.
What's better:
- relying on the common sense of the people in the judicial system to interpret the intent of the law as it applies to a particular situation,
- or relying on the common sense of legislators to write a precise, unambiguous law that will cover all possible situations without negative unintended consequences, and without the law-writing process being influenced by spureous interests and pressures?
The answer highlight why the law is interpreted as is now, with a body of trained public servants analyzing the particulars of each situation, rather than by fanatics trying to follow the letter of the law.
Languages like this may help clarify the intent of legislators so that it is not twisted by clever lawyers; but a human reviewer should always check the relevance of one law to any particular case, and wether the text corresponds to the original intent as applied to a given situation.
Judges and juries and lawyers all exist to help us interpret the inexact legal code in a way that is (hopefully usually; but obviously not always) fair and reasonable given the often-nuanced situations at hand.
Law is political. It's persuasive, not deterministic. It often comes down to a judgment based on the relative political power of the entities in question.
Even if you find a statute that says very clearly that X is unlawful, there will be situations where a lawyer will argue that it isn't.
Sometimes they'll make that case successfully - for various possible reasons, not all of which will be lawful themselves.
This is one reason why statute law is expanded by case law. And good luck trying to automate case law.
Being a mess riddled with inconsistencies is not a feature.
Still I'd argue that normal language is very poor at handling that tangle of references.
A good programming language would make those references very easy to untangle and present in their untangled form.
When I've read (Danish) laws, I've often thought that they would read better as if statements.
It's not that I think those laws are written in legalese, it's that they are expressing logic in a suboptimal way. Like how "four plus four equals eight" is a suboptimal way to express what could be expressed with 4+4=8.
Not necessarily. Notation can only do so much to help with understanding. To understand 4+4=8 you still need to understand what's a number, what addition means, and what it means for two numbers to be equal. The same problem applies to the law, and it takes far more time to understand legal concepts than the actual wording.
Additionally, the law is not supposed to be some arcane discipline that you need to learn a new language for. The law is decided on by, and applies to, people who are not and have no reason to become legal experts. It is simply a statement of the rules by which we try to live.
If laws were written in code, they would actually become much, much harder to understand than they already are for the vast majority of their audience. Imagine a public debate about a law where the text of the law was, instead of plain(ish) English, Haskell code. Imagine news anchors explaining that Biden agreed to add the lambda sign, but was heavily criticized by McConnell for his use of a monad instead of a plain for loop.
It would seem to me that reading laws has become an arcane discipline, partly due to it being expressed in a language with overly long sentences, which handles branches and references very poorly from a readability perspective.
> Imagine news anchors explaining that Biden agreed to add the lambda sign, but was heavily criticized by McConnell for his use of a monad instead of a plain for loop.
While that would surely be interesting to watch, I think we both know that's not what would happen.
Like I wouldn't ask you "number four plus sign number four equal sign X?"
And if the actual text of the law consisted of coding symbols, I very much expect that (a) you'd have endless debates about the precise symbols being used, and (b) have to have anchors going over the meaning of those symbols and losing 9/10ths of their audience along the way.
The problem here is the length and complexity, not the language used to express the contract. And note that law-as-code would necessarily mean that a layman is fully unable to understand a contract (or the text of a law) at all. They would be fully reliant on a specialized worker to explain the code to them in plain English. Current contracts, if you have the patience to read and map them in full, are fully understandable by anyone with a good knowledge of the English language.
You could even program the "law-in-code-to-humanspeak" translator to generate different levels of the target languages, e.g. translate into something at a 6th grade reading level vs. something at a grad school level. Again, the advantage would be the automaticity.
Don't get me wrong I'd prefer it too, I just recognise it's a consequence of my own education and experience, and if we somehow flipped the switch overnight most lawyers would be completely baffled and pining for the much clearer old way.
It's all very readable.
[1] https://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Lan...
That's it.
The full scope of what that encompasses is very hard to know, as it depends on essentially every other regulation and common law practice and precedent that applies in the particular legal jurisdiction (and which jurisdiction that is can itself be a somewhat thorny issue).
But this problem isn't solvable by code. It's part of the intrinsic complexity of the legal system.
At the same time, laws have been codified (i.e. the case law rewritten coherently, combining all the patches combined), such as the Uniform Commercial Code.
Especially around temporal events, and that goes to formal models (and even more bugs).
Typically, if there is a rule around height, there would be at least three tests¹: one taller, one equal to, and one shorter. (Without types or something, then also negative, null, and max/min boundary inputs too.)
So you could have tests based on timelines, like
Given a regulation is passed in 3 months
And parties are prevented from exercising B
But "17 tons" of waste are dumped anyway
And ...
When ...
Then ...
Having a model checker integrated would be a boon. Maybe we could have DevOps-like pipelines in formally-verified legislature (or at least the encoding of language to code).Many laws are written with a lot of double meaning (recent eu regulations on allowing or not allowing russian cars is a good example).
Though, it could be a good idea to find all the possible double meanings or vague definition when trying to "digitise" the laws into the programming language.
I'm sure the mentality of a PHP developer running a successful but insane legacy site is a better model for this than a perfect OCAML project :)
Or take it a step further, write a test suite and automatically generate a range of possible laws that satisfy the tests.
End to end tests for legal frameworks?
Once I lived in a state that proposed a very simple anti-child porn law with good intent, but it was too simple. It read sort of like "anyone sending explicit pictures of minors from a cell phone will be guilty of conveying child porn". It was written in the proper legal jargon, but wasn't a whole lot more detailed than that. I called the sponsor of the bill and asked if that meant if my hypothetical daughter sent a naked picture of herself to her boyfriend, then wouldn't she be a felon under his new law? He had an "oh, crap, that's not what I meant!" reaction and ended up withdrawing the bill so it could be re-written. (Aside: I felt pretty good about that. Props to the legislator for being quick to understand and respond appropriately!)
Imagine if that were handled like program code, with a test like:
* This law does not apply to minors sending pictures of themselves.
That would do a few big things:
It would make legislators be clear about what they mean. "Oh, we'd never use this online child safety law to ban pro-trans content from the Internet!" "Great! Let's add that as a test case then." I confess that this is a deal breaker: politicians don't like being pinned down like that.
It would probably make it easier to write laws that reflect those intentions. "Hey, that law as written would apply to a 15 year old sexting her boyfriend! The code doesn't pass the tests."
Future courts could use that to evaluate a law's intent. "The wording says it applies to 15 year olds sending selfies, but the tests are explicit that it wasn't meant to. Not guilty."
I'm sure this couldn't happen for a hundred reasons, but I can dream.
When a statute is ambiguous, courts do sometimes look at the congressional record (eg floor debates) to determine intent.
They are horrible at everything else.
As for test suites and courts - the two are complementary so there's need to compare them to one another.
I personally would be happy if any country would attach rationale for the law to the law itself. And possibly some KPI to see if it works. So the law could be reevaluated later, to see if it works at all, or maybe counterproductive, or maybe some major actual application of the law is not why it was introduced.
Either way you really want intent to be encoded somehow.
It is a thing already. In both the US and Germany it is common for lawmakers and regulators (e.g. the FCC which was here on HN to solicit comments a few days ago) to provide drafts of laws and regulations to interest groups so that these can raise issues they find.
Laws don't need to be computer-executable, they're about intent and the interpretation thereof, so the test suite itself is really part of the law and may as well just be embedded in it.
[1] https://www.aclu.org/news/juvenile-justice/minnesota-prosecu...
Minnesota is so bizarrely, irrationally wrong on that one. That poor kid needs an adult to sit her down and explain why sending out nude pics as a minor is a really bad idea, not to label her as a sex offender. Now, if someone (especially an adult) received those pics and shared them, go ahead and charge that person.
For those who don't know, Greg Bear was a well-known SF author who died less than a year ago. His passing was discussed here at the time [3] [4].
He was one of the authors that influenced my youth a great deal, and I particularly remember this aspect of Moving Mars as catching my imagination, so will be interested to read what Catala has to offer.
[1] https://en.wikipedia.org/wiki/Greg_Bear
[2] https://en.wikipedia.org/wiki/Moving_Mars
But this fails to realize that _ambiguity (in some ways) is a fundamental important part of law_.
This is because the world itself is fundamental ambiguous (in some ways)/clear cut.
Naturally not all ways of ambiguity are wanted.
But you can be sure that with "code as law" the ways loopholes are abused will get worse in my opinion.
I would even go as far that some many laws should be more focused on what should be upheld then the details how (which is fundamental less clear cut/more ambiguous).
I'm not going to argue that's a problem with laws vs. enforcement, but either way, our society is built around ambiguity and unequal enforcement of law.
But about that law, in difference to what movies love to pretend, is not about clever word tricks and nit-picking formulations.
(In court it still can be about clever arguing, including nit picking arguments if necessary.)
But code _is_ about nit picking formulations at least if we ignore documentation, naming conventions etc. but lock solely at what the code does.
Code is meant to be precise.
Law is meant to be only as precise as necessary but no more then that. Or you could say it's meant to be as imprecise as viable.
Code is about the specific case (in general).
Law is about the generic case (in general), avoiding specific cases where possible.
Code is made for machines to consume.
Law is meant to be consumed with ambiguous defined context of the situations in (human) .
This is so deeply rooted in law that I would argue it's (in general, with exceptions) not possible to translate any current laws to code without accidentally changing their meaning in a lot of subtle but meaningful cases.
For all the examples I can think of, the most beneficial outcome is removing the law altogether.
I would have thought that is a good example of a law placing an upper limit on risk in a very black and white way.
Maybe exemptions for passing on single lane roads might be a net reduction of risk but I can’t think of any other grey areas.
through "clear cut" here sometimes still involve an assessment of danger which fundamentally isn't 100% objective
and e.g. in germany you are only allowed to "drive as fast as it's save" even if the speed limit is higher (and that is a common occurrence, e.g. resident areas tend to be 30km/h zones but you have to slow down at nearly every crossing because anything else wouldn't be save and if you do an accident at a crossing driving 30km/h in such a zone you are very likely very much screwed (depending on damage done).
So I guess, yes speed limits in a certain way, too.
- Fair use law (there are thinks which clearly are and are not fair use but in between there is huge gray area where you can not really formulate generic precise rules which work reliable).
- Parent law (which has a lot of issues especially given how it's applied, but design wise you fundamentally have ambiguity about questions like when something is "enough added innovation" to be patentable as fundamentaly "the degree of inovativeness" is purely subjective.)
- Insult, is also very subjective. Define it as "only when insult was intented" would be bad, but similar would be "always when the person felt insulted" and even "if intended and felt insulted" has issues.
- Self defense it's in many jurisdiction based on the person feeling threatened, but in jurisdictions with sane law it also involves stuff like "a generic person would also have felt threatened", but then you still have to consider person specific circumstances.
- or lot of stuff around what counts as insider information, e.g. for insider trading
I agree with your idea that our interest in laws shouldn't focus on implementation details but I think they should focus on outcomes. This requires a method to produce an evaluation function to measure the outcomes of a new law, and a system such as Catala to help model expected outcomes and to help select between competing laws (eg if our outcome = "we want less pollution" then our policy might be "ban polluting industries" or "tax pollution externalities." Both have complex consequences which would be better analyzed automatically and measured empirically.)
No, I don't have a lot of faith in our legal system. Why do you ask?
Are there any lawmakers, lawyers or judges excited about this, or is it only programmers?
From the bottom of the readme:
> The language is named after Pierre Catala
I'd suggest changing it to PierreLang then.
As a native Catalan speaker I was quite surprised with the name! But it makes sense, since it's quite a common surname!
Linting and type checking the existing codebase would also be more helpful than rewriting everything in a new language. Enforcing size constraints on vocabulary and word count. Cross referencing between different legal systems. Throwing out dead laws that are no longer executed in prod. Profiling the efficiency of existing laws to find hot spots.
There’s little incentive to do this when the current system is run by a cadre of highly trained legacy COBOL programmers. I’d pick a very small part of the system — incorporate a new city and start from the ground up — and take it from there with the clear eyed expectation that a full rewrite is going to take a century.
https://virtuale.unibo.it/pluginfile.php/1273247/mod_unibore...
Catala: a programming language for socio-fiscal legislative literate programming - https://news.ycombinator.com/item?id=24948342 - Oct 2020 (37 comments)
AFAIK There's not really a programming language specific for describing how players interact in a game, so although there's no reason you couldn't implement it in any old programming language. I guess the same thing could be said of the law too until Catala.
Having a "compiler" for laws can help identifying conflicts between different codes of law. e.g.: Imagine having a compiler error when a law is unconstitutional from a logical standpoint.
But verifying the "business logic" (e.g.: what is the spirit or intent of the law?) of the law will remain a human intelligence task.
Humans (or, well, AI) is needed to cope with inconsistencies.
That said, pointing out the fact of existence of inconsistencies could be very valuable. But a system needs to embrace them, not fight them.
I don’t think Gödel’s theorems particularly support the claim you’re making.
In fact, here is an argument that a consistent rule-set (either can be extended to something consistent and complete, or ) can be extended to be made arbitrarily large and consistent:
take a ruleset which is consistent, but for which there is something for which it has no prescription one way or the other (neither explicitly nor implied collectively by other rules) (I.e. “not complete”). Then, add a rule specifying that thing and nothing else which isn’t implied by that thing. This will be consistent, as if it were not, then the negation of the rule added would have already been an implication.
This will either yield a larger ruleset of the same kind (consistent and incomplete), or it will yield one which is consistent and complete. Gödel’s theorems show that if the ruleset is an axiom system which is sufficiently expressive (e.g. contains Peano arithmetic) then the latter cannot be the result. So in this case, there are arbitrarily large extensions of the rule-set.
If it isn’t an axiom system, or is one for a rather weak system, then the “the result is a consistent and complete system” option, well, why would you want it to be larger?
Edit: perhaps what you are calling “inconsistencies” are what I would just call “exceptions”/“exceptional cases”?
To my mind, “embracing an inconsistency” doesn’t seem to make much sense in the case of law? Something has to be what actually happens. We (whether fortunately or unfortunately) cannot bring an actual contradiction into reality.
Well, I suppose if one takes a sub-truth(not sure if this is the right terminology? I mean the opposite of super-truth) approach to vague statements, one might say that a somewhat-bald man causes the statement “that man is bald, and also that man is not bald” to be true (and also false), and as such “bring a contradiction into reality”, but that’s not what I mean by the phrase.
I mean there is no full precise-ification of any statement, which we can cause to be simultaneously true and false irl.
Those acting as agents of the law must behave in some particular way.
When legal requirements contradict, people will not satisfy both of them. Perhaps one will be considered to take priority. Perhaps a compromise position between the requirements will be sought. Perhaps it will be left to the judgement of those following it in a case-by-case basis.
But in none of these cases is a contradiction implemented. Can they really be said to be embracing the contradiction?
Upon writing this edit I realize that I’m probably misinterpreting that part of your comment. I suppose the thing you are saying to embrace is not the individual contradictions themselves, so much as the system’s rules-as-written having contradictions, and therefore the necessity of dealing with such contradictions when implementing the rules, as the scenarios to which the contradictory statements apply, occur.
"As the Rules as Code movement gains momentum, questions are starting to be asked about the performance and practical effects of expressing law computationally. This article examines the strengths, weaknesses, and new opportunities of engaging with these emerging systems."
The Future of Coding podcast covered it recently https://futureofcoding.org/episodes/065
The abstract says, "Software code is built on rules. The way it enforces them is analogous in certain ways to the philosophical notion of legalism, under which citizens are expected to follow legal rules without thinking too hard about their meaning or consequences. By analogy, the opacity, immutability, immediacy, pervasiveness, private production, and ‘ruleishness’ of code amplify its ‘legalistic’ nature far beyond what could ever be imposed in the legal domain, however, raising significant questions about its legitimacy as a regulator."
It's a complex paper/topic that I personally need more time to grasp before throwing my opinions around too heavily. But my first, knee-jerk reaction so far is that moving laws into code is a bad idea. Specifically, as the paper says, "...code by its very nature tends toward a kind of strong legalism. This is the case regardless of the intent of the programmer, however vicious or virtuous that may be."
The "strong legalism" inherent in code means "the sovereign’s exercise of power is de facto legitimate, and thus not open to question." Not to be reductive, but that ain't good.
I feel we've seen evidence of this path already, with (easily refuted, but somewhat common) claims like "data can't be biased" (for example). The tendency to blindly follow a computer's dictate with, "Well, the computer says this is so, so it must be so." is strong in our society at times, I think.
https://catala-lang.org/en/examples/tutorial#The%20Catala%20...
> The language is named after Pierre Catala, a professor of law who pionneered the French legaltech by creating a computer database of law cases, Juris-Data. The research group that he led in the late 1960s, the Centre d’études et de traitement de l’information juridique (CETIJ), has also influenced the creation by state conselor Lucien Mehl of the Centre de recherches et développement en informatique juridique (CENIJ), which eventually transformed into the entity managing the LegiFrance website, acting as the public service of legislative documentation.
'à' has a grave accent, not an acute accent.
I imagine that they find their naming choices amusing.
> If the property was acquired by gift [and various conditions apply], then for the purpose of determining loss the basis shall be such fair market value. [emphasis added]
I think (and I'm not a lawyer or a tax expert) that this means that the basis of an asset can have a different value for the purpose of determining gain or determining loss. Wow, basis isn't just a number, although one might not notice this if one didn't read the six emphasized words.
But the Catala code seems to completely ignore this. Oops. I filed an issue:
https://github.com/CatalaLang/catala/issues/514
In a real use case, I imagine that substantial refactoring of the parts that consume basis might be needed when one notices that the basis is not a number.
I was puttering around with the idea of a ricardian compiler for legalese, basically a decompiler for something like this that could compile a legal text into clear logical rules. This would aid in proof checking for legal documents to ensure that they're compatible with existing law, that there are no (unintended lol) loopholes and the like. It would also be useful if you wanted to create self enforcing legal documents that can be enforced deterministically by machines, such as collateralized agreements, and finally, even though someone would still need to know legalese, it could make the development of such agreements easier for people and lower the bar tremendously.
I wonder if anyone has built anything like that, if these guys have, or if anyone has built other interesting ricardian compilers.
Smart contracts are much more comparable to "a webshop", than actual logic describing rules of arbitrage or other concepts at play in "law".
E.g. its not clear if there is an explicit or implicit ontology against which the validity of any codification can be checked.
It would be interesting to train Large Language Transformer Models to generate this code for you based on the text in the laws. This way you have a deterministic testable output, without risk of hallucinations.
But then, the first line of description in Github says:
> Catala is a domain-specific language for deriving faithful-by-construction algorithms from legislative texts.
This reads like 'text -> code', which is the opposite of what this project seems to be doing.
so “and” isnt a list of accepted criteria, it is a list of things that must be simultaneously satisfied
but its only using logical gates most of the time
this is a good step in showing that. not a panacea but a good step!
Is this a joke?
On the one hand, I think it would be fantastic, if you had automated tests for the law. For example, when German politicians introduced the "hacker law", you could have pointed out that "This new law would break the 'security researchers need to be allowed to do penetration testing' test".
On the other hand, "Brexit is in conflict with the Good Friday Agreement, we need a solution for Nothern Ireland." was known without machine readable laws and test, but politicians ignored it anyway.
Maybe what's needed is a law that outlaws test-breaking laws and requires politicians to fix the tests first, but I bet that would just result in a lot of "commented" tests.
an example of the game rules: https://agoranomic.org/ruleset/slr.txt
In the context of this thread, I'm sad that the game rules don't appear to be in a constrained vocabulary
Oh, this again. I suppose this looks relatively harmless, but I'm always wary of "law is like computer code."
The impulse to think this can strongly solve any real problem in the law is intuitively attractive, but I strongly predict this mostly never happens; it's the law's job to be intensely practical in the face of hard-edged "computer-like" rules.
If anything, you get goofy confusion about what things "are?" My go-to on this is always the "smart contract" -- which can be useful little bits of automated robot money moving code, but emphatically are neither "smart" nor "contracts."
They are contracts—just not legal contracts. One of many types of contracts in the world that are not legal constructs.
It's like calling a hopefully-completed-circuit in some device an "electric contract" or something like that.
I think this proves op’s point of goofy confusion for what things are.
Maybe not for lawyers, no. But as a citizen I'm expected to comply with the law, with many many laws. It'd actually be nice if law was slightly more formally verifiable, so it would be easier for me to understand what to comply with.
Being able to break down clauses into more logical normal forms would probably greatly enhance the possibility of compliance.
For every bit of gained clarity, you'd also gain a ton of people like the "sovereign whatever" idiots who just love trolling, with the added negative of them having more "formal proof" of their untenable silliness.
- your compiler was AI-complete and adversarial and hated you
- your compiler was also not bound by any hard rules and could emit undefined behavior at any time
- your job scheduling and orchestration system was AI-complete and adversarial and actively hated you
- your runtime library had 50 different incompatible canonical implementations and can only be run by being forked by publicly-elected officials who blindly merge patches from bad-faith lobbyists
- the documentation for any of those 50 runtime libraries is paywalled per page behind https://pacer.uscourts.gov/pacer-pricing-how-fees-work if you're lucky
- the IDE is Microsoft Word, and the linter is a summer associate on their tenth cup of coffee
- you will inevitably get a non-technical client who thinks that the more times you have "notwithstanding the foregoing" in your code the more you can call yourself Web Scale
There are some areas where automating things can be effective – e.g. tax systems.
Why not just take the existing law, and have a machine execute it in the style of a computer program?
We wouldn’t need judges juries or lawyers. You’d just type the specifics of your case and any supporting documents/evidence into the computer and a verdict would pop out.
Of course, the system could be used for other stuff too, like checking building code compliance or engineering soundness, signing off on military and police action, setting the executive branch’s priorities, and so on.
It is that the law would need to encode all the stuff I said, so it would need to be nuanced enough to replace all engineering, leadership and administration roles. (And also anything involving ethics.)
I see two potential issues:
- Picking evidences. "Evaluating" the law might need access to all the possible evidences that could exist, but that would certainly never be true, so you'd need someone to know which evidences to present. You probably cannot rely on some interactive process asking you such and such evidences because it would be presenting evidence that would trigger evaluations of chunks of laws. I would guess a lawyer with good knowledge of the law would probably be needed for this.
- Setting precedents. Wouldn't the "automated" law evaluation run into unprecedented cases all the time? You'd need someone to constantly issue a verdict on unforeseen situations all the time, and I guess you'd need a judge for this.
Maybe it could work on many "trivial" cases though.
Some elements of law are amenable to translation into source code, and indeed anyone working in fintech will probably have done that at some point. If the law gives a threshold for a tax allowance, for example, you need to encode that requirement in accordance with the law. Being able to mark up the text of each regulation should make it much easier to be confident you've not missed anything.
Trying to write non-financial regulation as code is pretty much doomed to failure. But to the extent that tax or benefits regulations set out numbers that we have to translate into code anyway, it's good to have that code be verifiable against the specific regulatory text.
"To a man with a hammer, everything looks like a nail." (Twain?)
Hasn't Cyc impressively demonstrated just how incredibly difficult and costly it is to formalize even the most basic matters of daily life?
There already was a discussion two years ago: https://news.ycombinator.com/item?id=27059899
I would offer that the "cost/benefit" analysis for such a formalism exists on at least two axes: the concept domain which one is attempting to formalize, and the benefit (and/or size of consumers) of any such working system
I can wholly understand that trying to translate the entirety of English into a formal logic system sounds overwhelming. But to side with a sibling commenter, why not at least start with the tax code which is a personal pain point, has (presumably) a correct outcome for some cases, and is mostly algorithms-in-English
And then, for the consumer side: ok, if I snapped my fingers and Cyc existed and worked I struggle to think how exactly my life would change. If the formally-specified tax code existed and worked I wouldn't have to rage-upvote almost every comment on the annual tax hatred thread
I would even offer that an incomplete version could still be useful if one left "fuzzy" variables in the corpus, and said "welp, we can't define what a $Person is because of the hundreds of years of precedent, so you'll need an actual Judge for that". I don't meant to say that 50% of the corpus can be undefined variables, that's just silly, but I'd hope the tax code isn't built upon 50% undefined behavior, even if accountants want you to think it is
There have been many such attempts (e.g. NKRL by Zarri et al., also funded by EU). There are even societies that have been dealing with such issues for many decades (e.g. http://www.iaail.org). The formalization of law and language is only one of the issues. Like many previous attempts, this one suffers from the fuzziness of human language (even in the case of tax code). Fuzziness is not a drawback; it is what makes it possible to communicate efficiently in the first place. In order for us to communicate effectively, we need an enormous amount of tacit knowledge about our environment that our culture and life experience brings. If one tries to formalize the language, as in the present approach, one must also take this knowledge into account, down to the last detail (an "upper ontology" is by far not sufficient for this, and Cyc after decades is still not finished). And the tacit knowledge and also the moral valuation of the same change over time. And there are things like https://en.wikipedia.org/wiki/Sorites_paradox which stand in the way of a complete formalization. Lenat's 1990 book addressed many of the issues, but also his more recent talks are very informative where he demonstrates how they had to extend the Cyc representation language to cope with the problem, and why e.g. RDF triples are not enough.
The reason we have courts and lawyers is because of the need for interpretation beyond just writing good logic, so I don't see how this can really do anything. Or is it for something else?
I'd argue that the imprecision of law is more feature than bug. Rules as written have edge cases and, as long as the law is written in natural language, you can get a feel for their intent and that helps Judges decide what to do in those situations.
- help in quickly testing whether newly drafted laws contradict existing laws(without needing to memorize the existing legal code)
- check for redundancies
- checking whether removing one law affects any others
- statistically analyze legal systems in different countries
Assuming any of those are important issues in law. I'm not sure
Examples of how this could be useful:
- Reducing the overhead for maintaining a list of semantic translations of that legal code into other languages. Of course the official language is the only one that is "legal" but the other translations should be close enough to effectively express the nuance provided the language outputs are maintained by people who can actually speak those languages.
- Producing machine executable proof or simulation code. This could be used for "fuzzing" the legal code to identify loopholes or unintended outcomes so that legislators can then propose improved terms to avoid those issues. This is by no means "making code law" but it provides an additional tool for understanding the law and how the many different parts of the legal code interact with each other.
- Adding on to the previous example, sim code could be integrated into complex models for simulating the impact of legal changes on the economy at large or specific segments.
- Finance related code can be used to generate a tool or API for validating tax, accounting, and compliance documents (as a first pass to catch errors early and reduce overhead) as well as to even prepare some of those documents. These tools often already exist but they are one or more steps removed from the actual legal definition which increases the risk of error as well as the overhead of maintaining them (which can potentially encourage rent seeking behavior by commercial providers of these tools).
France actually is already doing this to a reasonable degree albeit the "codified" version is based on the law rather than the codified version producing plaintext law. The DGFiP [1] maintains a gitlab organisation [2] that includes both Catala and MLang [3] representations of different parts of the french legal code for exactly these purposes.
1. https://fr.wikipedia.org/wiki/Direction_g%C3%A9n%C3%A9rale_d...
If only! Here in Canada there are two official languages. All laws are drafted, and enacted, in both English and French. Both versions are equally valid, equally binding. And, sometimes, they don't say the same thing.
Example of text law that should/may become code somewhere: the senate vote to give pension to veterans that meet some criteria… But there already exist less known rules for some cases and they may be incompatible.
I think that coupled with some kind of prolog, it may help detecting inconsistencies early.
Imagine someone creates a programming language called Russian. Good luck googling "russian lang".
Yes, but did they know that català is Catalan for Catalan? In French, as in English, it is catalan instead (well, English always capitalises it, French doesn't, but the spelling is identical).
Treaties can be written with vague wording to allow parties to sign it, even if there isn't 100% agreement. That's an old practice.
Imagine that you have an income tax where "income" isn't clearly defined. Someone will end up with an audit and a lawsuit from the tax office because their definition will be, of course, extensive (every income, including non-realized capital gains) whereas most citizens would only consider salaries.
In the end, you create legal uncertainty, and give courts way too much power.
For the record, I used to work for my country's government, and had to evaluate some laws in making that were written in an abstruse way. When I asked why, the civil servant told me that it was so "they could pick the most favorable meaning in the case of a lawsuit".
So there are different tiers to deal with this.
- Constitution - Very abstract and very rarely changed.
- Statute - Sometimes abstract, sometimes specific.
- Administrative rules. Very technical but still intended for broad application.
- Individual court cases. Can be hyper specific.
Programming tends to use less understandable but more precise verbiage in general.
And then there's the distinction between lex and ius that I think needs to be considered in this context.
It just seems like a bizarre decision that can't be a benefit at all and can only have negative consequences. Just googling things about it is going to be hard. Why immediately create potential problems for yourselves when you can choose a name that's not an issue?
> Just googling things about it is going to be hard
when you're looking for docs on go do you google just "go"?
edit: fine, it's called catalá in catalonian itself - this is so pedantic now that i might as well at this point say that the missing diacritic is sufficient to disambiguate.
This is obviously a not innocent choice. At this level I don't believe in coincidences and CatalaLang makes it even more obvious. This looks like a veeeery obvious psy-op, or a independentist version of the old embrace, extend, extinguish.
My bet is that as they can't stomach the basic legal concepts, they will try silently replace it by the new "updated" meaning of those concepts.
Golang will do the trick. Catala lang will not unless the language becomes massively popular.
I wouldn't use Go as a good example of naming a language. It worked out because the language had the weight of Google behind it, but it's still awkward that you have to use a different name when searching for things than you do at other times.
this is called the no true scotsman fallacy - "I'm still right in XYZ case because XYZ isn't a real instance of ABC (the thing I'm making a claim about)"
All I said is that Go, specifically, is an awkward name that probably shouldn't be used to justify further awkward names.