> I'll second (or third?) the appreciation of the simplicity.
>
> Two questions though:
>
> 1. What exactly does "Editing" in (i) imply? I could guess (esp. with it
> being lumped with "Introspection"), but I'll hold off on assuming things...
Basically I'm thinking of the the functionality used by SLIME here.. things like source-location (for M-.) and the who-calls introspection etc.
If someone has better wording for (i), please speak up.
> 2. While the "OS and Filesystem access" point is one I'm especially keen on,
> I'd like to hear what anyone's opinion would be on CLTL3 standardized regex
> functionality
Absolutely not :).
concise and to the point. i like it.
> Mr. Weitz's cl-ppcre seems to be fairly widely used & may be
> the *de-facto* standard, but why not take it one step further?
I think the better question is 'why take it further'? Personally, i don't use regexps that much, so i'm biased.. but...
i certainly don't use regexp's on a daily basis either, but they tend to get baked into languages as features or in standard lib form frequently & are indispensable in those instances that you need them, so it seemed worth mention (perhaps i'd missed such mention in previous CLTL3 discussion - if so, my apologies for the ensuing horse beating)
Is the PERL regexp standard the one we'd like to follow? There is a perfectly good portable implementation that is an excellent candidate for inclusion in the 'standard library', so why would CLtL3 need to include its own description of a defacto standard from another language?
The Standard Library (TM) being the key phrase there, no?
...but the mention of what "flavor" of regexp's would be standardized on in such a hypothetical situation is probably the most obvious source of pain (aside from regexp's themselves) that i didn't think about before opening my big fat mouth, and is a likely candidate for grounds of topic dismissal in itself...
I'd personally much prefer a 'lispy' (read : verbose and understandable) implementation of regexps then the one from perl, and still wouldn't want it included as part of CLtL3..
perfectly fair.
regexps are not simple, and can be implemented without implementation support, so there is no good reason to include them in the base language.
i don't necessarily agree with this statement **as written**, but i do agree with the brunt of your argument enough to not pick nits...
Should we also include cl-awk? How about an infix macro? an SQL syntax library? A parser generator? why cl-ppcre over any of those?
oh, c'mon - now we're just getting nasty :)
Edi himself has spoken against the idea of 'standardising' on cl-ppcre (i can't find the reference right now), and IIRC his reasoning was similar to mine.
this is an interesting tidbit and even more scrumptious food for thought - i'll try to dig this up for my own edification...(if anyone has references handy, please send them to me privately)
So, to turn the question around, how would including cl-ppcre help meet the goals of the project as outlined in the charter?
to play devil's advocate myself here - given it's widespread acceptance/usage, and it's very nature as a *portable* library, it seems that it would be in line with the following part of the CLTL3 charter:
"It should codify existing practice and provide additional features to facilitate portability of code among diverse implementations."
Again, i'll be your devil's advocate for the duration of these discussions, so please don't assume i'm dismissing this outright... but the questions and reasoning behind my arguments are valid... so i'd love to hear counter-arguments. Just to give you some ammo, ANSI included FORMAT and LOOP, and similar arguments could have been (and were) made against them.
no ammo needed...and even if it was, format & loop seem to hold title to the most contentious aspects of CL to this day, regardless of how much some people use/love them, so leaning on them as justification for any argument smells distinctly...dangerous.