On 02 Jan 2000 01:22:49 CST, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> 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".
Yes, I had observed this; it means that output can effectively get
pushed *ANYWHERE* by declaring a port.
If there's a bizarre device with a bizarre protocol, then an appropriate
method to get data there might be to push data into a string port, and
then have the "bizarre stuff" be on the other side of that, pulling data
out and sending it to "bizarre place."
This definitely simplifies life; there is no longer any need for the
report code to worry about pushing data anywhere other than into a port.
> > 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.
Indeed.
> > (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)
This doesn't work because we shouldn't assume that the items are put
into the list in order, and we don't know how many arguments there will
be.
What may be better is thus:
(output-line
sample-port
(report-string sample-port stuff)
(report-total sample-port stuff))
where "linedata" winds up being the value returned by the functions
report-string and report-total. What bugs me a bit is that I have
to pass in sample-port just about everywhere. A bit of "macro syntactic
sugar" might be nice in diminishing the need for that, although that
may not be realistic to actually have happen.
At any rate, we have, as the "Mark III" version:
(define (output-line port . items)
(do-stuff-with-items)...)
The only problem with that is that I don't think I like having to
have the functions (report-string) and (report-total) return values.
Or perhaps I'm overconcerned.
It's definitely a couple steps better.
> [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.
If a "line" is a single structure, then it's perfectly fine for
this to not be composable. I won't care to curry lines...
--
"Linux is a very complete, sophisticated OS" - Paul Maritz of MICROS~1
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
