Christopher Browne <[EMAIL PROTECTED]> writes:
> > Now, the first thing that happens is that the bracketed report-string
> > expression is evaluated. my-port is bound to anything in the frame
> > where report-string is evaluated, is it?
>
> my-port is bound to whatever is the value of my-port in the
> environment that it exists in.
I haven't been following this *really* closely, and you may well
already know this, but in case it's helpful, bear in mind that guile
has string-ports, so you can use them to accumulate output using
display, write, whatever, into a string. See "info guile-ref" and
search for "call-with-output-string".
> And... Argh... I finally see a bad hole. These functions don't have
> a way of accepting the report-port so as to have a "path" to push data
> out to the eventual port.
Unless you want to use a global, and that's no fun.
> (define linedata #f)
> (report-line sample-port linedata
> (report-string linedata 1 "Net Income (Loss)" 0 'TotalDescription)
> (report-total linedata grand-total-collector #f
> 2 "Net Income" 'CreditTotalAmount))
> Which would get transformed into the previous something very nearly
> like the previous set of code. (Hmmmm. I need to browse some bits of
> On Lisp again...)
I'm a pretty big fan of avoiding them unless there's a compelling
reason[1]. The best one is usually that you need to control evaluation
order, though sometimes I find syntax-clarity sufficient. What do you
think about some variation on this instead?
(output-line
(line-append
(report-string linedata 1 "Net Income (Loss)" 0 'TotalDescription)
(report-total linedata grand-total-collector #f
2 "Net Income" 'CreditTotalAmount))
sample-port)
[1] Aside from the standard issues about it being a little harder to
read code as you add more exceptions to the standard evaluation rules,
there's the issue that macros are not first class objects, so you're
substantially limited in what you can do with them since they're not
"composable" items themselves.
FWIW
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
