New subject: [cltl3-devel] RFC: CLtL3 Charter

1 Sep 2009

      2009/9/1 Ian Mondragon <ian.mondragon@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@tech.coop> wrote:
...
2009/9/1 Ian Mondragon ian.mondragon@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@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@common-lisp.net
...
...
...
http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
...
...
...
...

Re: [cltl3-devel] RFC: CLtL3 Charter

drew.crampsie＠gmail.com

Ian Mondragon

Stanislaw Halik

John Cowan

tags

participants (4)