[alexandria-devel] Hi

[Nikodemus Siivola]

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