alexandria-devel June 2007

alexandria-devel@common-lisp.net

4 participants
4 discussions

[alexandria-devel] darcs patch: Add #.#+ readtime conditional functions.
by asf＠boinkor.net 02 Oct '09

02 Oct '09

Mon Oct 16 10:00:31 CEST 2006 asf(a)boinkor.net * Add #.#+ readtime conditional functions. * This adds functions that can be used in #+#. readtime conditionals, for example: #+#.(alexandria:read-if (find-package :asdf-install)) :yay #+#.(alexandria:read-if-fbound :install :asdf-install :exportedp t) :yay * included in the patch is a commented-out portion that allows the user to activate a #? read syntax. I'm not sure if that fits into the conservativism constraints.

3 3

Re: [alexandria-devel] Moving to next stage
by Attila Lendvai 25 Jun '07

25 Jun '07

> > on this note, we should/could add a REMOVE-FROM-ALIST and their > > DELETE-FROM... counterparts. > > I agree. i've added the missing delete-from-plist and their modify macro variants. i'm not sure about the alist versions, though: what should be their api? plists are usually used with symbols as keys, so using #'eq for comparison is ok, but alists are mostly addressed by non-symbols, so the (alist &rest keys) api is not too useful without a :test argument. because of this i've skipped them for now. > > 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? yep, i've added them. everybody, feel free to excercise your veto rights even with an UNDO patch, i won't take it as an offense! this is how the Alexandria project is planned to work... -- attila

1 0

[Fwd: Re: [alexandria-devel] Moving to next stage]
by Nikodemus Siivola 13 Jun '07

13 Jun '07

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(a)random-state.net> Date: Wed, 13 Jun 2007 14:30:37 +0300 From: Nikodemus Siivola <nikodemus(a)random-state.net> User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Attila Lendvai <attila.lendvai(a)gmail.com> Subject: Re: [alexandria-devel] Moving to next stage References: <466D1F29.2030908(a)random-state.net> <b54b34af0706130043v7fe27976lf05e254d6abb8b6c(a)mail.gmail.com> In-Reply-To: <b54b34af0706130043v7fe27976lf05e254d6abb8b6c(a)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

1 0

[alexandria-devel] Moving to next stage
by Nikodemus Siivola 13 Jun '07

13 Jun '07

I think Alexandria is soon ready to move to next stage: dropping the things that we cannot agree on. My TODO list before that includes just a few cleanups and documentation tweak (that can be probably best done in parallel with the dropping), and adding three more functions: MAP-COMBINATIONS, -PERMUTATIONS, and -DERANGEMENTS, which I'll merge as soon as I find my MAP-DERANGEMENTS (missing in action, but I know I have it.) Does anyone else think there is something significant missing? After we feel that we're as complete as we're likely to get in short order, I propose the following work order: 1. Hash over everything we have, one-by-one: * Vetos, dropping the things we don't agree on or are feeling unsure about. (Eg. I'm not sure the statistical stuff belongs in Alexandria: is it "good enough" for real statistical work? If not, then we should drop it because people really needing it will just need to shadow it, and others don't care.) * Checking that the documentation is complete enough. * Checking that the tests are complete enough. * Checking that the API is Common Lispy enough: :START & :END arguments, etc. * Checking that the API is future-proof enough: not grabbing names that might better serve other purposes, not using &OPTIONAL arguments if we may end up wanting to later add &KEY arguments, etc. * Checking that we're not defining something that should be a generic function as function. * Checking that functions have their "obvious" companion functions: REMOVE-FOO, REMOVE-FOO-IF, REMOVE-FOO-IF-NOT, DELETE-FOO, etc. * Fixing as necessary. ...this is going to take a fair while, so the sooner we get to it the better -- but similarly it doesn't make a real difference if we start a week or few later then sooner. 2. Make the nickname ALEXANDRIA conditional on there not being an ALEXANDRIA.X[.Y] with X greater then 1. 3. Wrap it up as ALEXANDRIA.1.BETA.1, and put it up for public review (month or two.) If there are comments, attend to them and repeat the beta cycle 5. Rename it as ALEXANDRIA.1, and rest on our laurels. I futher propose that the stuff we drop goes in BABEL package, which is doesn't make any guarantees about anything -- just a grab-bag of stuff that doesn't fit in Alexandria, and doesn't (yet) have an obvious home elsewhere. Cheers, -- Nikodemus

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

alexandria-devel June 2007