[alexandria-devel] Hi
Hi, I was thinking about putting some order in my own fare-utils, and maybe merge with arnesi, cl-utilities, and so many other libraries. Nikodemus told me to look for Alexandria. It would make a good start. But there should really be another layered project to provide all the basic algorithms to CL: fifos, various trees, iterators, comparators, tries, hashes, sorting, pure and impure containers, etc. Although we possibly want to layer that on top of a good macroexpansion and higher-order module system a la MzScheme. Notes, reading the darcs source: * I think if-let* would be better if it did short-circuit logic and stopped computing and binding at the first NIL * in sequences.lisp, shouldn't suffle be shuffle? * shouldn't emptyp be a gf? * in symbols, what does ensure-symbol do that intern alone doesn't do??? * there should be a shortcut format-keyword for format-symbol :keyword * tests should probably be in a separate directory, one per file, mimicking the main source files. Things I would really like from arnesi * compose is done better in arnesi. a multiple-value version would be even better (as a replacement or a distinct function). * I *really* would like to see the flow-control parts of arnesi there. Except that I prefer (block NIL ...) to (block while ...), and with* should have a different name. * ensure-list, ensure-cons, remove-keywords * eval-always (called eval-now in fare-utils) Things that might or not be good, some of which I have in fare-utils or that are in use at ITA: * the "optimizing" strcat (that normalizes to base-string if possible) * nconcf, append1 append1f (i.e add one element at the end). * many variants along the line of clisp's with-collect, arnesi's with-collector, etc. * my DBG macro, for print-based debugging. * with-input, with-output, for wrapping a stream-using function like format does with its internals (i.e NIL means returning the resulting string). * defconstant-equal, defconstant-equalp, defconstant-unequal, defconstant-eqx -- to specify the constantness that matters. * alist->hash-table and hash-table->alist * with-accessors (with optional prefix) as a replacement for with-slots. * accessors-equal to help compare objects slot-by-slot * plist->alist * association * defun-inline * define-values-modify-macro define-values-post-modify-macro post-incf post-decf * multiple-value-quote (only useful if we also provide standard abbreviated names -- which would make sense *a different package*) * symbol-macro-expansion That's all for today. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A long time ago, someone in the Lisp industry told me it was poor form quote people; it suggests that they lack value. But I don't want to get bound up into that argument, so let's just achieve closure by agreeing that the point is that you can feel free to point people to my earlier pointer, which works as a reference for certain reference works that are particularly on point in their pointers about pointer references. Did you copy all that? -- Kent M Pitman Take my advice, I for one have always believed in share and share alike. I'm constant on that. If I were to modify my argument, however slightly, those that depend on me (and I get calls all the time, and I return most of them), might accuse me of corruption. I may have no class, but at least my values haven't changed. -- Jrm
Faré wrote:
But there should really be another layered project to provide all the basic algorithms to CL: fifos, various trees, iterators, comparators, tries, hashes, sorting, pure and impure containers, etc. Although we possibly want to layer that on top of a good macroexpansion and higher-order module system a la MzScheme.
Sure, but definitely out of scope for Alexandria.
Notes, reading the darcs source: * I think if-let* would be better if it did short-circuit logic and stopped computing and binding at the first NIL
Possible, but probably a sign that the operator itself can be interpreted in too many ways and should be left out. Dunno.
* in sequences.lisp, shouldn't suffle be shuffle?
Ooops!
* shouldn't emptyp be a gf?
Probably yes.
* in symbols, what does ensure-symbol do that intern alone doesn't do???
When writing macros needing to do (intern (string something-from-user) package) happens often enough to annoy me. I have no idea why it does first FIND-SYMBOL and the INTERN. Looks like a brainfart.
* there should be a shortcut format-keyword for format-symbol :keyword
Good call.
* tests should probably be in a separate directory, one per file, mimicking the main source files.
The same.
Things I would really like from arnesi * compose is done better in arnesi. a multiple-value version would be even better (as a replacement or a distinct function).
You're referring to implementation, not semantics? (Taking a quick look Arnesi seems to agree on semantics.) Both COMPOSE and MV-COMPOSE are useful in different situations, so I don't really see why they should be folded into one.
* I *really* would like to see the flow-control parts of arnesi there. Except that I prefer (block NIL ...) to (block while ...), and with* should have a different name.
Aside from anaphoric stuff contents of flow-control.lisp seem mostly fine to me. (Modulo docs.) I agree on the BLOCK NIL, fits with various CL constructs. ...except I am very dubious about WITH*.
* ensure-list, ensure-cons, remove-keywords
ensure-list is in Alexandria, remove-keywords is calles SANS. ensure-cons sounds good.
* eval-always (called eval-now in fare-utils)
I can be convinced about this, but I've always felt that eval-always is a sign that the thing has not been thought about, and doesn't really inform the reader. I believe an Emacs command to insert the mantra does the same thing better.
Things that might or not be good, some of which I have in fare-utils or that are in use at ITA: * the "optimizing" strcat (that normalizes to base-string if possible)
Possible, but seesm pretty specialized.
* nconcf, append1 append1f (i.e add one element at the end).
You mean nconc1, append1, and the corresponding modify-macros? Sounds good.
* many variants along the line of clisp's with-collect, arnesi's with-collector, etc.
I think collector stuff may out of scope, at least for initial release. The design space is too large for a "right" solution, and there is no clear traditional favorite.
* my DBG macro, for print-based debugging.
I think putting debugging tools into a separate package might be a good idea.
* with-input, with-output, for wrapping a stream-using function like format does with its internals (i.e NIL means returning the resulting string).
Possible.
* defconstant-equal, defconstant-equalp, defconstant-unequal, defconstant-eqx -- to specify the constantness that matters.
How about (define-constant var value :test equal) ?
* alist->hash-table and hash-table->alist
hash-table-alist and alist-hash-table exist in Alexandria.
* with-accessors (with optional prefix) as a replacement for with-slots.
This would shadow cl:with-accessors, no?
* accessors-equal to help compare objects slot-by-slot
Possible.
* plist->alist
Call it plist-to-alist and add the inverse. ;)
* association
Need to look at this. (Or you can explain it.)
* defun-inline
I feel this is redundant, or possibly out of scope for Alexandria. A separate package/project for defun-typed, defun-inline might be in order.
* define-values-modify-macro define-values-post-modify-macro post-incf post-decf
If the semantics are right, sure.
* multiple-value-quote (only useful if we also provide standard abbreviated names -- which would make sense *a different package*)
Need to look at this. (Or you can explain it.)
* symbol-macro-expansion
Nice! I wonder if doing the SETF too would be too hacky.
That's all for today.
Good stuff. I see that there are two things that are part of the Big Alexandria Idea that are not on the homepage: 1. Remain backwards compatible. Don't add stuff you may regret. 2. All project members have a veto on any operator. (This veto doesn't have to be excercised immediately -- we will have a veto-round before release.) And to lesser extent: keep the package namespace down to something reasoable so that it will not conflict too badly when it gets USE-PACKAGEd. These are basically the ways conservativism is hopefully created. Cheers, -- Nikodemus
OK, what are the next steps to 1) be added to the voters/vetoers 2) get each of my previous proposals either done or vetoed? Should I "just" create my own darcs repo, and push my patches there? Is vetoing done before committing or after? Moderation or retromoderation? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] To do evil a human being must first of all believe that what he's doing is good. -- Alexander Solzhenitsyn
Faré wrote:
1) be added to the voters/vetoers
Send in a few patches, express interest, if no-one vetoes it it'll happen.
2) get each of my previous proposals either done or vetoed?
Send in separate patches, preferably one patch per feature (even if you apply them to your own darcs repo, please send them to the list). Unified diffs are preferred even in this darcs-age by me at least, since I find them easier to eyeball, but darcs format is also ok. ...just takes a bit more time for me to process, but I cannot speak for the others.
Should I "just" create my own darcs repo, and push my patches there? Is vetoing done before committing or after? Moderation or retromoderation?
After. We'll purge the vetoed stuff before release. ...but stuff that doesn't appeal doesn't get merged at all, so... Cheers, and welcome! -- Nikodemus
participants (2)
-
Faré -
Nikodemus Siivola