[EMAIL PROTECTED] writes:
> What struck me Friday morning was that I really should be
> marshalling data into somewhat more organized "structures" rather
> than just building assoc lists.
[ General agreement. ]
> I also finally grokked define-struct, and maybe am looking at is as
> a "hammer," and am looking for "nails" to hit with it.
Could be. Rather than assoc lists, unless I need something fancier, I
generally use vectors and define getters/setters and use those
exclusively:
(define (point:create x y z) (vector 'point x y z)) ;; the tag is optional...
(define (point:x pt) (vector-ref pt 0)
(define (point:set-x! pt value) (vector-set! v 0 value))
...
The advantage to using this over something like define-struct is that
define-struct is not standard scheme so your code won't be portable to
other implementations. I'm not a about using non-portable scheme
code, but I try to avoid it unless it provides a compelling advantage.
Of course, if you need dispatch, then you have to do a little more
(which without looking closely yet, looks like what you've done).
For example, *if* we ever decided to implement even more of GnuCash in
scheme, and we really needed to speed some of it up to C level
performance, we could use a good scheme compiler as long as the
relevant code didn't depend on a lot of uncommon functions.
> [This is one of the annoyances of Scheme as compared to Common Lisp;
> there are many commonly desirable functions/macros that CL has
> standardized but that different Schemes handle differently.]
True, but there is some movement toward fixing this (see below).
Further, slib, which we already requrire implements a whole bunch of
useful things. Though I've tended to avoid using slib if I could
implement the same function easily because we might or might not want
to keep that dependency long-term.
There's actually quite a bit of useful code at the MIT and Indiana
repositories we could include if we needed it, but more interesting
than that for your purposes would probably be the SRFI (Scheme Request
For Implementation) process (see www.schemers.org). If you're going
to implement the skeleton of any "struct" style system, I'd suggest
modelling it after the relevant SRFI. In fact, since a SRFI is
required to provide a reference implementation written in standard
scheme to be valid, there should already be code there for this.
SRFI's, especially the finalized ones, should be commonly available in
most schemes soon, and if not, you can just copy/paste the reference
code into your own project.
Also, if we're going to use non-standard scheme bits, I'd recommend
using hash tables instead of alists for any case where there's likely
to be more than a small number of items. Might as well get O(1)
lookups rather than O(n).
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
