On Sat, Nov 1, 2025 at 7:19 AM <[email protected]> wrote:
> [email protected] > > Oh, this is super helpful.Thanks! > > Yeah, I was trying to understand how I got the 20k lines of C++ code > down to about 1500 lines of Go for the core, but imagine I will constrain > the format much much more tightly > and avoid some of the more "turing complete" options available. It is > impressive what's been done, but > think I am focusing on a data format more than a language itself. > > I've got an initial, naive implementation done which parses and gives > balances register etc etc for my personal > accounts, but noticed a few issues and need to throw it against some more > complex data for things like > my stock portfolio and business accounts. > > I'll post up the Go implementation shortly. I used regexs ofr prasing > (which I know are more fragile) but also > think I can move to some sort of AST later as it develops. Was kinda fun > though. I am still trying to grok a > lot of the niche dege cases in the code base and options which (tbh) I > think I'll never use. > > Anyhow, thanks for the reply! > > Simon Michael wrote > > On 2025-10-29 17:27, Daryl Manning wrote: > > I'd be interested in hearing about the variability you think there is in > > the file format (I use a stricter format for *myself*) > > like, for example, not allowing prefixed currencies and such and > > demanding ISO 3 letter curency codes etc, but would be interested > > in hearing the types of things that we all feel _should_ be removed. > > It's very complex. A few things that come to mind (still true as far as > I know): > > - Multiple formats can be mixed in the journal file. Journal entries and > directives, but also timeclock entries, python code and value > expressions (as part of journal entries and directives I think) which > are a turing complete programming language themselves. > > - There's great flexibility in the syntax, which is a double edged > sword. It feels pleasant for users in the beginning but complicates life > ever after for implementors (and in the end, for users as well). > Beancount's syntax is too restrictive for comfort in some ways, but eg > requiring strict ISO dates, and ISO currency codes on the right hand > side, are two small things that simplify a lot. > > - The syntax for everything right of the account name in postings stands > out as particularly complex - amounts, costs, lot prices, lot dates, lot > labels, balance assertions, balance assignments, and comments can all be > combined there, in many different ways. > > - Allowing spaces in account names brings in the two-space delimiter > requirement, which beginners always trip up on. Also it makes scripting > harder, later. Again it's a double-edged sword, costly though also > sometimes pleasant. > > You might be interested to review hledger's journal format[1]. It copies > most though not all of Ledger's (not value expressions, eg). But you can > see I've documented some syntax as first class and pushed some other > parts into a legacy section[2]. Also I discuss syntax differences at [3]. > > [1] https://hledger.org/1.50/hledger.html#journal > [2] https://hledger.org/1.50/hledger.html#other-syntax > [3] https://hledger.org/ledger.html#journal-format-differences > > > > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/ledger-cli/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to [email protected]. > -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/ledger-cli/CAL9aZkuHj1kiKx-a_cOPVBD62M%2BVCVQ7HxyPTHsAuqyWqqsH3A%40mail.gmail.com.
