On Sep 29, 2017, at 4:00 AM, Aris Merchant <[email protected]> wrote:
> 2. Annotation style. As you've mentioned, your format is a bit forced. > You're doing a great job with what you have to work with, but I think > the basic problem may be that you're trying to use markup to represent > transactions. It works wonderfully for representing the data (and > should probably be a base format for that), but poorly for > representing things like conditional actions. You can add and add to > the format, but you'll just be making it more complicated to use. I > suggest you consider using programs (possibly with methods you > provide) as annotations. It feels kind of intuitively weird to > represent an annotation as a program, and they don't have the nice > formal properties the data itself does (except maybe if you used > Haskell or something), but I think it might be a lot more practical > for actual use. Programs allow for loops, unrestricted conditionals, > and the like, meaning that you don't have to work something out by > hand or create a new transaction type just for one complicated > transaction. They would work well for this because they take data and > compute changes, which is exactly what our action system does. There > is thus a neat one-to-one correspondence between an action and a > program. I’ve just gotten the archive (Cadastre) to a point where it’s capable, at least in principle, of handling some of my reports for me, and imported the data I use to drive the existing Surveyor’s report. Hopefully, this weekend’s Surveyor report will come out of that, rather than out of my existing scripts. Having gotten to this point, I have the following observation: Aris, you were absolutely right. Even the simple cases needed for the Surveyor’s reports, where the most complex transactions are “change one owner to another,” are clunky and repetitious without the ability to define abstractions or to iterate. The annotation for the message adopting proposal 7846 reads as follows: > --- > changes: > - op: set > path: /estates > value: > Antegria: > full_name: The Estate of Antegria > owner: Agora > short_name: Antegria > Borduria: > full_name: The Estate of Borduria > owner: Agora > short_name: Borduria > Cagliostro: > full_name: The Estate of Cagliostro > owner: Agora > short_name: Cagliostro > Dawsbergen: > full_name: The Estate of Dawsbergen > owner: Agora > short_name: Dawsbergen > Erehwon: > full_name: The Estate of Erehwon > owner: Agora > short_name: Erehwon > events: > - message: The Estate of Antegria created by Proposal 7846 > office: surveyor > - message: The Estate of Borduria created by Proposal 7846 > office: surveyor > - message: The Estate of Cagliostro created by Proposal 7846 > office: surveyor > - message: The Estate of Dawsbergen created by Proposal 7846 > office: surveyor > - message: The Estate of Erehwon created by Proposal 7846 > office: surveyor And that’s as terse as I can get it. The following messages that transfer those estates around are dully mechanical, too: > --- > changes: > - op: set > path: /estates/Cagliostro/owner > value: CuddleBeam > - op: set > path: /estates/Cagliostro/last_price > value: 68 > events: > - message: CuddleBeam bought Cagliostro for 68 shinies > office: surveyor There’s some room for abstraction, here. I’ve attached a copy of the state output this thing generates. It has an API - but the command-line tool I wrote for it uses YAML for usability reasons. However, I’m looking forwards to moving the Agoran Land Registry Office to the cloud, at least, even in this initial form. I’m going to try to transfer the Secretary’s reports to it, as well, which should put a bit more stress on the design. Once that works, does anyone feel like beating on it using the limited tooling I’ve created so far? I need outside feedback to make sure I’m not just spinning my wheels on this. -o
state.yml
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
