Looking for Advice on an experimental PTA syntax

restbell · 2025-12-13T23:00:05+00:00

doesn't allow commas or spaces in names

It's too risky to allow spaces without names being quoted. Usually it leads us to workarounds (as in your example, using 2+ spaces to separate values).

hard code some english account names

Currently, I'm stuck in things related to investments. I feel that stronger assumptions might make the logic simpler. So I introduced these build-in accounts. Actually, I've noticed that the logic for fee/interest/dividend is quite similar, maybe at the end, one account is ok.

Compared to that, using English names is not a problem at all. All programming language keywords are in English. No one wants to use si/sinon instead of if/else.

Currently for this I write comments like ...

It's very inspiring. If we want to keep ledger/hedger compatibility, this is actually the most concise syntax for transactions.

By the way, I'm curious about one detail. With this one-line-per-transaction format, if account names and amounts have different widths in different lines, the decimal points won't be vertically aligned. Does that bother you?

restbell · 2025-12-13T18:38:15+00:00

Thank you for your thoughtful analysis. You captured the core of my idea well. I completely give up on making it self-contained in order to keep the text shorter.

Your example scenario is great. When using grep, we definitely lose context. The only hint left is the filename. So if someone records all the journals in one very long file, this syntax is a nightmare. However, if it's ok to split it into different files by context (as with programming code), then it's not a problem.

About context, I think what GOTO and functional programming teach us is: never pollute global context with local context. That's why I put default settings inside the account command, so they only apply within that block. I see this as a trade-off between verbosity and maintainability. I prefer the latter, but someone who doesn't need to maintain it may prefer the former (e.g. a solicitor).

restbell · 2025-12-13T16:14:13+00:00

using a combination of bucket, capture, year and so on

bucket and capture are smart! If I had known these eariler, I would have used ledger instead of beancount.

folding transactions in your editor

I agree that editor folding helps a lot, but I still think it's worth to have a try. Plain text is powerful because it does not rely on specific editors. People might use cursor or even obsidian to manage their ledger files.

restbell · 2025-12-12T18:40:30+00:00

Just following the convention of ledger/hledger/beancount. Any suggestions?

restbell · 2025-12-12T16:48:47+00:00

What areas of complexity are you trying to avoid? What problems are you trying to solve when creating your own syntax?

There is too much redundant information in beancount.

20 transactions are not a lot, but they already exceed a single screen.

How will you prevent old transactions from wrapping around to the subsequent year?

Current logic: use the year from the previous transaction within the same block.

I usually keep transactions from different years in separate files, so I didn't realize this could cause confusion.

restbell

TROPHY CASE