[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
01 Dec 2000 17:13:40 +0100
Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
Dirk Herrmann <address@hidden> writes:
> First, I admit that I did not look very closely into the performance
> consequences of the change, because some of the posts regarding goops gave
> me the impression that up to now goops is not performance optimized anyway
Actually, asymptotic performance (efficiency after the initial pass
through the code) is optimized. Code loading and initial pass should
be optimized further, though.
But the question about scm_sloppy_memq is independent of GOOPS.
> my plan was to do some goops cleanup anyway, bringing it closer to
> guile's today API, and then looking into such things more closely.
Just a small comment about my view of Guile development:
While I do appreciate your cleanups a lot, please be careful so that
we don't loose information. As you yourself has pointed out, we make
Guile changes in an incremental way. A strategy "first remove feature
A for temporary solution B, then later reintroduce feature A in a new
form" is likely to fail because it's so easy to forget about the
second part. Also, in the middle stage it's not easy for other
developers to see what is going on.
I'd like us to pursue development in a way that we preserve the
previous thinking which has gone into the code and remove things only
when we have complete understanding of why the code was written the
way it was.
Especially with regard to efficiency, the normal thing is to
continuously slide along a slippery slope. I think it's possible not
These things said, I don't want you to take this as criticism---I have
a very high respect for your understanding of Guile code.
> But, there is something about scm_sloppy_memq which we should think about,
> before re-introducing a function like that: The (now deprecated) current
> version of scm_sloppy_memq will accept any object, in particular lists and
> improper lists as argument. This means, if you see a call to
> scm_sloppy_memq, this does not give you any assertions about the type of
> the parameter. If we would like to have such a function in the API at
> all, we should have two versions of scm_sloppy_memq, one which accepts any
> object, as it is now, and one which assumes that the argument is a proper
Yes, only these are needed: 1. scm_memq and 2. a maximally efficient
version of memq intended for use in cases where the listiness is
guaranteed. Functions 2 should not be exported to the Scheme level.
Such a function is useful also for applications using Guile.
> If the argument is not a proper list, the code will crash.
> Obviously, such a function should not be exported to the scheme
Agreed. I just checked and am surprised that we haven't removed
scm_sloppy_memq from the Scheme level earlier!
I suggest that we introduce function 2 above under the name
What do you think?