If they just remade it with modern AF software, I'd probably carry mine around most every I went. Not to mention what they could do by updating hardware.
Napoleon's only been gone for about two hundred years, whereas Common Law has some real classics. For example https://en.wikipedia.org/wiki/Statute_of_Merton was a set of laws promulgated in 1235, some of which remained in force (at least nominally) until the 1980s. I don't know much about Canon Law, but that surely goes back even further.
All that to say, you can just do your best to understand the law in the the context in which it was written, and replace the text every now and again.
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.
As always, labor is a marketplace, and the supply side boils down to a) how much the next person else is willing to work (all else equal), and b) external forces (like overtime requirements kicking in at 40 hours).
OCR for printed documents is super robust, but handwriting, low res, and aligned recognition (not just image to "hello world" but also having "h is here in space e is here in space...) are all still well behind "basically solved."
There's more to this that I'd absolutely love to see in a language, and I can't tell if rye supports. If you want an ergonomic `if` you need its scope aspects too.
Consider this example
<beginning of the function>
x = ...
if foo:
y = ...
else:
x = ...
y = ...
<rest of the function>
Critical parts of the ergonomics are that
a) in each branch, we have everything in scope that comes from <beginning of the function>
b) in <rest of the function>, we have everything in scope that was assigned or reassigned in the executed branch
I'd love a language that supports programmable stuff like if, since I'm tired of python autodiff not handling `if` and `for`. But it would really need programmable scope stuff to still allow the ergonomic "scope effects" that make `if` and `for` blocks ergonomic.
Sorry, but I don't understand the example. In Rye, as in REBOL all first level block evaluations (do, if, for, loop, ...) happend in current scope (context).
Rye has first class contexts and it's one of more exciting things to me about it, but I'm not sure it's related to what you describe above. More on it here:
One thing that pops out at the example above is that I wouldn't want to define a y inside if block, because after the if you have y defined or not defined at all, at least to my understanding of your code.
Rye is constant by default, most things don't change and you need less veriables because it's expression based and it has left to right "flow" option. So you only make variables where you really need them, which is less common and specific, it should be obvious why you need a variable.
10 days later... sorry, I didn't see your comment.
The example I gave had a few pieces:
- x is defined prior to the if/else, and overwritten in just one branch
- y is defined in both branches
So in the rest of the function, we have both x and y available, regardless of which branch is taken.
I just took a quick read of the context page and the context basics page, but it's still unclear to me whether you can program how scopes/contexts interact in rye.
In my example, we I'd say we have a few different scopes worth mentioning, and I'm curious how programmably we can make them interact in rye:
Scope 1. Right below the first x = ...: we have names available form <beginning of the function> and have x available as the ... stuff. Presumably the `foo` in `if foo` lives in this scope.
Scope 2T. Right after the true branch's y, we have scope 1 plus y introduced
Scope 2F. Right after the false branch's x and y, we have scope 1 plus x "pointing to" something new and y introduced.
Scope 3. Below the if/else, where <rest of the function> lives. This is either scope 2T or scope 2F. x is either scope 1's x or scope 2F's x, and y is either scope 2T's y or 2F's y.
In the original articles language,
So the scope relationships in an if/else are a diamond DAG taking the names from before it, making them available in each branch's scopes, and then making a sorta disjoint union of the branch's names available afterwards. Could that be programmed in rye, to allow the kinds of naming ergonomics in my previous example, but with the if/else being programmable in the sense of the original article? I'm especially interested in whether we could overload it in the traditional autodiff sense.
Responding to a different part of your comment about using names rarely in rye, I've found that I benefit a ton from handing out names more than most people do in functional languages, just for clarity and more self-documenting code. Like, the ide can say "`apples` is broken" instead of "error in location xyz" and I can rebuild my mental state better too when revisiting code.
Mercury is one of those languages that seems to support so many different styles of programming in a nicely unified way, I've always been curious about it. This is so much more readable than I remember any of the Mercury docs being. Worth checking out.
It's one of those languages where I'd love to see the mainstreamification of some of its ideas, but as is, it just seems too clunky.
> Not particularly, no. What I want is for you to purchase the seats your family needs ahead of time, not ask me for them for free.
What happened to "if you want it, then you have to pay for the privilege?" If you want to be sure you aren't next to a kid, just pay for a first class ticket, instead of making other people pay extra for your comfort. You knew your preferences when you bought the ticket, after all. Select the seat you find necessary. /s
The point being that the status quo rolls dice that make everyone unhappy, and there are options for everyone to avoid it by paying extra. Those options are priced by the people creating the situation in order to make a maximally profitable 'pay to avoid this' scenario. I always pay for my family to get together, but blame the airline for making you uncomfortable, not the family.
Of course, the challenge is that the next question after solving a leetcode problem is often to explain and optimize the performance characteristics, which in prolog can get stupidly hairy.
reply