I can see the point where commands which apply across many transactions (a manual optimization) are broken by sorting. My data has always been verbose and each txn is atomic, so sorting wasn't an issue.
Thanks. On Mon, Aug 26, 2013 at 01:14:53PM -0700, Craig Earls wrote: > RJ, > I think your idea is great. John would have to comment on its > practicality of implementation at this point. I also don't know how > many people already depend on the behavior as it currently sits. I > intentionally avoid use of commands in the body of the file > specifically because of this issue. Others may differ in their use > by, for example, changing the bucket directive mid file and keeping > different financial institutions indifferent parts of the file. > Blindly sorting that by date would be disastrous. Org users would > probably be the best candidates for checking this. > > Craig > > On Mon, Aug 26, 2013 at 12:12 PM, Harshad RJ <[email protected]> wrote: > > > > On Tue, Aug 27, 2013 at 12:10 AM, Russell Adams <[email protected]> > > wrote: > >> > >> When we start talking about sorting and queries (narrowing) this is > >> where the flat file format starts to be an issue vs a kind of > >> database. > > > > > > I don't think the flat file format by itself is an impediment. If the > > semantics are well defined and declarative, then it is as good as a > > structured database, and yet, being more convenient to humans. > > > > I had mentioned this in a previous thread. Sorry to harp on it again, but it > > really would be good to reconsider this suggestion: > > > > Don't > > leak parsing order and other such internal details. > > Make the declaration order irrelevant. > > > > While this might make some rare scenarios a little cumbersome, I think it > > will be a net win. I have implemented this exact suggestion when I joined a > > team building a large commercial DSL. It simplified the DSL and also the > > parser and processing engine. It also allowed easy development of IDEs where > > partial processing of input could be done in real time. That was couple of > > years ago and that team still thanks me for it. > > > > -- > > Harshad RJ > > > > -- > > > > --- > > 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. > > > > -- > Craig, Corona De Tucson, AZ > enderw88.wordpress.com > > -- > > --- > 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. > ------------------------------------------------------------------ Russell Adams [email protected] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 -- --- 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.
