On Sun, Jul 14, 2013, at 11:56, Harshad RJ wrote: > Martin, > > I couldn't reply earlier and couldn't work on abandon either (a clairvoyant > name for the project :) > > Until now, that is. > > Some comments below. > > On Sat, Jun 1, 2013 at 9:20 AM, Martin Blais <[email protected]> wrote: > > > If you're in the mood to collaborate, one obvious candidate is to reuse > > the simplified input syntax. > > > > Indeed, it would be great to collaborate. I had a look at your > cheatsheet.org. If I understand right, the push and pop syntax allows a way > to define something and then "undo" the define.
Yeah, these and "option" are the only commands that don't start with a date and hat don't create entries. They're actually very much optional. > For this purpose, I want to develop a generic concept called "scopes". I am > jotting down my idea here <https://github.com/hrj/abandon/wiki/Scopes>. > Your idea of scopes really goes hand in hand with some of what John is doing. The idea behind my syntax definition is at odds with that, it is to keep constructs minimally simple and explicit instead. I haven't really found the need to have this kind of elision, I think it's actually better to be fully explicit and to have Emacs auto-complete account names. It's easy and it works well, and IMO seeing the full account names is clearer (in practice there aren't that many accounts anyhow, like 100 or so). You can then more easily to global renames with text than with elided names (I've had to do this many times in practice). I think that a lot of the creative ideas John and I and others had back in the day (5 years ago?) were of that flavor (better syntax) but never turned out to be really useful FOR ME, in using the system. Over many years of using it, they didn't turn out to be useful time-savers. Much of the input is spit out of scripts in my case anyhow. Emacs completes the account names, that's a non-issue IMO. In the process I've found other things to be useful and missing, links between entries, for instance, or removing virtual transactions (fosters incorrect practices of data entry/representation). So this one is probably an idea for your own syntax. A space of collaboration would make sense if you don't care too much about syntax and just want to use something that is already proven to represent the data structures correctly and can import the data structures and where you want to innovate in the area of processing the entries or creating new kinds of reports. I had envisioned a JVM parser for the same syntax I already use, or perhaps with very simple modifications and others could add on top. We could have used the same syntax to use out each other's reports. That would make sense, because then I could, for example, run my existing data file through your reports generation, or vice-versa. I think that the area where there needs to be more work, in general, is in producing all kinds of reports from the data. Fancy input is a complete non-issue from my POV. But if the area where you want to play is at the level of syntax, I think it's better if you just create your own. You may still want to have a look at the data structures design, I think we all end up with something pretty similar. If they map 1-to-1, it would make someone's job easy to write a Python/C parser for your syntax to use beancount reports, or write a parser from beancount syntax into your data structures to use your reports. Here are the following components to my system, which are fairly decoupled: - core: definition of data structures - parser: read a specific syntax into data structures defined in "core" - ops: purely functional operations on lists of "core" data structures - web: a web-based front-end that produces all reports - imports: framework for importing entries from various files I've attached a dependency graph. You're welcome to clone and poke around and run the example. If one of those components could be reused by Abandon, or if we can share the same definitions (even without sharing code), this might still make sense, again, for writing modules that can accommodate cross-talk between implementations. I so need to go document my design now... the new system is fully working at this point, web interface reports and imports. I've ditched the old version, I'm only using the new one now, fully replaced.) I need to write user docs and more unit testing before I announce some sort of release. That's the 20% that takes 80% of the time... > "scopes" should be familiar to programmers; I am not sure how it would fly > with non-programmers. I don't think catering to non-programmers matters too much to be honest, I doubt the non-geeky would adopt such a system in the first place. > > I've been wanting to write an ANTLR version of the parser, but have > > been reserving this for after everything else is done. You could use that > > from your Scala app via Java interop > > While that is a great idea, I have access to a very cool parsing technology > in Scala, called parser combinators. It is a programmatic way of defining > the parser and there are many benefits to it. The biggest con of parser > combinators is that they are slow, but that is not a consideration for me > right now. I'm familiar with them. Awesome! :-) -- --- 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]. For more options, visit https://groups.google.com/groups/opt_out.
beancount-notests.pdf
Description: Adobe PDF document
