On Mon, 06 Mar 2000 00:25:17 CST, the world broke into rejoicing as
Bryan Larsen <[EMAIL PROTECTED]> said:
>
> thanks. especially since the refinements you suggested are to the original
> code, not my modifications. :)
>
> > Not bad; I suggest couple of refinements, involving adding some useful
> > abstractions that essentially pull out the HTML dependancy.
>
> this was in the pipe, but I wasn't doing it as well as you suggest,
> so thanks!
>
> >
> > a) By creating a debit/credit "collector," lots of set! instances get
> > to go away, and you don't have to track "inflow" and "outflow."
>
> I didn't consider the transaction report "mine" (I'm working on budgeting),
> so I wasn't going to get into that.
>
> But to be able to report on multiple accounts at once, we do need something
> better.
It may be useful to have additional "collectors" of similar style to
the "drcr-collector." Indeed, if/when we wind up trying to generate
multiple forms of output, we'll really *need* stuff like that.
> > b) Generate HTML in an automated manner, rather than by hand:
>
> My function prettifies the number itself -- I'll merge it in to your cell
> stuff.
Perfect idea. Of the points of having the "helper functions" is that
it centralizes control of generation of the cells so that if there is
any "prettification," it can have sweeping effect on *all* instances.
> > ;;; the above function is a sample of looping via "named let," which is
> > ;;; one of the nicest ways of managing loops...
>
> Yah, I just found it. it sure is sweet.
It sure cuts down on the need for set!, which is one of the operations
that makes it *much* harder to factor out Scheme code. set! is kind
of like the "GOTO" of Scheme; necessary sometimes, but generally to be
discouraged...
There are a couple of places in the reporting code where there's an
idiom like:
(define (whateverfun input1 input2)
(let ((complex-set-of-bindings))
(set! input1 (append input1 (list (something-based-on-bindings))))
(whateverfun input1 (cdr input2)))
which is Just Not Nice.
Three problems:
1. set! makes the code less readable, and makes the function not
functional if the thing getting set! isn't local to the function
2. append is intended for joining lists. Instead of
(append (list 'a) '(b c d)), it is much more efficient to do
(cons 'a '(b c d))
3. You do *not* want to keep binding values over and over if they're
likely just taking on the same values. That eats time and memory.
Named let lets you do recursion in some little portion of the
function, without having to rebind everything.
(define (whatever inp1 inp2)
(let ((this (expensivefun1))
(that (anotherexpensivefun))
(other (stillanotherexpensivefun))
(thing (thing-done-each-iteration (car inp1))))
(if (empty? inp1)
inp2
(whatever (cdr inp1)
(cons inp2 thing)))))
is bad, as it keeps recalculating this and that.
More appropriate is something like:
(define (whatever inp1 inp2)
(let ((this (expensivefun1))
(that (anotherexpensivefun))
(other (stillanotherexpensivefun)))
(let loop
((i1 inp1)
(i2 inp2)
(thing (thing-done-each-iteration (car inp1)))
(if (empty? i1)
i2
(loop (cdr i1) (cons i2 thing)
(thing-done-each-iteration (cadr i1)))))
> > Note: I've spent some time Messing Seriously With Reports, and haven't
> > yet checked anything in. I suspect that what I should do is to check
> > in the utility functions that have fallen out of it, and drop the
> > reports proper, to redo the work once some further code gets checked
> > in.
>
> Ouch, I figured this would happen. I'd like to request that you check in
> regularly to minimize my merge costs.
I can't merge when 2 reports are broken :-(.
I'll have to eat this one; check your code in and I'll see about merging
what I can...
--
"Be humble. A lot happened before you were born." - Life's Little
Instruction Book
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
