[cltl3-devel] RFC: CLtL3 Charter

[Ian Mondragon]

On Tue, Sep 1, 2009 at 3:40 PM, <drew.crampsie at gmail.com> wrote:

> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090901/3df14fe0/attachment.html>