freenode/#sicl - IRC Chatlog
Search
4:19:54
beach
Bike: When I wrote Flexichain, the possibility of defining extended sequence types did not exist, so I didn't have the sequence functions in mind for the client code using Flexichain.
4:20:32
beach
Bike: I would have to go back and look at Climacs and see what uses could be replaced by calls to the sequence functions.
8:42:06
splittist
I seem to remember that using CL-PPCRE (for example) with Climacs buffers might have been easier had they been CL sequences.
9:09:19
beach
splittist: That's a good point actually. There should be a sequence interface for Cluffer for that reason.
11:19:10
splittist
cl-ppcre coerces strings to something that you can call SCHAR on; on LispWorks that is something other than simple-string (lw:simple-text-string), so there is hope...
12:26:12
Shinmera
Extensible sequences in cl-ppcre would only really make sense if it was rewritten to not use random access everywhere.
13:34:17
Bike
an implementation with the sequences extension can easily define (cl:coerce 'simple-string extended-sequence) to work. of course it'll cons
13:39:40
Bike
for example we could have a function that, given a sequence, returns a specialized elt for it, and then ppcre could pass that around
13:44:49
Bike
(except it also computes the applicable methods, and returns an actual function rather than a form or method, and etc)
13:46:41
Bike
given that ppcre actually works with indices directly, i don't think using just the iteration protocol would be enough, basically
13:48:29
scymtym
given the number of special variable accesses, a specialized character-access function closed over the input sequence could actually be faster than the current code (maybe depending on the implementation)
13:51:22
scymtym
yeah, remaining variability for SIMPLE-STRING (element-type NIL on SBCL comes to mind) and also accessing the string through *STRING*
13:52:25
Bike
oh, wait, you mean like it reads a special variable to get the string, whenever it does schar. i see, yeah