Provide pre-configured agent for lists and arrays

[Pierre Neidhardt]

Since they are index-based, it makes sense to have a common interface for them. But CL uses nth for lists and elt for vectors, so it would not follow the standard here (which is my opinion not very convenient).

Otherwise they can be separate interfaces.

[Manfred Bergmann]

Do you think there is a need to cover ordinary lists at all?
List operations like cons and append are not destructive and return a new list which can more easily be used for swapping. nth of list, in particular together with setf, do you think this is really used? Since nth needs to traverse the list I'd imagine that such a use-case should use an array.

For arrays/vectors there is no question.

[Pierre Neidhardt]

Funny you mention it, because I just had my first use of (setf (rest l) ...) yesterday! In this case, I can't really use vectors because I need to pass the list to sb-ext:search-roots which does not accept vectors. Definitely not a common use for me though, so I guess it's fine if gserver does not expose such interface.

[Manfred Bergmann]

What about elt vs. aref. elt works on sequences, so also strings and such. Where aref is only used on vectors/arrays.

[Pierre Neidhardt]

aref also works on sequences like strings. The difference between `elt` and `aref` is that the latter ignore the fill-pointer in arrays.

[Manfred Bergmann]

OK. So elt is actually more safe? Going beyond the fill-pointer sounds like going beyond the bounds of an array in C or so.

[Pierre Neidhardt]

It's not memory related, both aref and elt can be passed arguments outside their range. CL arrays may optionally have a fill-pointer which is used to indicate where the meaninful data stops. This is useful to extend and shrink the array without reallocating memory (an expensive operation). Consider this example: (let ((array (make-array 6 :element-type 'character :initial-contents "abcdef" :fill-pointer 4))) (aref array 4) ; => #\e (elt array 4))

[Manfred Bergmann]

I'm a bit unsure here about the error handling.
The functionality that retrieves something like agent-elt, agent-pop, etc. can return a condition raised by elt, vector-pop, etc. That's ok.
But functionality that only happens by agent-update (internally uses tell) to only update internal state, any conditions raised by setf, vector-push, etc. would just be available as part of log4cl. But for the user that's not good enough I think. So I'm thinking about an error handler function the user can optionally pass that is called with the condition that was raised by the function (elt, ...). Then the user can decide what to do with it. Ignore, log, or whatever.

[Manfred Bergmann]

Finalized array-agent.
As part of this the interface also for hash-agent was slightly modified to streamline the interface.

[Pierre Neidhardt]

Neat! Thanks a lot!