Re: Almost, but not quite: C++ STL in LilyPond

[David Kastrup]

Dan Eble <address@hidden> writes:

> On May 5, 2020, at 11:09, David Kastrup <address@hidden> wrote:
>> I'd like to come up with an allocator/container programming model
>> comparatively similar to the STL one so that one could mostly steal the
>> implementations and "just" add the required Scheme awareness while
>> removing of destruction/deallocation tracking.
>
> It might be difficult for me to devote the time to this discussion
> that it deserves, but I want to say that I've been working on C++
> wrappers that allow walking SCM lists (of immediate values or Smobs)
> with standard iterator syntax and semantics.  I suppose that's
> tangential to what you are talking about, but it would be
> disappointing if we did significant overlapping work.

At the current point of time, I am more concerned with offering
container shadows than iterators on existing SCM data structures.  The
typical SCM list would be somewhat akin to a Forward_list construct.

What I have ready-to-use is something that stores like an SCM value but
behaves like a Smob pointer with regard to -> and * usage.  That would
allow to replace a number of Smob members that are now marked with

scm_gc_mark (xxx->self_scm ())

with

scm_gc_mark (xxx) or scm_gc_mark (xxx.scm ()) which is a first step
towards making Smob memory layout be organised where its garbage
collection phase can be handled by a struct vtable rather than an
explicit hook (this basically shifts the responsibility of whether the
whole struct or just individual parts of it participate in the mark
phase back to the Guile implementation).

But STL containers still require a strategy.

-- 
David Kastrup