Obviously it would be great if this caught on, but it's not even widely understood/agreed on that read-time precision is a desirable quality in a legal system. This is something almost everyone here takes for granted; we want the interpreter or machine to give the same result for the same input. We want that property so we can know the run-time behavior during development.

There are judges and politicians in the US that advocate for various "interpretations" of laws including parts of the constitution, which are different from what the law literally says. In fact they refer to the literal meaning as the "literal interpretation", implying it is one of many valid interpretations, and casting doubt on the idea of language having a precise meaning. The crowd here knows that it is totally possible and often invaluable to work in languages with precise meaning. Anyways, in practice this means: all the steps happened for the law to get passed by the legislature including arguing about the exact text, and instead of enforcing it as written, the judiciary enforces some slightly different but similar law.

A technology like this necessarily concentrates power in the legislature, and takes it away from the judicial system. It concentrates legal power at write time and removes it from run/read time.

Catala is specifically for tax codes and other laws that involve formulas and calculations, not all laws, so I don’t think most of your concerns apply to it specifically. There are often complicated rules governing how, e.g. benefits or tax credits are calculated that natural language is clumsy at expressing, so having a formal language that encodes that logic seems useful.

I agree government/justice by algorithm would be very dangerous, but Catala does not seem to be that.

It’s also the case that the massive set of constantly evolving case law is akin to the most convoluted and buggy “libc” ever implemented, running on a system where random bit flips occur frequently. Any lawyer who says they know how to definitively encode an assumption is inherently making a probabilistic statement colored by their own experience and definitionally limited exposure to case law - it may be near perfect, but it exists in an imperfect runtime environment.

This doesn’t mean that this isn’t a useful tool as an aid for interpretability. And perhaps we can reach a point where ambiguity in case law can “propagate” through a graph of nodes to give a range of answers to any question about a regulation - perhaps with the aid of LLMs. But until we have such a system, it can be dangerous to draw conclusions from systems like this one.

(Not a lawyer, this is not legal advice.)

> "interpretations"... which are different from what the law literally says.

We have to remember that the letter and spirit of the law can grow apart over time, and loopholes are often gamed before that naturally happens anyway. So obviously we still need judges to keep the "spiritual" aspect of intent alive, so that evil isn't laundered through technicality.

"Literal" should really be a concrete thing, but it does feel strangely connected to a problem that has existed since Sola Scriptura, up to Gödel's theorem. I think about this everytime software and law collide. That article on "what color are your bits"[1] also comes to mind.

[1]: https://ansuz.sooke.bc.ca/entry/23

I have a potentially more optimistic (and simultaneously more pessimistic!) view to offer.

Some differing interpretations of the law distinguish between the lawmakers' intention vs the literal meaning (and keep in mind that language itself changes a lot in just a few centuries. The hard problem is that, in PL terms, the law is written in syntax without agreed upon semantics. So a decent step could be just using some agreed upon semantics, like we do in code! Then at least "interpreting" it would be unambiguous.

Maybe a decent analogy would be gcc vs clang might produce different programs for certain undefined behavior, and different combinations of pieces might lead to different behavior too (like race conditions), and somebody (the plaintiff/user) is asking you (the judge/compiler) to decide what's going to happen in this next loop/program/whatever.

Or maybe a decent analogy would be getting a ticket that the API is erroring in some rare user's case and having to look into the code and stacktrace to realize it's some weird unanticipated interaction between two different pieces of legacy code (150 year old law) that now interact due to a recent merge (a new law from last year), and now it's crashing, so we have to figure out how to interpret/compile/resolve this user's case.

If law was usable like code, we'd never have any of those issues, just like we never have those issues with actual literal programs. And when we do, it's just because we're using the wrong language/aren't encoding enough things in the types and semantics/shouldn't have used this niche compiler so now let's get a new interpretation from another Supreme Compiler/etc. Life would be easier \s

So it's maybe more optimistic than you, in that the run/read time power (judicial) doesn't get diminished, but more pessimistic in that I believe it because I believe that changing the language from english law jargon to some formal language doesn't actually eliminate the issues it might be intended to eliminate.

[dead]