On 09 Aug 1999 00:17:53 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> [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).
Only a little bit more.
> 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.
Stalin, maybehaps.
> > [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.
The problem with SRFI's is that they still won't provide you with a
standard way of requesting facilities, e.g. - things like (require)
which is different from the DrScheme equivalent.
> 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).
Agreed; hashing is another thing that almost always has a slightly
different expression in each different implementation.
In the case of a struct, n isn't likely more than 10 or so, the
complexity is essentially "O(10)," which is probably effectively only
a little slower than hashing.
--
Found in a TOPS-10 MCO:
Quotation for the day: "a counter that doesn't exist can't get messed up."
"Once in a blue moon" is defined as the creation of a new SFD or the
renaming of an old one.
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
