2009/9/1 Ian Mondragon ian.mondragon@gmail.com:
I'll second (or third?) the appreciation of the simplicity.
Two questions though:
- 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.
- 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:
- 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.
- 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 -
- 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.
- 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.
- 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.
- 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
- 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