Re: scm_sloppy_memq

[Mikael Djurfeldt]

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
> yet.

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
to.

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
> list.

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
> level.

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

  scm_c_memq

What do you think?