Oops, forgot to CC the list.

-------- Original Message -------- From: - Wed Jun 13 14:31:03 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Message-ID: 466FD55D.3040703@random-state.net Date: Wed, 13 Jun 2007 14:30:37 +0300 From: Nikodemus Siivola nikodemus@random-state.net User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Attila Lendvai attila.lendvai@gmail.com Subject: Re: [alexandria-devel] Moving to next stage References: 466D1F29.2030908@random-state.net b54b34af0706130043v7fe27976lf05e254d6abb8b6c@mail.gmail.com In-Reply-To: b54b34af0706130043v7fe27976lf05e254d6abb8b6c@mail.gmail.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit

Attila Lendvai wrote:

i'm missing some kind of collecting macro, to avoid the way too much used push/nreverse pattern. this macro should preferably use such names that do not conflict with ITERATE.

i've proposed one some time back, but it's not satisfying enough for inclusion as is.

I'm open to proposals, but I have the hunch that collecting macros end up being either small languages (and thus sort of outside Alexandria's scope) or not general enough.

i would like to bring up the possible removal of SANS (again. it's not that i hate it, but it's a broken window in my eyes... :) SANS is a REMOVE-FROM-PLIST which is a much more intuitive name and matches the CL naming convention of REMOVE/DELETE.

Possible. I would personally be happy to retain it as a synonym / alternative API.

on this note, we should/could add a REMOVE-FROM-ALIST and their DELETE-FROM... counterparts.

I agree.

then we could define setf expanders for them, no idea on their names though. REMOVEF-FROM-PLIST sounds silly, REMOVE-FROM-PLIST! is (unfortunately) not used much in CL and if there were a DELETE-FROM-PLIST! then DELETE-FROM-PLIST would be confusingly suggesting that it has no side effects. hm, seems like i have more questions then answers here...

You mean modify-macros? REMOVE-FROM-PLISTF, etc.

another one that bothers me is the STARTS-WITH/ENDS-WITH. currently they check for the first and last element of a sequence. unfortunately it can't be clearly made to work so that it can check both for single elements and sequences (because NIL is both of them) unless we agree on something about NIL and document it. but on the other hand, most of the time (this may be subjective) such a STARTS-WITH/ENDS-WITH is needed that works with sequences, so i usually end up shadowing them.

i personally would be ok if they worked so that when called with NIL they would always return T (so NIL would be taken as an empty sequence). and if we added FIRST-ELEMENT/LAST-ELEMENT then people could use them to test if a sequence start and/or ends with NIL as an element.

Would STARTS-WITH-SUBSEQ and ENDS-WITH-SUBSEQ work for you?

Cheers,

-- Nikodemus