[cltl3-devel] RFC: CLtL3 Charter

[drew.crampsie at gmail.com]

2009/9/1 Ian Mondragon <ian.mondragon at gmail.com>:
> 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 :).

> 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...

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?

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.. regexps are not simple, and can be  
implemented without implementation support, so there is no good reason to  
include them in the base language.

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?

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.

So, to turn the question around, how would including cl-ppcre help meet the  
goals of the project as outlined in the charter?

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.

Cheers,

drewc


On Sep 1, 2009 12:43pm, Drew Crampsie <drewc at tech.coop> wrote:




> 2009/9/1 Ian Mondragon ian.mondragon at gmail.com>:

> > 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 like.



> 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 :).



> > 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...



> 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?



> 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.. regexps are not simple, and can be  
> implemented without implementation support, so there is no good reason to  
> include them in the base language.



> 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?



> Edi himself has spoken against the idea of 'standardising' on cl-ppcre (i  
> can't find the reference right now), but IIRC his reasoning was similar  
> to mine.



> So, to turn the question around, how would including cl-ppcre help meet  
> the goals of the project as outlined in the charter?



> Again, i'll be your devil's advocate for the duration of these  
> discussions, so please don't assume i'm dismissing this

















> >

> > Just food for thought.

> >

> > :ian

> >

> > On Mon, Aug 31, 2009 at 2:57 PM, Drew Crampsie drewc at tech.coop> wrote:

> >>

> >> Hello all,

> >>

> >> Below is a draft of the charter for the CLtL3 project. Please comment

> >> as you see fit.

> >>

> >> Cheers,

> >>

> >> drewc

> >>

> >> Purposes of the CLtL3 effort. SECOND DRAFT - 2009-08-31 -

> >>

> >> 1) The CLtL3 group wishes to create an updated description of Common

> >> Lisp. It should codify existing practice and provide additional

> >> features to facilitate portability of code among diverse

> >> implementations.

> >>

> >> 2) The group intends the description to be a base for a  
> larger "standard

> >> library" of code. The focus of the effort will be to provide

> >> library authors with a stable and portable lisp on which to build

> >> an evolving distribution that meets the ever changing needs of

> >> modern developers.

> >>

> >> 3) The group will begin with ANSI Common Lisp as described in the

> >> _Common Lisp Hyperspec_. All possible effort will be made to ensure

> >> source compatibility. The group does not intend to remove any

> >> functionality from the language, and will only deprecate features

> >> that are superseded by those in CLtL3.

> >>

> >> 4) The group will address the following topics in the course of

> >> producing the description. Preference will be given to topics that

> >> cannot be implemented portably and have multiple existing

> >> implementations.

> >>

> >> (a) Repairing mistakes, ambiguities, and minor ommissions

> >> in ANSI Common Lisp

> >> (b) Extensions outlined in the CDR (including the MOP)

> >> (c) Multiprocessing and Concurrency

> >> (d) Foreign Function Interfaces

> >> (e) Extensible Streams

> >> (f) Extensible Sequences

> >> (g) Networking

> >> (h) OS and Filesystem access

> >> (i) Editing and Introspection

> >>

> >> 5) The CLtL3 effort will be a community effort.Discussion will take

> >> place on public forums. Any source code or documents produced will

> >> be placed under a permissive open source license that also allows

> >> commercial use and redistribution.

> >>

> >> _______________________________________________

> >> cltl3-devel mailing list

> >> cltl3-devel at common-lisp.net

> >> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

> >

> >



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090901/ae96d991/attachment.html>