From antoniotti.marco at disco.unimib.it  Tue Sep  1 13:09:39 2009
From: antoniotti.marco at disco.unimib.it (Marco Antoniotti)
Date: Tue, 1 Sep 2009 15:09:39 +0200
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
Message-ID: <C0657F84-DEF8-4F33-96E3-43A4B6C10FDA@disco.unimib.it>

Sometimes (or always?!?) keeping things simple makes a lot of sense.

I personally agree with what has been written in the CLtL3 charter.

Cheers
--
Marco


On Aug 31, 2009, at 21:57 , Drew Crampsie 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

--
Marco Antoniotti, Associate Professor				tel.	+39 - 02 64 48 79 01
DISCo, Universit? Milano Bicocca U14 2043
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.








From drewc at tech.coop  Tue Sep  1 17:21:47 2009
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 1 Sep 2009 10:21:47 -0700
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
Message-ID: <bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>

2009/9/1 Gustavo <gugamilare at gmail.com>:
> Hello,
>
> I also like to keep things simple. Here are a few suggestions, though.
>
> In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't
> know if that is intended to be included in "Networking", because Unix
> sockets are local to the computer.

To be quite honest, i don't know if CLtL3 actually needs sockets or
networking. If we have FFI and extensible streams, we can build
sockets and networking as library code.. right? I'm interested in
hearing dissent on this one.

>
> A few more topics that could be discussed:
>
> (j) Interface to Environments, which is needed in a macro walker (e.g.
> cl-walker accesses lexical environments using implementation specific
> functions).

I'm interested in this as well... but macroexpand-dammit shows one
doesn't need environments to do a portable walker. However, most lisps
have CLtL2 environments at least, so i'll add this to the list.

> (k)Custom Hash Functions and Hashtable Test (SBCL's extensions).

This is covered by a CDR, and so is on the list already.

> (l) Weak Pointers, Weak Hashtables and Garbage Collector (like in
> trivial-garbage).

Right, i was just thinking about these last night. added.

> And, by the way, "omission" have only one "m".

Damnit... i've been spelling that word wrong my entire life and just
found out now! thanks :)

drewc
>
> Cheers,
> Gustavo.
>
> 2009/8/31 Drew Crampsie <drewc at tech.coop>
>>
>> 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
>
>



From gugamilare at gmail.com  Tue Sep  1 16:37:18 2009
From: gugamilare at gmail.com (Gustavo)
Date: Tue, 1 Sep 2009 13:37:18 -0300
Subject: [cltl3-devel] Fwd:  RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
Message-ID: <4be8713d0909010937o77114b3w2df63b860b2a919@mail.gmail.com>

Sorry, drewc, the e-mail should have gone to the list, not only you.


Hello,

I also like to keep things simple. Here are a few suggestions, though.

In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't
know if that is intended to be included in "Networking", because Unix
sockets are local to the computer.

A few more topics that could be discussed:

(j) Interface to Environments, which is needed in a macro walker (e.g.
cl-walker <http://common-lisp.net/project/cl-walker/> accesses lexical
environments using implementation specific functions).
(k)Custom Hash Functions and Hashtable Test (SBCL's
extensions<http://www.sbcl.org/manual/Hash-Table-Extensions.html#Hash-Table-Extensions>
).
(l) Weak Pointers, Weak Hashtables and Garbage Collector (like in
trivial-garbage <http://www.cliki.net/trivial-garbage>).

And, by the way, "omission" have only one "m".

Cheers,
Gustavo.

2009/8/31 Drew Crampsie <drewc at tech.coop>

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/92381a86/attachment.html>

From malcolm.reynolds at gmail.com  Tue Sep  1 17:39:21 2009
From: malcolm.reynolds at gmail.com (Malcolm Reynolds)
Date: Tue, 1 Sep 2009 18:39:21 +0100
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com> 
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com> 
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
Message-ID: <dcb2fcee0909011039t5b3113d9kf9f4b68dd1f2e897@mail.gmail.com>

On Tue, Sep 1, 2009 at 6:21 PM, Drew Crampsie<drewc at tech.coop> wrote:
> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>> Hello,
>>
>> I also like to keep things simple. Here are a few suggestions, though.
>>
>> In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't
>> know if that is intended to be included in "Networking", because Unix
>> sockets are local to the computer.
>
> To be quite honest, i don't know if CLtL3 actually needs sockets or
> networking. If we have FFI and extensible streams, we can build
> sockets and networking as library code.. right? I'm interested in
> hearing dissent on this one.
>

I've only been working with CL for 6 months so take all my opinions
with that in mind.. but I think not having native sockets / networking
is a big minus for a language in this day and age. To a relative
beginner like me, having to use FFI (I know what this is but have
never touched it myself) and extensible streams (I don't really have a
concrete idea of what these entail, is it in any way similar to Java
*OutputStream classes?) just to write to the network seems like quite
a lot of hoops to jump through as opposed to just using some
standardised functions. And I understand the situation now is that
there are a plethora of networking libraries, which no doubt causes
confusion when coming to the language for the first time... I think
forcing implementations to include network code which you can rely on
to be maintained and debugged is a big win.

Cheers,

Malcolm



From drewc at tech.coop  Tue Sep  1 18:24:36 2009
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 1 Sep 2009 11:24:36 -0700
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <dcb2fcee0909011039t5b3113d9kf9f4b68dd1f2e897@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
	<dcb2fcee0909011039t5b3113d9kf9f4b68dd1f2e897@mail.gmail.com>
Message-ID: <bc10d2190909011124x86de908k3816094e76eea6af@mail.gmail.com>

2009/9/1 Malcolm Reynolds <malcolm.reynolds at gmail.com>:
> On Tue, Sep 1, 2009 at 6:21 PM, Drew Crampsie<drewc at tech.coop> wrote:
>> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>>> Hello,
>>>
>>> I also like to keep things simple. Here are a few suggestions, though.
>>>
>>> In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't
>>> know if that is intended to be included in "Networking", because Unix
>>> sockets are local to the computer.
>>
>> To be quite honest, i don't know if CLtL3 actually needs sockets or
>> networking. If we have FFI and extensible streams, we can build
>> sockets and networking as library code.. right? I'm interested in
>> hearing dissent on this one.
>>
>
> I've only been working with CL for 6 months so take all my opinions
> with that in mind.. but I think not having native sockets / networking
> is a big minus for a language in this day and age.

Section 2 of the charter mentions a 'standard library', which will
include sockets and networking code. It is a lot easier, as a
community,  to ship a library than it is implementation-specific code.
You, as a user, would use the 'standard library' and not care.

>To a relative
> beginner like me, having to use FFI (I know what this is but have
> never touched it myself) and extensible streams (I don't really have a
> concrete idea of what these entail, is it in any way similar to Java
> *OutputStream classes?) just to write to the network seems like quite
> a lot of hoops to jump through as opposed to just using some
> standardised functions.

As a user, you would not need to write your own networking library
just to use the network.. library implementors would do this for you,
as they do now. The fact is that current implementations build their
networking code on the equivalent of FFI and extensible streams, so
that's all that really needs describing (read 'standardised') in order
to build a portable sockets/networking library.

>And I understand the situation now is that
> there are a plethora of networking libraries, which no doubt causes
> confusion when coming to the language for the first time...

The goal of the CLtL3 project is not to make the language easier for
those using it the first time, it's to provide a solid foundation for
library authors and promote portability among implementations. Many
things in CL are confusing to newcomers, and it is not our expressed
goal to change this.

Rather, the goals of CLtL3 are to provide enough of a "Common Lisp"
base language so that things like networking libraries and the like
may be implemented using portable constructs rather than
implementation-specific ones. As a newcomer, this may not seem as
important to you has using the same network library as everyone else,
but from those trying to provide that networking library, it's
extremely important... vital even.

> I think
> forcing implementations to include network code which you can rely on
> to be maintained and debugged is a big win.

"forcing implementations" is not something we want or plan to do. We
rather hope to keep things simple enough that the cost of adoption for
implementations is a minimal as possible. If we have to force
implementors to do anything, we'll have lost the battle before it's
even begun.

For a new user like yourself, it's not going to matter if networking
is in CLtL3 or the 'standard library' whatsoever. For an implementor,
not having to support all that extra code in the library is a big plus
and lowers the barriers to adoption... they can just ship CLtL3
compatibility, and let us worry about the 'standard library'.

Which do you think is better, many implementations of the same
protocol scattered among lisps, or a single-sourced library built on
portable constructs that have been provided by each implementation? My
opinion is that the latter is likely to provide a better user
experience with less effort to implementors than the former, and hence
more likely to see wide adoption.

I'm playing devil's advocate to a certain extent, so please don't take
my arguments as a brushing off of your needs. I'm interested in
hearing rebuttals and more dissent, but the goals expressed in the
charter must be kept in mind... keeping CLtL3 small and simple is the
only way it's going to work, and if we can remove the need to describe
something large and complex like networking and sockets, we'll have a
better chance of actually achieving something rather than just arguing
about it :).


Cheers,
drewc







>
> Cheers,
>
> Malcolm
>



From ian.mondragon at gmail.com  Tue Sep  1 19:05:16 2009
From: ian.mondragon at gmail.com (Ian Mondragon)
Date: Tue, 1 Sep 2009 14:05:16 -0500
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
Message-ID: <9b8ed3b80909011205q54239b38j86f7ba9be5878d34@mail.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...

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

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/62c723f5/attachment.html>

From drew.crampsie at gmail.com  Tue Sep  1 20:40:38 2009
From: drew.crampsie at gmail.com (drew.crampsie at gmail.com)
Date: Tue, 01 Sep 2009 20:40:38 +0000
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
Message-ID: <0016e648fca6bc77dc04728a295a@google.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>

From malcolm.reynolds at gmail.com  Tue Sep  1 21:39:18 2009
From: malcolm.reynolds at gmail.com (Malcolm Reynolds)
Date: Tue, 1 Sep 2009 22:39:18 +0100
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011124x86de908k3816094e76eea6af@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com> 
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com> 
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com> 
	<dcb2fcee0909011039t5b3113d9kf9f4b68dd1f2e897@mail.gmail.com> 
	<bc10d2190909011124x86de908k3816094e76eea6af@mail.gmail.com>
Message-ID: <dcb2fcee0909011439j6c6f7725qa7a05190a4d1647a@mail.gmail.com>

> Section 2 of the charter mentions a 'standard library', which will
> include sockets and networking code. It is a lot easier, as a
> community, ?to ship a library than it is implementation-specific code.
> You, as a user, would use the 'standard library' and not care.

Okay, this is sounds good. Essentially my point would come down to "it
should be easy to do networking in CLtL3" and if the path of least
resistance is to standardise FFI and streams then that definitely
makes sense.

I definitely appreciate your point about it not necessarily being
about making CL easier for newcomers, as clearly a lot of the complex
and initially confusing stuff is what, in the end, makes it a good
language. As long as the end user experience of writing network code
is (approximately) as simple as in newer scripting languages, I agree
that whether you're using a standard library or standardised language
features makes no odds, and so the approach of keeping it simple in
order to make for an easy (ish!) standardisation process is the right
choice.

Malcolm



From ian.mondragon at gmail.com  Wed Sep  2 00:39:29 2009
From: ian.mondragon at gmail.com (Ian Mondragon)
Date: Tue, 1 Sep 2009 19:39:29 -0500
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <0016e648fca6bc77dc04728a295a@google.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
Message-ID: <9b8ed3b80909011739r43efb4fcoa27292eeb396e8ee@mail.gmail.com>

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>

From gugamilare at gmail.com  Wed Sep  2 00:47:01 2009
From: gugamilare at gmail.com (Gustavo)
Date: Tue, 1 Sep 2009 21:47:01 -0300
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
Message-ID: <4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>

2009/9/1 Drew Crampsie <drewc at tech.coop>

> 2009/9/1 Gustavo <gugamilare at gmail.com>:
> > Hello,
> >
> > I also like to keep things simple. Here are a few suggestions, though.
> >
> > In paragraph 4, you didn't mention "sockets" explicitly in the list. I
> don't
> > know if that is intended to be included in "Networking", because Unix
> > sockets are local to the computer.
>
> To be quite honest, i don't know if CLtL3 actually needs sockets or
> networking. If we have FFI and extensible streams, we can build
> sockets and networking as library code.. right? I'm interested in
> hearing dissent on this one.
>

Well, yes, but all implementations that I know about have some interface to
sockets. So, I believe that this is a very small task for implementors, it
is just a matter of creating a small layer on top of them (like
usocket<http://common-lisp.net/project/usocket/>)
or changing the functions that deal with them. Isn't Cltl3 meant to avoid
the need for portability layers?

Maybe we could make the support for sockets optional for each
implementation, but standardize the interface for sockets for
implementations that want to provide them (something like "These functions
may signal an error if the implementations doesn't have support for
sockets.").

>
> >
> > A few more topics that could be discussed:
> >
> > (j) Interface to Environments, which is needed in a macro walker (e.g.
> > cl-walker accesses lexical environments using implementation specific
> > functions).
>
> I'm interested in this as well... but macroexpand-dammit shows one
> doesn't need environments to do a portable walker. However, most lisps
> have CLtL2 environments at least, so i'll add this to the list.
>
> > (k)Custom Hash Functions and Hashtable Test (SBCL's extensions).
>
> This is covered by a CDR, and so is on the list already.
>

I know, but I didn't like the approach of that CDR. I think that the
standard functions gethash, make-hash-table, etc, should work for generic
hashtables, no new packages should be needed. It also should specify how the
type (or class) GENERIC-HASH-TABLE should be related to the system class
HASH-TABLE (Is it a subtype? A proper subtype? Or a disjoint type?) or to
other types. Well, it even didn't define such a type, but I think we shoud.
I believe that we could discuss it later, when we discuss the CDR documents
(we are going to do that, aren't we?).

>
> > (l) Weak Pointers, Weak Hashtables and Garbage Collector (like in
> > trivial-garbage).
>
> Right, i was just thinking about these last night. added.
>
> > And, by the way, "omission" have only one "m".
>
> Damnit... i've been spelling that word wrong my entire life and just
> found out now! thanks :)
>

Thank my Firefox's spell checker :)

One more suggestion: you could add this sentence or something similar (after
paragraph 4):

"Other topics might be discussed in the course of the description, but
priority will be given to the topics mentioned above."

This way we can choose to discuss lesser details later.


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

From luismbo at gmail.com  Wed Sep  2 01:01:17 2009
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Wed, 2 Sep 2009 02:01:17 +0100
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com> 
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com> 
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com> 
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
Message-ID: <391f79580909011801h79fa0c09w9d7b30961e298bab@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:47 AM, Gustavo<gugamilare at gmail.com> wrote:
> I know, but I didn't like the approach of that CDR. I think that the
> standard functions gethash, make-hash-table, etc, should work for generic
> hashtables, no new packages should be needed. It also should specify how the
> type (or class) GENERIC-HASH-TABLE should be related to the system class
> HASH-TABLE (Is it a subtype? A proper subtype? Or a disjoint type?)

Indeed, the approach followed by Christophe Rhodes in his extensible
sequences paper is much more appropriate.

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/



From drewc at tech.coop  Wed Sep  2 01:30:43 2009
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 1 Sep 2009 18:30:43 -0700
Subject: [cltl3-devel] Fwd:  RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
Message-ID: <bc10d2190909011830x5ea215ear2cd05eac415f1cae@mail.gmail.com>

bloody list .. always forget to cc


---------- Forwarded message ----------
From: Drew Crampsie <drewc at tech.coop>
Date: 2009/9/1
Subject: Re: [cltl3-devel] RFC: CLtL3 Charter
To: Gustavo <gugamilare at gmail.com>


2009/9/1 Gustavo <gugamilare at gmail.com>:
>
>
> 2009/9/1 Drew Crampsie <drewc at tech.coop>
>>
>> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>> > Hello,
>> >
>> > I also like to keep things simple. Here are a few suggestions, though.
>> >
>> > In paragraph 4, you didn't mention "sockets" explicitly in the list. I
>> > don't
>> > know if that is intended to be included in "Networking", because Unix
>> > sockets are local to the computer.
>>
>> To be quite honest, i don't know if CLtL3 actually needs sockets or
>> networking. If we have FFI and extensible streams, we can build
>> sockets and networking as library code.. right? I'm interested in
>> hearing dissent on this one.
>
> Well, yes, but all implementations that I know about have some interface to
> sockets. So, I believe that this is a very small task for implementors, it
> is just a matter of creating a small layer on top of them (like usocket) or
> changing the functions that deal with them. Isn't Cltl3 meant to avoid the
> need for portability layers?

Yes, avoiding portability layers is a goal.. so when you state " it is
just a matter of creating a small layer on top of them (like
usocket)", we're directly against that goal. usocket and the like
exist already, so there's not much value in working to standardize the
interface... just use usocket! :)

I'm not sure what you mean by 'changing the functions that deal with
them' in this context, but a goal of cltl3 (i will add this to the
charter) is to require as little effort on the part of implementors as
possible. In the case of sockets and networking, we can provide
library code from a single source... so why duplicate that effort
across every distribution or implementation of lisp? Seems like a
wasted effort and a barrier to adoption from my POV.

It is possible, given FFI and gray streams, to implement sockets
without using _any_ implementation defined socket code. Rather than a
compatibility layer that attempts to paper over the differences in
implementations (trouble with such layers being a large motivation for
the creation of CLtL3), i'd prefer a single canonical implementation
based on constructs provided by CLtL3.

The prior art here (as for a lot of things we will be discussing) is
IOlib. IOlib uses its own implementation of sockets and networking
based on the OS's underlying implementation (through FFI). It is
mostly portable and uniform across implementations, and does not
require any support for networking in the implementation itself
(fe[nl]ix had better correct me if i'm wrong).

> Maybe we could make the support for sockets optional for each
> implementation, but standardize the interface for sockets for
> implementations that want to provide them (something like "These functions
> may signal an error if the implementations doesn't have support for
> sockets.").

This is exactly what i'd like to avoid. If we have a portable
implementation based on the simple constructs we plan to describe in
CLtL3, we remove the need for implementors to support (or not support)
our idea of what a socket library could be. We have no need to
standardize an interface that implementors must support when we can
write a portable interface. We can still call it 'standard' if you
like, but 'standard library' and not 'cltl3', whatever that means :).

CLtL3 should be for things that _cannot_ be implemented portably,
first and foremost. Sockets and networking _can_ be, on operating
system that support them, via FFI. The goal of CLtL3 is to create a
lisp where it is possible to have portable networking code, but not
necessarily to include that code in the language itself... The line
between 'library' and 'base language' was heavily blurred during the
ANSI process... i'd prefer not to repeat that (what i view as a)
mistake.

CL pathnames are the perfect example of what happens when you try to
lowest-common-denominator these kind of things, and that's all we'd be
able to do if we relied on existing implementation support. Going the
other way, and expecting implementors and vendors to conform to our
idea of what socket code should be is just as useless because, well,
they won't.

Simply asked : what exactly do we gain by requiring a socket and
networking layer as part of the base language, as opposed to in the
library we plan to build on that language? If all you want is a
uniform API, a standard library will have that. Heck, if you want
that, code against IOlib!

I'm still not dismissing inclusion of networking and sockets, but i've
not heard a convincing argument for them, and i think our time would
be better spent elsewhere.


[snipped bit about hash tables]

> I believe that we could discuss it later, when we discuss the CDR documents
> (we are going to do that, aren't we?).

You bet. :)

Cheers,

drewc


>>
>> > (l) Weak Pointers, Weak Hashtables and Garbage Collector (like in
>> > trivial-garbage).
>>
>> Right, i was just thinking about these last night. added.
>>
>> > And, by the way, "omission" have only one "m".
>>
>> Damnit... i've been spelling that word wrong my entire life and just
>> found out now! thanks :)
>
> Thank my Firefox's spell checker :)
>
> One more suggestion: you could add this sentence or something similar (after
> paragraph 4):
>
> "Other topics might be discussed in the course of the description, but
> priority will be given to the topics mentioned above."
>
> This way we can choose to discuss lesser details later.
>
>>
>> drewc
>
>
> _______________________________________________
> cltl3-devel mailing list
> cltl3-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
>
>



From gugamilare at gmail.com  Wed Sep  2 01:04:48 2009
From: gugamilare at gmail.com (Gustavo)
Date: Tue, 1 Sep 2009 22:04:48 -0300
Subject: [cltl3-devel] Fwd:  RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909011804q562c0a88v4fd594acb012ad44@mail.gmail.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
	<4be8713d0909011753k412c1990r543925766852fcb3@mail.gmail.com>
	<4be8713d0909011804q562c0a88v4fd594acb012ad44@mail.gmail.com>
Message-ID: <4be8713d0909011804v41ef3fa0x36a99c71dca8e9d6@mail.gmail.com>

2009/9/1 <drew.crampsie at gmail.com>

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

cl-ppcre allow the use of sexps as regexps. I think that they are "verbose"
and "understandable".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090901/b6272d96/attachment.html>

From drew.crampsie at gmail.com  Wed Sep  2 01:40:12 2009
From: drew.crampsie at gmail.com (Drew Crampsie)
Date: Tue, 1 Sep 2009 18:40:12 -0700
Subject: [cltl3-devel] Fwd:  RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
	<4be8713d0909011753k412c1990r543925766852fcb3@mail.gmail.com>
	<bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com>
Message-ID: <bc10d2190909011840s4213fas5ff88194b45cbb8c@mail.gmail.com>

did it again .. somebody smack me upside the head!


---------- Forwarded message ----------
From: Drew Crampsie <drew.crampsie at gmail.com>
Date: 2009/9/1
Subject: Re: [cltl3-devel] RFC: CLtL3 Charter
To: Gustavo <gugamilare at gmail.com>


2009/9/1 Gustavo <gugamilare at gmail.com>:
>
>
> 2009/9/1 <drew.crampsie at gmail.com>
>>
>> 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..
>
> cl-ppcre allow the use of sexps as regexps. I think that they are "verbose"
> and "understandable".

So it might ... but as per section 4 "Preference will be given to
topics that cannot be implemented portably and have multiple existing
implementations.".

There will be a library folks, and that is what you as a coder will
likely use. CLtL3 is not for coders, but for implementors and library
authors (who, yes, are also coders but you get the idea). It's for
things we can't currently do in portable common lisp, not for things
that have been done and already see wide use. There is nothing holding
back the acceptance of cl-ppcre as the 'standard' ?portable
implementation of perl compatible regular expressions, so why waste
time documenting and discussing it?

It will take an incredible amount of effort to describe in any detail
the interface of cl-ppcre, and for little to no gain. When a new perl
comes out, do we go ahead and change the standard? do we freeze
cl-ppcre at the time we publish CLtL3?

I understand that what a lot of people want is a 'standard library',
and not an updated description. I'd like that too. But we have to get
there somehow, and as it stands we cannot build our 'standard library'
on Standard Common Lisp. That is what CLtL3 is trying to fix.

Cheers,

drewc

>



From gugamilare at gmail.com  Wed Sep  2 01:44:58 2009
From: gugamilare at gmail.com (Gustavo)
Date: Tue, 1 Sep 2009 22:44:58 -0300
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
	<4be8713d0909011753k412c1990r543925766852fcb3@mail.gmail.com>
	<bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com>
Message-ID: <4be8713d0909011844i24e971d5tbfb7ea0644a0d731@mail.gmail.com>

2009/9/1 Drew Crampsie <drew.crampsie at gmail.com>

> 2009/9/1 Gustavo <gugamilare at gmail.com>:
> >
> >
> > 2009/9/1 <drew.crampsie at gmail.com>
> >>
> >> 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..
> >
> > cl-ppcre allow the use of sexps as regexps. I think that they are
> "verbose"
> > and "understandable".
>
> So it might ... but as per section 4 "Preference will be given to
> topics that cannot be implemented portably and have multiple existing
> implementations.".
>

I'm not saying that cl-ppcre should be made part of cltl3, I actually agree
with you. That was just an off-topic comment (if someone doesn't know that
already).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090901/9d10a2f3/attachment.html>

From luismbo at gmail.com  Wed Sep  2 01:48:11 2009
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Wed, 2 Sep 2009 02:48:11 +0100
Subject: [cltl3-devel] Fwd: RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011840s4213fas5ff88194b45cbb8c@mail.gmail.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com> 
	<0016e648fca6bc77dc04728a295a@google.com>
	<4be8713d0909011753k412c1990r543925766852fcb3@mail.gmail.com> 
	<bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com> 
	<bc10d2190909011840s4213fas5ff88194b45cbb8c@mail.gmail.com>
Message-ID: <391f79580909011848n7dbe9393k8ecfd40766520b24@mail.gmail.com>

On Wed, Sep 2, 2009 at 2:40 AM, Drew Crampsie<drew.crampsie at gmail.com> wrote:
> I understand that what a lot of people want is a 'standard library',
> and not an updated description. I'd like that too. But we have to get
> there somehow, and as it stands we cannot build our 'standard library'
> on Standard Common Lisp. That is what CLtL3 is trying to fix.

Point 2 is perhaps a bit confusing on this matter. Is building such a
library part of the CLtL3 effort? If not, point 2 doesn't make that
very clear.

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/



From drew.crampsie at gmail.com  Wed Sep  2 01:57:22 2009
From: drew.crampsie at gmail.com (Drew Crampsie)
Date: Tue, 1 Sep 2009 18:57:22 -0700
Subject: [cltl3-devel] Fwd: RFC: CLtL3 Charter
In-Reply-To: <391f79580909011848n7dbe9393k8ecfd40766520b24@mail.gmail.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
	<4be8713d0909011753k412c1990r543925766852fcb3@mail.gmail.com>
	<bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com>
	<bc10d2190909011840s4213fas5ff88194b45cbb8c@mail.gmail.com>
	<391f79580909011848n7dbe9393k8ecfd40766520b24@mail.gmail.com>
Message-ID: <bc10d2190909011857v51447183r6fd9f5b63ddfa603@mail.gmail.com>

2009/9/1 Lu?s Oliveira <luismbo at gmail.com>:
> On Wed, Sep 2, 2009 at 2:40 AM, Drew Crampsie<drew.crampsie at gmail.com> wrote:
>> I understand that what a lot of people want is a 'standard library',
>> and not an updated description. I'd like that too. But we have to get
>> there somehow, and as it stands we cannot build our 'standard library'
>> on Standard Common Lisp. That is what CLtL3 is trying to fix.
>
> Point 2 is perhaps a bit confusing on this matter. Is building such a
> library part of the CLtL3 effort? If not, point 2 doesn't make that
> very clear.

Getting to the point where we can build such a library is the purpose
of the CLtL3 effort. That library (or libraries.. competition is good)
will come later, once it's possible to build it :). It may indeed be
the same people who work on cltl3 that make (or gather) the library,
and i'd like to document the library as a part of CLtL3 (one stop
shopping!), but we need to get there first.

My personal goals involve building such a library, but i want to limit
the scope of the (initial) CLtL3 effort to something that can actually
be achieved,  and be useful, with minimal effort on the parts of all
involved.

At one point the idea of three levels was mentioned : base,
extensions, and library. Our initial focus should be on the base
language, and be kept as small and simple as possible. If, in
parallel, library authors wish to write code to CLtL3 rather than ANSI
+ extensions, that's a big plus.

So, point 2 might need a little re-wording if the intent is not clear.

Cheers,

drewc

>
> --
> Lu?s Oliveira
> http://student.dei.uc.pt/~lmoliv/
>



From gugamilare at gmail.com  Wed Sep  2 03:41:15 2009
From: gugamilare at gmail.com (Gustavo)
Date: Wed, 2 Sep 2009 00:41:15 -0300
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
Message-ID: <4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>

2009/9/1 Drew Crampsie <drewc at tech.coop>

> 2009/9/1 Gustavo <gugamilare at gmail.com>:
> >
> >
> > 2009/9/1 Drew Crampsie <drewc at tech.coop>
> >>
> >> 2009/9/1 Gustavo <gugamilare at gmail.com>:
> >> > Hello,
> >> >
> >> > I also like to keep things simple. Here are a few suggestions, though.
> >> >
> >> > In paragraph 4, you didn't mention "sockets" explicitly in the list. I
> >> > don't
> >> > know if that is intended to be included in "Networking", because Unix
> >> > sockets are local to the computer.
> >>
> >> To be quite honest, i don't know if CLtL3 actually needs sockets or
> >> networking. If we have FFI and extensible streams, we can build
> >> sockets and networking as library code.. right? I'm interested in
> >> hearing dissent on this one.
> >
> > Well, yes, but all implementations that I know about have some interface
> to
> > sockets. So, I believe that this is a very small task for implementors,
> it
> > is just a matter of creating a small layer on top of them (like usocket)
> or
> > changing the functions that deal with them. Isn't Cltl3 meant to avoid
> the
> > need for portability layers?
>
> Yes, avoiding portability layers is a goal.. so when you state " it is
> just a matter of creating a small layer on top of them (like
> usocket)", we're directly against that goal. usocket and the like
> exist already, so there's not much value in working to standardize the
> interface... just use usocket! :)
>

Well, maybe I didn't expressed myself clearly. And I didn't quite get your
point. If you go down that road, we could say that we don't need to
standardize FFI or threads as well ("just use CFFI or bordaux-threads" -
usocket is just as much of a portability layer as CFFI or bordeaux-threads
is). In the part of "just create a small layer on top of them", I meant
internally in each implementation. Each implementation will take the
functions to manipulate sockets that it already has and create the standard
functions on top of them or make small modifications appropriately to make
those functions conform with the standard. This is what I believe that will
be done by implementations to conform FFI, thread and any other standard we
create here, isn't it?

>
> I'm not sure what you mean by 'changing the functions that deal with
> them' in this context, but a goal of cltl3 (i will add this to the
> charter) is to require as little effort on the part of implementors as
> possible. In the case of sockets and networking, we can provide
> library code from a single source... so why duplicate that effort
> across every distribution or implementation of lisp? Seems like a
> wasted effort and a barrier to adoption from my POV.
>

My point is that every implementation already support sockets, it should be
much better if there was a standard interface so they could implement socket
interface uniformly across implementations.

>
> It is possible, given FFI and gray streams, to implement sockets
> without using _any_ implementation defined socket code. Rather than a
> compatibility layer that attempts to paper over the differences in
> implementations (trouble with such layers being a large motivation for
> the creation of CLtL3), i'd prefer a single canonical implementation
> based on constructs provided by CLtL3.
>

I believe it would also be possible to implement multiple threading that way
(using FFI, if it support callbacks (as CFFI does)). But I'm not going
further on this topic.

>
> The prior art here (as for a lot of things we will be discussing) is
> IOlib. IOlib uses its own implementation of sockets and networking
> based on the OS's underlying implementation (through FFI). It is
> mostly portable and uniform across implementations, and does not
> require any support for networking in the implementation itself
> (fe[nl]ix had better correct me if i'm wrong).


Using IOlib has its drawbacks. It is a big library, one more dependency and
it will only add functionality that is already present in all Lisp
implementations. It also uses grays streams, which are not optimized streams
(so implementation specific's sockets should be faster for good
implementations). And it uses FFI, which is a barrier when you need to save
and load lisp images.

>
> > Maybe we could make the support for sockets optional for each
> > implementation, but standardize the interface for sockets for
> > implementations that want to provide them (something like "These
> functions
> > may signal an error if the implementations doesn't have support for
> > sockets.").
>
> This is exactly what i'd like to avoid.


Fair enough.

> [snipped]
>
> I'm still not dismissing inclusion of networking and sockets, but i've
> not heard a convincing argument for them, and i think our time would
> be better spent elsewhere.
>

I still can't really see why standardizing sockets is so different from
other topics that were included. I agree with you when you say our time will
be better spent in other subjects for now, but I really think we should
discuss this at some point. Lack of standard sockets is one of the topics
that are most oftenly mentioned when the subject is "what are CL's negative
points".

Well, I guess I am the one playing the devil's advocate now :)

>
>
> [snipped bit about hash tables]
>
> > I believe that we could discuss it later, when we discuss the CDR
> documents
> > (we are going to do that, aren't we?).
>
> You bet. :)
>
> Cheers,
>
> drewc
>
>
By the way, a few more topics that can be discussed:

* Features (as in trivial-features - e.g. when should x86-64 or x86 or
darwin features be provided)
* (Per-package ?) Readtables (I believe we *really* should discuss about
readtables, it would avoid many of the hacks that are needed for using read
macros - clsql is the canonical example)
* Declarations and other optimizations - For instance, ECL has a declaration
to freeze some generic function to avoid redefinition or including new
methods, which is used for optimization. Freezing functions and types may be
useful as well. Something like a standard
sb-ext:defglobal<http://www.sbcl.org/manual/Global-and-Always_002dBound-variables.html#Global-and-Always_002dBound-variables>,
including sb-ext:global and sb-ext:always-bound proclamations, are welcome.
I don't know if these are good ideas, but it would be very simple and easy
to both include and implement (since actually using the declarations is
optional, and defglobal can be implemented as an usual defvar).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090902/a18d38d1/attachment.html>

From drewc at tech.coop  Wed Sep  2 04:17:09 2009
From: drewc at tech.coop (Drew Crampsie)
Date: Tue, 1 Sep 2009 21:17:09 -0700
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
	<4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
Message-ID: <bc10d2190909012117i45f320e0u5596976e16f13bc4@mail.gmail.com>

[snipped some context]

>> Yes, avoiding portability layers is a goal.. so when you state " it is
>> just a matter of creating a small layer on top of them (like
>> usocket)", we're directly against that goal. usocket and the like
>> exist already, so there's not much value in working to standardize the
>> interface... just use usocket! :)
>
> Well, maybe I didn't expressed myself clearly. And I didn't quite get your
> point. If you go down that road, we could say that we don't need to
> standardize FFI or threads as well ("just use CFFI or bordaux-threads" -
> usocket is just as much of a portability layer as CFFI or bordeaux-threads
> is). In the part of "just create a small layer on top of them", I meant
> internally in each implementation. Each implementation will take the
> functions to manipulate sockets that it already has and create the standard
> functions on top of them or make small modifications appropriately to make
> those functions conform with the standard.

Right, i getcha, and i don't necessarily disagree. But, why require
that an implementation have sockets when you don't need them to be
implementation specific?

Sure, given sockets you can create a crude FFI, but it will not be
fast or pretty. However, the socket interface i can create via FFI and
extensible streams is just as good, if not better, than those provided
by individual implementations.

What if i want more functionality for our sockets then those provided
by an implementation? do i ask the implementation to implement my
extension? Again, if we try to force implementors to do anything,
we've lost. We need to gain traction and momentum first.

The point i'm trying to make is that including sockets and networking
in the CLtL3 specification (it's not a standard, lets not call it one)
will require work, and potentially a lot of work, on both our parts
and the parts of implementors. I see a good argument for excluding
them (a perfectly good implementation can be built on the features we
provide), but i've yet to hear a good argument for providing them (in
the description rather than the library) beyond 'because some
implementations have sockets already'.

> This is what I believe that will
> be done by implementations to conform FFI, thread and any other standard we
> create here, isn't it?

That remains to be seen.. this is not ANSI, is not funded by ARPA, and
has little chance of getting anywhere if we start making demands of
implementors. Keep that in mind... nobody has to listen to anything we
come up with. It's our job to make it acceptable.

>> I'm not sure what you mean by 'changing the functions that deal with
>> them' in this context, but a goal of cltl3 (i will add this to the
>> charter) is to require as little effort on the part of implementors as
>> possible. In the case of sockets and networking, we can provide
>> library code from a single source... so why duplicate that effort
>> across every distribution or implementation of lisp? Seems like a
>> wasted effort and a barrier to adoption from my POV.
>
> My point is that every implementation already support sockets, it should be
> much better if there was a standard interface so they could implement socket
> interface uniformly across implementations.

what do you mean by 'standard' and who is the 'they' that will
implement this interface? If the they is us (which is the only they it
could be), then FFI and Extensible Streams are all we require from our
implementations. If the they is implementors, who will pay, who will
convince them it's worthwhile, etc? This is where the main thrust of
my argument lies. We don't need sockets supported by an implementation
if we're given the proper tools to write them ourselves.

What difference does it make if they are in CLtL3 or in the 'standard library'?


>> It is possible, given FFI and gray streams, to implement sockets
>> without using _any_ implementation defined socket code. Rather than a
>> compatibility layer that attempts to paper over the differences in
>> implementations (trouble with such layers being a large motivation for
>> the creation of CLtL3), i'd prefer a single canonical implementation
>> based on constructs provided by CLtL3.
>
> I believe it would also be possible to implement multiple threading that way
> (using FFI, if it support callbacks (as CFFI does)). But I'm not going
> further on this topic.

You'd better not, because that is demonstrably false. Threading
requires implementation support.. think of the simple case of two
threads mutzing about with a hash table. Either you lock the world
(then why bother with threads!), or the implementation must have
primitives that support the notion of multiple strands of execution in
order to avoid race conditions and data corruption.

>>
>> The prior art here (as for a lot of things we will be discussing) is
>> IOlib. IOlib uses its own implementation of sockets and networking
>> based on the OS's underlying implementation (through FFI). It is
>> mostly portable and uniform across implementations, and does not
>> require any support for networking in the implementation itself
>> (fe[nl]ix had better correct me if i'm wrong).
>
> Using IOlib has its drawbacks. It is a big library, one more dependency and
> it will only add functionality that is already present in all Lisp
> implementations.

All lisp implementations? are you sure that all lisp implementations
support all that's in IOlib? Hint: they don't, and that's part of the
reason we're doing CLtL3 :).


> It also uses grays streams, which are not optimized streams
> (so implementation specific's sockets should be faster for good
> implementations). And it uses FFI, which is a barrier when you need to save
> and load lisp images.

Hence a good reason for describing a FFI and an extensible stream
implementation (with a specific stated goal of supporting sockets and
networking, on those platforms where they are available). FFI is
hardly a barrier to saving images... just save the .so in the image as
an array and write it out at run time if you can't find it.

If you think that implementors are going to go ahead and code to
anything we can come up with, you are barking up the wrong tree.
However, if we define a minimal set of features as 'CLtL3', and
provide a reference implementation, there is a chance that it might
gain hold, and users might demand CLtL3 compliance from vendors.


>>
>> I'm still not dismissing inclusion of networking and sockets, but i've
>> not heard a convincing argument for them, and i think our time would
>> be better spent elsewhere.
>
> I still can't really see why standardizing sockets is so different from
> other topics that were included.

You cannot extend sequences without breaking ANSI conformance. You
cannot have FFI and extensible streams without implementation support.
Threads require runtime support. Lisps should have some access to the
OS and filesystem in order to support things like ASDF, file
compilation, etc.

Sockets and networking, OTOH, can be implemented without implementation support.

If we implement it as a library, an implementation is free to clone
the API using fast native streams etc. If we try to force something on
implementors, we will get nowhere.

> I agree with you when you say our time will
> be better spent in other subjects for now, but I really think we should
> discuss this at some point. Lack of standard sockets is one of the topics
> that are most oftenly mentioned when the subject is "what are CL's negative
> points".

Let me reiterate the point that CLtL3 is not a 'standard', and we will
not be standardising anything. CLtL3 is merely a description of
features that modern lisps should provide in order to support our
eventual standard library.

>
> Well, I guess I am the one playing the devil's advocate now :)

It goes back and forth :). Discussion is good!

> By the way, a few more topics that can be discussed:
>
> * Features (as in trivial-features - e.g. when should x86-64 or x86 or
> darwin features be provided)

Excellent.. it's a simple one that needs little discussion but has a
lot of benefit,

> * (Per-package ?) Readtables (I believe we really should discuss about
> readtables, it would avoid many of the hacks that are needed for using read
> macros - clsql is the canonical example)

 I can't believe i forgot readtables! It'll be on the next draft for sure.

> * Declarations and other optimizations - For instance, ECL has a declaration
> to freeze some generic function to avoid redefinition or including new
> methods, which is used for optimization. Freezing functions and types may be
> useful as well. Something like a standard sb-ext:defglobal, including
> sb-ext:global and sb-ext:always-bound proclamations, are welcome. I don't
> know if these are good ideas, but it would be very simple and easy to both
> include and implement (since actually using the declarations is optional,
> and defglobal can be implemented as an usual defvar).

I'll add this to the list as well, in some form or another.

Thanks for all the feedback! Your input has been quite valuable so far.

Cheers,

drewc


>
> _______________________________________________
> cltl3-devel mailing list
> cltl3-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
>
>



From demmeln at in.tum.de  Wed Sep  2 12:32:14 2009
From: demmeln at in.tum.de (Nikolaus Demmel)
Date: Wed, 2 Sep 2009 14:32:14 +0200
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
Message-ID: <EA1C5704-2FE0-42CF-BBFD-655AC3957632@in.tum.de>

Hi,

Am 01.09.2009 um 19:21 schrieb Drew Crampsie:
> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>> <snip>
>
>>
>> A few more topics that could be discussed:
>>
>> (j) Interface to Environments, which is needed in a macro walker  
>> (e.g.
>> cl-walker accesses lexical environments using implementation specific
>> functions).
>
> I'm interested in this as well... but macroexpand-dammit shows one
> doesn't need environments to do a portable walker. However, most lisps
> have CLtL2 environments at least, so i'll add this to the list.
>

Having had to deal with this recently, I think having at least whats  
in CLtL2 would be great. I might be wrong, but I'm not sure you can  
build an full AST - like in cl-walker or arnesi - with the technique  
used in macroexpand-dammit. Although its cool what the macroexpand- 
dammit author has done, it doesn't strike me as very elegant and 'the  
way you would want to do it'.

Although some people in the IRC channel have the opinion that "there  
is nothing you truely need a walker for", I think this view is too  
limited/ignorant. I believe there are (many) valid use cases like  
code introspection/analysis ... How does this relate to the "Editing"  
features meantioned in the draft charta.

Cl-walker not only uses environment augmentation (as in CLtL2  
environments), but also environment introspection. I'm not sure how  
much more effort it would be to include environment introspection  
(both defining a good interface and adoption for implementors) and I  
very much agree with you that for CLtL3 to be successful at all it  
must be as brief and small as possible. On the other hand environment  
access is (unlike say sockets) not something that can be done as part  
of the "standard library". Having said that I think environment  
access is not of the highest priority but should be discussed.

Lisp is all about giving you access to the compiler and I can't see a  
reason why this shouldn't be the case for environments. The rationale  
of not including the CLtL2 environments in the ANSI standard would be  
interesting here.

>> <snip>



From malcolm.reynolds at gmail.com  Wed Sep  2 12:57:50 2009
From: malcolm.reynolds at gmail.com (Malcolm Reynolds)
Date: Wed, 2 Sep 2009 13:57:50 +0100
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909012117i45f320e0u5596976e16f13bc4@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com> 
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com> 
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com> 
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com> 
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com> 
	<4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com> 
	<bc10d2190909012117i45f320e0u5596976e16f13bc4@mail.gmail.com>
Message-ID: <dcb2fcee0909020557jb3232cfy93d0367a292c3813@mail.gmail.com>

> If you think that implementors are going to go ahead and code to
> anything we can come up with, you are barking up the wrong tree.
> However, if we define a minimal set of features as 'CLtL3', and
> provide a reference implementation, there is a chance that it might
> gain hold, and users might demand CLtL3 compliance from vendors.
>
>

Slightly off topic, but if I might enquire.. when you say provide
provide a reference implementation, does that mean picking one of the
open source CL implementations and developing it to include everything
that CLtL3 specifies?

Malcolm



From gugamilare at gmail.com  Wed Sep  2 14:13:44 2009
From: gugamilare at gmail.com (Gustavo)
Date: Wed, 2 Sep 2009 11:13:44 -0300
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909012117i45f320e0u5596976e16f13bc4@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
	<4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
	<bc10d2190909012117i45f320e0u5596976e16f13bc4@mail.gmail.com>
Message-ID: <4be8713d0909020713h4e9bb9f0kd72e804c8b4b96e6@mail.gmail.com>

2009/9/2 Drew Crampsie <drewc at tech.coop>

> [snipped some context]
>
> >> Yes, avoiding portability layers is a goal.. so when you state " it is
> >> just a matter of creating a small layer on top of them (like
> >> usocket)", we're directly against that goal. usocket and the like
> >> exist already, so there's not much value in working to standardize the
> >> interface... just use usocket! :)
> >
> > Well, maybe I didn't expressed myself clearly. And I didn't quite get
> your
> > point. If you go down that road, we could say that we don't need to
> > standardize FFI or threads as well ("just use CFFI or bordaux-threads" -
> > usocket is just as much of a portability layer as CFFI or
> bordeaux-threads
> > is). In the part of "just create a small layer on top of them", I meant
> > internally in each implementation. Each implementation will take the
> > functions to manipulate sockets that it already has and create the
> standard
> > functions on top of them or make small modifications appropriately to
> make
> > those functions conform with the standard.
>
> Right, i getcha, and i don't necessarily disagree. But, why require
> that an implementation have sockets when you don't need them to be
> implementation specific?
>
> Sure, given sockets you can create a crude FFI, but it will not be
> fast or pretty. However, the socket interface i can create via FFI and
> extensible streams is just as good, if not better, than those provided
> by individual implementations.
>
> What if i want more functionality for our sockets then those provided
> by an implementation? do i ask the implementation to implement my
> extension? Again, if we try to force implementors to do anything,
> we've lost. We need to gain traction and momentum first.
>
> The point i'm trying to make is that including sockets and networking
> in the CLtL3 specification (it's not a standard, lets not call it one)
> will require work, and potentially a lot of work, on both our parts
> and the parts of implementors. I see a good argument for excluding
> them (a perfectly good implementation can be built on the features we
> provide), but i've yet to hear a good argument for providing them (in
> the description rather than the library) beyond 'because some
> implementations have sockets already'.
>

All right, I guess you won this discussion. I won't die for not having a
per-implementation interface for sockets. I guess I did not had in mind that
implementors might or might not like Cltl3 and choose to comply with it or
not to care at all.

But, in any case, as I see in usocket's page, all currently alive
implementations that I am aware of (except perhaps Corman CL) have at least
the basics for sockets.

>

 [snipped]
>

> Thanks for all the feedback! Your input has been quite valuable so far.
>

You are welcome. I'm just having some fun.

There are still a bunch of minor things that could be be included in Cltl3,
but I don't know yet how much effort this might take, so this is just a
suggestion. Hooks (hooks for when the gc runs, for when Lisp initializes and
finishes (useful for when you save and load images and need to do some setup
or teardown) and possibly others). There are also functions like quitting
lisp, running an external program, access to a shell (like
trivial-shell<http://common-lisp.net/project/trivial-shell/>)
a way of getting the so-called "posix-argv". The last three might fall in
the "OS and Filesystem access" topic.

Cheers,
Gustavo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090902/078b4b5b/attachment.html>

From levente.meszaros at gmail.com  Wed Sep  2 12:12:08 2009
From: levente.meszaros at gmail.com (=?ISO-8859-1?Q?Levente_M=E9sz=E1ros?=)
Date: Wed, 2 Sep 2009 14:12:08 +0200
Subject: [cltl3-devel] Types
Message-ID: <a0d87c1c0909020512k5ed56fc2v3e0547321bf1cab4@mail.gmail.com>

Hi,

Some issues about the type system that comes to my mind (some of them
might be less important than the others):
 - no reliable way to figure out whether something is a type specifier or not
 - no way to portably expand a type specifier by using its definition
 - practically there is no reflection on types
 - no easy way to specify a parametric type of strings with less than
N characters (this is just an example of the issue: (deftype
length-limited-string (limit) ...)
   due to the limits of satisfies
 - no portable way to get the inferred type of a function, a variable, etc.

Cheers,
levy

-- 
There's no perfectoin



From pkhuong at gmail.com  Wed Sep  2 03:46:38 2009
From: pkhuong at gmail.com (Paul Khuong)
Date: Tue, 1 Sep 2009 23:46:38 -0400
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<4be8713d0909010935w40cd7ad8j7a0dd7356413c5fc@mail.gmail.com>
	<bc10d2190909011021k42f8ed98sabb25a274d407d8f@mail.gmail.com>
	<4be8713d0909011747n6d8df1ccn6e5485c2486833da@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
	<4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
Message-ID: <915046ED-84D0-459C-82E3-2865A25F8813@gmail.com>

On 1-Sep-09, at 11:41 PM, Gustavo wrote:
> I believe it would also be possible to implement multiple threading  
> that way (using FFI, if it support callbacks (as CFFI does)). But  
> I'm not going further on this topic.

No. Even if it were technically possible to implement threading (and  
strictly that) portably using FFI, threads are not a library feature.  
Threads are a language feature. For threads to be useful and  
trustworthy, you must fully specify a boat load of things, from  
atomicness of stores to memory barriers and observable store/load  
ordering.

Paul Khuong



From kalyanov.dmitry at gmail.com  Wed Sep  2 17:11:00 2009
From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry)
Date: Wed, 2 Sep 2009 21:11:00 +0400
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
	<4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
Message-ID: <200909022111.06768.Kalyanov.Dmitry@gmail.com>

On Wednesday 02 September 2009 07:41:15 Gustavo wrote:
>
> I believe it would also be possible to implement multiple threading that
> way (using FFI, if it support callbacks (as CFFI does)). But I'm not going
> further on this topic.

It is certainly not possible to implement multithreading with FFI. 
Multithreading requires substantial support from the runtime.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090902/158e85ac/attachment.sig>

From antoniotti.marco at disco.unimib.it  Fri Sep  4 12:58:36 2009
From: antoniotti.marco at disco.unimib.it (Marco Antoniotti)
Date: Fri, 4 Sep 2009 14:58:36 +0200
Subject: [cltl3-devel] Types
In-Reply-To: <a0d87c1c0909020512k5ed56fc2v3e0547321bf1cab4@mail.gmail.com>
References: <a0d87c1c0909020512k5ed56fc2v3e0547321bf1cab4@mail.gmail.com>
Message-ID: <A8A225A8-C855-487A-BEE0-16A7BA504BCC@disco.unimib.it>


On Sep 2, 2009, at 14:12 , Levente M?sz?ros wrote:

> Hi,
>
> Some issues about the type system that comes to my mind (some of them
> might be less important than the others):
> - no reliable way to figure out whether something is a type  
> specifier or not

Yep.  I use

(defun type-specifier-p (ts) (ignore-errors (subtypep ts t)))


> - no way to portably expand a type specifier by using its definition

Yep.

> - practically there is no reflection on types

Yep.


> - no easy way to specify a parametric type of strings with less than
> N characters (this is just an example of the issue: (deftype
> length-limited-string (limit) ...)
>   due to the limits of satisfies

Careful.  This opens up a can of worms.  There is no way to specify a  
recursive type either, but this would go really deep.

> - no portable way to get the inferred type of a function, a  
> variable, etc.

Environment access *could* mitigate this problem.

Cheers

Marco








>
> Cheers,
> levy
>
> -- 
> There's no perfectoin
>
> _______________________________________________
> cltl3-devel mailing list
> cltl3-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

--
Marco Antoniotti, Associate Professor				tel.	+39 - 02 64 48 79 01
DISCo, Universit? Milano Bicocca U14 2043
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.








From antoniotti.marco at disco.unimib.it  Fri Sep  4 13:00:05 2009
From: antoniotti.marco at disco.unimib.it (Marco Antoniotti)
Date: Fri, 4 Sep 2009 15:00:05 +0200
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <200909022111.06768.Kalyanov.Dmitry@gmail.com>
References: <bc10d2190908311257t2d158320me68275ec5f0e754d@mail.gmail.com>
	<bc10d2190909011828y5de84eb9t3391695a4291454d@mail.gmail.com>
	<4be8713d0909012041y194581a9vac40379235645005@mail.gmail.com>
	<200909022111.06768.Kalyanov.Dmitry@gmail.com>
Message-ID: <A4025025-84A4-4189-9596-7515DB493DE7@disco.unimib.it>


On Sep 2, 2009, at 19:11 , Kalyanov Dmitry wrote:

> On Wednesday 02 September 2009 07:41:15 Gustavo wrote:
>>
>> I believe it would also be possible to implement multiple threading  
>> that
>> way (using FFI, if it support callbacks (as CFFI does)). But I'm  
>> not going
>> further on this topic.
>
> It is certainly not possible to implement multithreading with FFI.
> Multithreading requires substantial support from the runtime.

Do you mean the underlying the OS?

Cheers

Marco

--
Marco Antoniotti, Associate Professor				tel.	+39 - 02 64 48 79 01
DISCo, Universit? Milano Bicocca U14 2043
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.








From john at fremlin.org  Sun Sep  6 07:35:56 2009
From: john at fremlin.org (John Fremlin)
Date: Sun, 06 Sep 2009 07:35:56 +0000
Subject: [cltl3-devel] RFC: CLtL3 Charter
Message-ID: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>


It's awesome that the standard is getting revisited.

In my view there are four main problem areas. I think it's most
important that the broken or lacking core language features be
addressed! Other languages have groups continually going over these
things; Common Lisp needs one too.

   (1) Missing or broken language features that should be added or fixed

Crummy type-system (at least parameterised types please)! 

As Levente also brought up: also access to type inference, etc. This
would allow:

Efficient generic functions dispatched to inline expansions at compile time.

Value semantics.

More help for code walkers and transformers (what does a declare form
refer to?, etc.)

Limited(?) serialisation of closures.

Ability to locally alias a symbol and package

   (2) Brokenness in the current Lisp standard

Different facilities should be separated and put into different packages.

Pathnames are overly complicated and do not handle symlinks well.

Extensible sequences, gray streams, etc.

Hash-tables should be generalised like extensible sequences allow user
implementation of other datastructures.

eq, eql, equal, equalp are not enough; nothing should restrict itself to
these comparisons.

Generally all functions like +, -, equal etc. should be overridable for
user's custom types with the efficient compile-time dispatched generic
function mechanism.

This would allow (explicit) laziness!

Possibly kill the many bizarrely named or strangely parameterised and
hardly used functions like `get'.

   (3) Stuff all implementations provide but is not standard

Unsafe machine pointers

Weak pointers

Details from room

GC

Stack frame inspection

etc.

   (4) Libraries that basically already exist but would be useful as
part of the standard
    
    cl-ppcre, local-time, osicat, cffi, etc.



From js at crispylogics.com  Sun Sep  6 12:38:23 2009
From: js at crispylogics.com (Jochen Schmidt)
Date: Sun, 6 Sep 2009 14:38:23 +0200
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
Message-ID: <F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>


Am 06.09.2009 um 09:35 schrieb John Fremlin:

>
> It's awesome that the standard is getting revisited.

CLtL3 will only be a specification, not a standard. This is a big  
difference. Between CLtL2 and ANSI CL are significant differences and  
creating a standard like ANSI CL was a complex and costly task. We  
hope that the result of CLtL3 will be a specification that gets  
accepted as solid progress for Common Lisp as a programming language -  
not Common Lisp as a standard. I think time will show if there will be  
benefits if the standard itself will get revised.

The fact that there exists an established standard (ANSI CL) will have  
a stake on what we can do with CLtL3. It doesn't make any sense to me,  
to break ANSI CL support; a future CLtL3 capable Common Lisp should  
also work with programs written for ANSI CL.

>
> In my view there are four main problem areas. I think it's most
> important that the broken or lacking core language features be
> addressed! Other languages have groups continually going over these
> things; Common Lisp needs one too.
>
>   (1) Missing or broken language features that should be added or  
> fixed
>
> Crummy type-system (at least parameterised types please)!

As others already outlined extending the type system could probably  
the most efficient way to drive CLtL3 against some wall. It's not  
impossible to implement your own type systems within Common Lisp  
without touching the CL type system at all. I think I remember reading  
Thomas Burdick talk about this on c.l.l before; maybe it was someone  
else. On the other side: I would be the last who would say NO! if  
someone can show how to extend the CL type system in a way that  
doesn't break ANSI CL code, is sound and (most important) is useful. I  
just think that this is maybe one of those parts we will not tackle  
with CLtL3.

>
> As Levente also brought up: also access to type inference, etc. This
> would allow:
>
> Efficient generic functions dispatched to inline expansions at  
> compile time.

Generic functions do not dispatch on types, but on classes (and on EQL  
values). There exists some classes which correspond to types like  
numbers, strings a.s.o. This means you can already do something like:

(class-direct-subclasses (find-class 'number))
=> (#<BUILT-IN-CLASS REAL 20945223> #<BUILT-IN-CLASS COMPLEX 20944833>)

The consequence is, that you cannot dispatch on all types expressible  
in CL. Allowing dispatch on arbitrary types is probably not easy and  
perhaps not very efficient. Though: Extensions to the dispatch system  
are a very interesting topic for CLtL3. AFAIK Pascal Costanza is  
working on some ideas to realize predicate dispatch within CLOS.

>
> Value semantics.

Value semantics? I would like to here some more about why you think  
this is needed for CL and how it should work.

>
> More help for code walkers and transformers (what does a declare form
> refer to?, etc.)

defining access to environments - I would like to see something like  
that too.

>
> Limited(?) serialisation of closures.

Would be somewhat cool. More important to me would be compiling and  
loading code from a stream.

>
> Ability to locally alias a symbol and package

Package-local aliases, nicknames for packages that are only valid  
within the package in which they are defined are quite possible.  
Perhaps ideas from Tim Bradshaws conduits package should be taken into  
account.

I fear locally aliasing a symbol is more difficult. You cannot mean  
creating a new symbol with the same name shadowing the first, because  
thats already how the package system works. So I think you actually  
mean accessing the _same_ symbol using a different name within a  
particular package. SYMBOL-NAME currently is a property of a symbol  
which is independent from the concept of a package. Following your  
idea SYMBOL-NAME would give different names depending on the value of  
*package* in the current dynamic extent. IMPORT is just defined on  
symbols and does not associate names with which the imported symbols  
are imported (because IMPORT gets them using the global symbol  
property SYMBOL-NAME); so one would need another function (e. g.  
called IMPORT-ALIASED) to associate a symbol with a particular name in  
the chosen package. A problem is though, that in ANSI CL there is this  
constraint were the symbol-name of a symbol is always the same -  
regardless of the current package - this could lead to problems with  
ANSI CL programms.

>
>   (2) Brokenness in the current Lisp standard
>
> Different facilities should be separated and put into different  
> packages.

More: New facilities defined in CLtL3 should be clearly modularised  
and - of course - get their own packages were applicable. You should  
recognize a CLtL3 using program easily by its usage of CLtL3 packages.  
There could be a common prefix like "CLTL3." for all those packages.  
Perhaps it would be interesting to expose existing ANSI CL symbols in  
different packages, but they will all have to be available in "CL".

>
> Pathnames are overly complicated and do not handle symlinks well.

Windows XP doesn't handle symlinks well ;-) - The situation in common  
lisp is somewhat similar to that of java 2-3 years ago. They solved it  
in JSR 203. CL Pathnames are actually better than their fame. Im not  
sure what the best idea would be - more clearly define how pathnames  
should behave or just orthogonally implement URIs and make all  
functions who accept pathname designators let accept uris too (URIs as  
pathname designators). Either one would restrict those to file-URIs or  
one could establish a protocol to implement support for other schemes.

>
> Extensible sequences, gray streams, etc.

Of course!

>
> Hash-tables should be generalised like extensible sequences allow user
> implementation of other datastructures.

yes

>
> eq, eql, equal, equalp are not enough; nothing should restrict  
> itself to
> these comparisons.

http://www.nhplace.com/kent/PS/EQUAL.html


>
> Generally all functions like +, -, equal etc. should be overridable  
> for
> user's custom types with the efficient compile-time dispatched generic
> function mechanism.

This is already possible to some extend using symbol shadowing. I  
would not want to allow "operator overloading" like in C++ (shudder)

>
> This would allow (explicit) laziness!
>
> Possibly kill the many bizarrely named or strangely parameterised and
> hardly used functions like `get'.

"Kill" gets to far - this would break ANSI CL compatibility. We could  
deprecate their use and don't import them in the CLtL3 package(s) - so  
one could use CL:GET if one wants to.

>
>   (3) Stuff all implementations provide but is not standard
>
> Unsafe machine pointers
>
> Weak pointers
>
> Details from room
>
> GC
>
> Stack frame inspection

Usefulness is king.

>
> etc.
>
>   (4) Libraries that basically already exist but would be useful as
> part of the standard
>
>    cl-ppcre, local-time, osicat, cffi, etc.

Thats actually not a good idea (as discussed on the list before).

ciao,
Jochen


-- 
Jochen Schmidt
CRISPYLOGICS
Uhlandstr. 9, 90408 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828  
16438) http://www.crispylogics.com




From john at fremlin.org  Sun Sep  6 14:20:29 2009
From: john at fremlin.org (John Fremlin)
Date: Sun, 06 Sep 2009 14:20:29 +0000
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com> (Jochen
	Schmidt's message of "Sun, 6 Sep 2009 14:38:23 +0200")
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
	<F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>
Message-ID: <87hbvg17f6.fsf-genuine-vii@john.fremlin.org>

Jochen Schmidt <js at crispylogics.com> writes:
[...]
> The fact that there exists an established standard (ANSI CL) will have
> a stake on what we can do with CLtL3. It doesn't make any sense to me,
> to break ANSI CL support; a future CLtL3 capable Common Lisp should
> also work with programs written for ANSI CL.

Possibly, but I hope you understand that the ANSI CL standard was not
perfect, is not implemented perfectly, and if a small change or
clarification is proposed then you agree that it should be judged on its
individual merits (as affecting existing programs or not, etc.) and not
summarily rejected.

[...]
> Generic functions do not dispatch on types, but on classes (and on EQL
> values).

Yes, I am painfully aware of this and find it very unfortunate that there
are three kinds of valid type in CL: types you can give to declare or
the, types you can give to typep, and classes.

[...]
> The consequence is, that you cannot dispatch on all types expressible
> in CL. Allowing dispatch on arbitrary types is probably not easy and
> perhaps not very efficient. Though: Extensions to the dispatch system
> are a very interesting topic for CLtL3. AFAIK Pascal Costanza is
> working on some ideas to realize predicate dispatch within CLOS.

To digress into this tangent, it might great if generic functions could
also dispatch on types. If it makes it inefficient for those cases which
use this functionality (e.g. satisfies), fair enough, but it would make
things less complicated to explain.


What I was talking about before was (1) a facility for macros to inspect
the declared or derived types in the lexical environment, (2) a new
auto-sealing generic function system built on this. Namely, if the type
is known and matches a defined method then that method may be inlined at
the compiler's discretion; if it is later redefined (defsealedmethod) or
a more specific method is defined then that may not affect compiled code
(in the same vein as inline functions at the moment).

[...]
> Value semantics? I would like to here some more about why you think
> this is needed for CL and how it should work.

It would be nice if it were possible to get decent code out of a CL
compiler for things like bytemap or manardb, where the ability to pass
around small structures instead of horribly packing things into integers
would be great. For another example, an array of structures rather than
an array of pointers to structures has hugely different performance.


[...]

> defining access to environments - I would like to see something like
> that too.

To be clear one of the messiest areas of the CL standard is the business
of declarations; for example, the distinction between bound or unbound
declarations. How can a code-walker/transformer decide what a
declaration refers to if the declaration is not standard?

[...]

> Would be somewhat cool. More important to me would be compiling and
> loading code from a stream.

You can load code from a stream in ANSI (but not Allegro, which assumes
its a fasl or not depending on the element-type of the stream -- another
messy bug they are afraid to touch).


[...]
> Package-local aliases, nicknames for packages that are only valid
> within the package in which they are defined are quite possible.
> Perhaps ideas from Tim Bradshaws conduits package should be taken into
> account.

Or Ron Garret's ideas.


[...]
> the chosen package. A problem is though, that in ANSI CL there is this
> constraint were the symbol-name of a symbol is always the same -  
> regardless of the current package - this could lead to problems with
> ANSI CL programms.

You could munge the reader to have a local alias table that it consults,
it wouldn't affect anything that didn't touch this table.


Having package versioning so multiple versions of the same package could
be simultaneously loaded would make some of the dependency nuisances go
away, and allow for somewhat smoother live updates.

[...]

>> eq, eql, equal, equalp are not enough; nothing should restrict
>> itself to
>> these comparisons.
>
> http://www.nhplace.com/kent/PS/EQUAL.html

What's that got to do with it? I was complaining about the limitations
of the standard make-hash-table :test. (Is there another place where the
set of test functions is restricted?)

[...]

> This is already possible to some extend using symbol shadowing. I
> would not want to allow "operator overloading" like in C++ (shudder)

Why not?

>> This would allow (explicit) laziness!
>>
>> Possibly kill the many bizarrely named or strangely parameterised and
>> hardly used functions like `get'.
>
> "Kill" gets to far - this would break ANSI CL compatibility. We could
> deprecate their use and don't import them in the CLtL3 package(s) - so
> one could use CL:GET if one wants to.

Yes.

[...]

>> Stack frame inspection
>
> Usefulness is king.

?

Backtraces are badly implemented by many projects and would be used by
more if they weren't so tricky.

[...]




From drewc at tech.coop  Sun Sep  6 17:24:26 2009
From: drewc at tech.coop (Drew Crampsie)
Date: Sun, 6 Sep 2009 10:24:26 -0700
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <87hbvg17f6.fsf-genuine-vii@john.fremlin.org>
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
	<F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>
	<87hbvg17f6.fsf-genuine-vii@john.fremlin.org>
Message-ID: <bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>

2009/9/6 John Fremlin <john at fremlin.org>:
> Jochen Schmidt <js at crispylogics.com> writes:
> [...]
>> The fact that there exists an established standard (ANSI CL) will have
>> a stake on what we can do with CLtL3. It doesn't make any sense to me,
>> to break ANSI CL support; a future CLtL3 capable Common Lisp should
>> also work with programs written for ANSI CL.
>
> Possibly, but I hope you understand that the ANSI CL standard was not
> perfect, is not implemented perfectly, and if a small change or
> clarification is proposed then you agree that it should be judged on its
> individual merits (as affecting existing programs or not, etc.) and not
> summarily rejected.

CLtL3 will make every effort to avoid breaking compatibility with
ANSI. While a non-compatible change may be worth looking at, it likely
will not be a part of this spec unless there is an extremely good
reason and little chance of breaking ANSI CL code.

> [...]
>> The consequence is, that you cannot dispatch on all types expressible
>> in CL. Allowing dispatch on arbitrary types is probably not easy and
>> perhaps not very efficient. Though: Extensions to the dispatch system
>> are a very interesting topic for CLtL3. AFAIK Pascal Costanza is
>> working on some ideas to realize predicate dispatch within CLOS.
>
> To digress into this tangent, it might great if generic functions could
> also dispatch on types. If it makes it inefficient for those cases which
> use this functionality (e.g. satisfies), fair enough, but it would make
> things less complicated to explain

It would make things significantly more complex to implement (read:
impossible in many cases to determine the effective method), and with
little gain.. one can easily hack something up with typecase and a
hash table if one wants to dispatch on CL types.

How would it make things less complicated to explain? AMOP is fairly
simple (or it at leasts builds on simple concepts).. adding types to
the GF dispatch would complicate things significantly.

The goals of CLtL3 are not to make CL 'simpler', 'more understandable'
or 'easy for newbies'.

>
> What I was talking about before was (1) a facility for macros to inspect
> the declared or derived types in the lexical environment,

Something like this may make it as part of the environments module.
But, we won't _require_ any compile-time type inference.

> auto-sealing generic function system built on this. Namely, if the type
> is known and matches a defined method then that method may be inlined at
> the compiler's discretion; if it is later redefined (defsealedmethod) or
> a more specific method is defined then that may not affect compiled code
> (in the same vein as inline functions at the moment).


Something like this is _way_ out of scope. I'd like to offer the tools
to enable someone to build it portably, but it's not going into the
description.


>
> [...]
>> Value semantics? I would like to here some more about why you think
>> this is needed for CL and how it should work.
>
> It would be nice if it were possible to get decent code out of a CL
> compiler for things like bytemap or manardb, where the ability to pass
> around small structures instead of horribly packing things into integers
> would be great. For another example, an array of structures rather than
> an array of pointers to structures has hugely different performance.

Out of scope as well.

>
>
> [...]
>
>> defining access to environments - I would like to see something like
>> that too.
>
> To be clear one of the messiest areas of the CL standard is the business
> of declarations; for example, the distinction between bound or unbound
> declarations. How can a code-walker/transformer decide what a
> declaration refers to if the declaration is not standard?

Environments are worth looking into, yes.

>
> [...]
>> Package-local aliases, nicknames for packages that are only valid
>> within the package in which they are defined are quite possible.
>> Perhaps ideas from Tim Bradshaws conduits package should be taken into
>> account.
>
> Or Ron Garret's ideas.

Conduits, and hierarchal packages, are something we'll have to look at
further, I can see uses within CLtL3 itself.

> Having package versioning so multiple versions of the same package could
> be simultaneously loaded would make some of the dependency nuisances go
> away, and allow for somewhat smoother live updates.

I'd need to see some code for this, it's a neat idea, but the
implementation is likely hairy. Can you point to an existing
implementation?

>
> [...]
>
>>> eq, eql, equal, equalp are not enough; nothing should restrict
>>> itself to
>>> these comparisons.
>>
>> http://www.nhplace.com/kent/PS/EQUAL.html
>
> What's that got to do with it? I was complaining about the limitations
> of the standard make-hash-table :test. (Is there another place where the
> set of test functions is restricted?)

Extensible hash tables are covered by a CDR, and so are on the list of
things we will consider.


>
> [...]
>
>> This is already possible to some extend using symbol shadowing. I
>> would not want to allow "operator overloading" like in C++ (shudder)
>
> Why not?

Because it's crap, and we have SHADOW.

>>> Possibly kill the many bizarrely named or strangely parameterised and
>>> hardly used functions like `get'.

Not going to happen.. ever. I used GET just yesterday, and we will not
be 'killing' anything.
If you don't like it, don't use it, but removing functionality and CL
compatibility is not worth it, and not a goal of CLtL3.

>>
>> "Kill" gets to far - this would break ANSI CL compatibility. We could
>> deprecate their use and don't import them in the CLtL3 package(s) - so
>> one could use CL:GET if one wants to. ,

We will also _not_ be deprecating things from CL because they are
bizarrely name or parameterized . If anything i'd like to un-deprecate
a few things ANSI sent down (*-if-not, i',m looking at you).

>
> Yes.
>
> [...]
>
>>> Stack frame inspection
>>
>> Usefulness is king.
>
> ?
>
> Backtraces are badly implemented by many projects and would be used by
> more if they weren't so tricky.

Trivial-backtrace exists, so there is some need for this. It's covered
under 'Editing and Introspection' in the charter.

Cheers,

drewc
>
> [...]
>
>
> _______________________________________________
> cltl3-devel mailing list
> cltl3-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
>



From gugamilare at gmail.com  Sun Sep  6 18:26:44 2009
From: gugamilare at gmail.com (Gustavo)
Date: Sun, 6 Sep 2009 15:26:44 -0300
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
	<F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>
	<87hbvg17f6.fsf-genuine-vii@john.fremlin.org>
	<bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>
Message-ID: <4be8713d0909061126i40945066s11358886cddf6659@mail.gmail.com>

I have a suggestion concerning what Cltl3 will not do (specially after the
recent discussions with John Fremlin). Nothing personal, John Fremlin, but
we must do things in a very conservative way, and this was already discussed
in this topic. This or something similar should be added to the charter:

"The group don't intend to include things incompatibly with the ANSI
specification, nor to include features that can be easily included with
tools provided by ANSI CL like symbol shadowing, packages and read tables,
or with the other features included in this description. Making CL more
readable or understandable is not one of Cltl3's goals. It will not change
function or macro names nor create new names or aliases for them in some
other package, even if the new names are more descriptive or acceptable.

This description is intended to be as easy to implement as possible and
features difficult to implement are only going to be adopted if they are
strictly necessary to achieve other Cltl3's goals. In particular,  This
description will not enforce implementations to do anything at all. The
group, however, expects this new description to provide features and and
advantages over the current ANSI specification so that implementations
choose to adopt it."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090906/05b9b306/attachment.html>

From eadmund42 at gmail.com  Sun Sep  6 18:48:35 2009
From: eadmund42 at gmail.com (Robert Uhl)
Date: Sun, 06 Sep 2009 12:48:35 -0600
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <4be8713d0909061126i40945066s11358886cddf6659@mail.gmail.com>
	(Gustavo's message of "Sun, 6 Sep 2009 15:26:44 -0300")
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
	<F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>
	<87hbvg17f6.fsf-genuine-vii@john.fremlin.org>
	<bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>
	<4be8713d0909061126i40945066s11358886cddf6659@mail.gmail.com>
Message-ID: <m3vdjvlxj0.fsf@latakia.octopodial-chrome.com>

Gustavo <gugamilare at gmail.com> writes:
>
> It will not change function or macro names nor create new names or
> aliases for them in some other package, even if the new names are more
> descriptive or acceptable.

That seems unnecessarily restrictive.  What's wrong with a COMMON-LISP-3
package which has more orthogonal names?  Heck, it could even take
advantage of some theoretical versioned-package functionality.

-- 
Robert A. Uhl
I take great delight at jeering at overly healthy types and telling 
them that they're going to feel really stupid one day, lying in a 
bed dying of nothing.                                        --GB



From gugamilare at gmail.com  Sun Sep  6 21:15:32 2009
From: gugamilare at gmail.com (Gustavo)
Date: Sun, 6 Sep 2009 18:15:32 -0300
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <m3vdjvlxj0.fsf@latakia.octopodial-chrome.com>
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>
	<F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>
	<87hbvg17f6.fsf-genuine-vii@john.fremlin.org>
	<bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>
	<4be8713d0909061126i40945066s11358886cddf6659@mail.gmail.com>
	<m3vdjvlxj0.fsf@latakia.octopodial-chrome.com>
Message-ID: <4be8713d0909061415s6c1a199ei1b1d3ed60ad3054a@mail.gmail.com>

2009/9/6 Robert Uhl <eadmund42 at gmail.com>

> Gustavo <gugamilare at gmail.com> writes:
> >
> > It will not change function or macro names nor create new names or
> > aliases for them in some other package, even if the new names are more
> > descriptive or acceptable.
>
> That seems unnecessarily restrictive.  What's wrong with a COMMON-LISP-3
> package which has more orthogonal names?  Heck, it could even take
> advantage of some theoretical versioned-package functionality.
>

I based this sentence on what Drew Crampsie said:

"We will also _not_ be deprecating things from CL because they are
bizarrely name or parameterized."

Just renaming functions or creating a new package with more "orthogonal
names" (whatever that means) does not include any new feature nor
functionality in the language and it is something you can do yourself. It
falls into what was already said: that it is not one of Cltl3's goal to make
CL more readable or easier for newbies or whatever. It also depends too much
on personal taste. Having one function with different names makes more
confusion than clarification.

Such a thing pollutes the packages with names you are not going to use. For
instance, I might not like some naming conventions in COMMON-LISP-3 or I
might have some code that already uses CL's standard names, so I decide to
import from both packages COMMON-LISP-3 and COMMON-LISP. Then I will have to
manually shadow all symbols that I don't want to use, or I will be obligated
not to use those names in my package.

Not to mention that doing this will make it look like that we are trying to
force people to program in a different language, learn new names or new
parameter orders. This is very different from including extensions - you may
safely and easily just ignore such extensions. Maybe in the course of
discussion we end up creating functions that are generalizations of other
functions already in ANSI CL, then it will be ok to deprecate those
functions, but this is very different from just creating aliases.

And, as a mater of fact, I can't imagine how to implement versioned packages
in a way that its cost is below its benefits. I can only imaging that
something in this direction will need big changes in implementations for
only providing a small benefit, or to occupy more space (many versions of
the same functions). I will be glad if someone proves me wrong. Conduit
packages look much more useful than versioned packages.


> --
> Robert A. Uhl
> I take great delight at jeering at overly healthy types and telling
> them that they're going to feel really stupid one day, lying in a
> bed dying of nothing.                                        --GB
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090906/980e64a5/attachment.html>

From dherring at tentpost.com  Mon Sep  7 04:44:42 2009
From: dherring at tentpost.com (Daniel Herring)
Date: Mon, 7 Sep 2009 00:44:42 -0400 (EDT)
Subject: [cltl3-devel] wishlist items
Message-ID: <alpine.LNX.1.10.0909062339210.2494@strider2.example.org>

Here are a few items on my post-ANSI wishlist.  Please forgive me if I'm 
not following proper CLtL3 wishlist protocol.


* Get REQUIRE right.  IIRC, CLtL2 had *MODULE-PROVIDER-HOOKS*.  This is 
good.  There should be a standard way for defsystems to coexist.

* If versioning semantics are added to REQUIRE, I suggest something like
   - (require system &optional version), NIL matches any version
   - require signals an error if the requested version doesn't match a
     currently loaded version
   - versions have three numbers (a la libtool)
     - "major" number represents external API changes (e.g. new functions)
     - "minor" number represents internal changes (e.g. bugfixes)
     - "range" counts minor numbers that are binary compatible
   - Example: 5.7.2
     - API 5, release 7, backwared compatible with 5.6.x and 5.5.x
     - projects compiled against 1.x.y-4.x.y will need to be recompiled and
       may also need code changes
     - projects compiled against 5.0.x-5.4.x will require a recompile but
       no code changes

* Standardize read macros that dispatch on a symbol.  The current
   read-macro namespace is too crowded.  Here are a couple syntax variants.
   The first lets the dispach function read everything; it takes the
   current standard read-macro arguments.  The second uses a normal read
   to get the default arguments; it takes the read-macro arguments as
   special variables.
   - #?(read-if (= 1 2) :true :false)
     dispatch to #'read-if which reads "(= 1 2)", skips :true, and
     reads :false
   - #!(read-if nil)(:true :false)
     dispatch to (read-if nil), which skips :true and reads :false

* Allow packages to specify whether they want case folding.  The ANSI CL
   reader folds case first, then looks for a match.  I'm aware of a few
   skunkworks projects which try to reverse that order.  Thus CL::REQUIRE
   will always fold case, but symbols in package PR could have their case
   preserved.

* Provide a standard code walker.

* Define a standard mapping between pathnames and files on the major OSs.

* Split CL into smaller packages like CL.ALIST, CL.PLIST, etc.  Use
   symbol macros for symbols in CL.

* Provide a standard way for macros to query type-inferencing info,
   declarations, etc.

* Introduce a range api, and use it as a standard way to hook any
   datastructure into MAP*, NTH, etc.  Something like Clojure or D.
   http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html

* Define CL's memory model in a multithreaded environment, a la JSR133.
   http://jcp.org/en/jsr/detail?id=133

Later,
Daniel



From john at fremlin.org  Mon Sep  7 05:31:31 2009
From: john at fremlin.org (John Fremlin)
Date: Mon, 07 Sep 2009 14:31:31 +0900
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>
References: <87iqfwbk4j.fsf-genuine-vii@john.fremlin.org>	
	<F6FE638B-3023-429B-9337-96FF96E688E9@crispylogics.com>	
	<87hbvg17f6.fsf-genuine-vii@john.fremlin.org>
	<bc10d2190909061024g45b961dblf0865ca01c0c7bdb@mail.gmail.com>
Message-ID: <4AA49AB3.7020601@fremlin.org>

Drew Crampsie wrote:
>> What I was talking about before was (1) a facility for macros to inspect
>> the declared or derived types in the lexical environment,
> 
> Something like this may make it as part of the environments module.
> But, we won't _require_ any compile-time type inference.

Fair enough.

>> auto-sealing generic function system built on this. Namely, if the type
>> is known and matches a defined method then that method may be inlined at
>> the compiler's discretion; if it is later redefined (defsealedmethod) or
>> a more specific method is defined then that may not affect compiled code
>> (in the same vein as inline functions at the moment).
> 
> 
> Something like this is _way_ out of scope. I'd like to offer the tools
> to enable someone to build it portably, but it's not going into the
> description.

Well, if the tools were there that would be an important start. I think 
that at least supporting this sort of extension should be considered.

> I'd need to see some code for this, it's a neat idea, but the
> implementation is likely hairy. Can you point to an existing
> implementation?

No :-)

>>> This is already possible to some extend using symbol shadowing. I
>>> would not want to allow "operator overloading" like in C++ (shudder)
>> Why not?
> 
> Because it's crap, and we have SHADOW.

Well, that's not an argument; I like it. I think it's great. How does 
this essentially differ from the generalized sequences proposal? If you 
called it generalized numbers would you be happier?

>>>> Possibly kill the many bizarrely named or strangely parameterised and
>>>> hardly used functions like `get'.
> 
> Not going to happen.. ever. I used GET just yesterday, and we will not
> be 'killing' anything.
> If you don't like it, don't use it, but removing functionality and CL
> compatibility is not worth it, and not a goal of CLtL3.
> 
>>> "Kill" gets to far - this would break ANSI CL compatibility. We could
>>> deprecate their use and don't import them in the CLtL3 package(s) - so
>>> one could use CL:GET if one wants to. ,
> 
> We will also _not_ be deprecating things from CL because they are
> bizarrely name or parameterized . If anything i'd like to un-deprecate
> a few things ANSI sent down (*-if-not, i',m looking at you).

I meant that using the CLTL3 package should not mean that the more 
unfortunate functions from CL be automatically imported. You cannot bind 
(flet ((get (...))) for example, and while I have indeed used get 
(unfortunately, more than a week ago so not on a par with your mastery 
of it), I think it is unfortunate that a specific functionality managed 
to grab a generic three letter name.

I guess we will have to wait for Attila Lendvai to complete his redesign 
of the Lisp namespace and CLTL3 will be for other things ;-)

>> Backtraces are badly implemented by many projects and would be used by
>> more if they weren't so tricky.
> 
> Trivial-backtrace exists, so there is some need for this. It's covered
> under 'Editing and Introspection' in the charter.

Trivial backtrace and the portable backtrace functionality in it is just 
a start. Backtraces are (badly) implemented in many server projects.

I didn't understand that you'd gone so far to fixing on your charter. 
Sorry for butting in; have fun!




From antoniotti.marco at disco.unimib.it  Mon Sep  7 09:25:46 2009
From: antoniotti.marco at disco.unimib.it (Marco Antoniotti)
Date: Mon, 7 Sep 2009 11:25:46 +0200
Subject: [cltl3-devel] Pathnames
Message-ID: <A81431BA-72E6-4D39-98B0-769448BFAF54@disco.unimib.it>

... just to start a bit of a flame war :), I submit here that a good  
start to solve the pathname issue is my very own NAMES-AND-PATHS effort.

http://common-lisp.net/project/names-and-paths/

I also have code that implements a lot of the syntax.

Comments and developers welcome.

... and no: symlinks (a UNIX concept and one of the problems that  
newbies find with ASDF) are explicitely not handled.

Cheers


--
Marco Antoniotti





From eadmund42 at gmail.com  Mon Sep  7 16:35:39 2009
From: eadmund42 at gmail.com (Robert Uhl)
Date: Mon, 07 Sep 2009 10:35:39 -0600
Subject: [cltl3-devel] wishlist items
In-Reply-To: <alpine.LNX.1.10.0909062339210.2494@strider2.example.org> (Daniel
	Herring's message of "Mon, 7 Sep 2009 00:44:42 -0400 (EDT)")
References: <alpine.LNX.1.10.0909062339210.2494@strider2.example.org>
Message-ID: <m3iqfulnl0.fsf@latakia.octopodial-chrome.com>

Daniel Herring <dherring at tentpost.com> writes:
>
> * Allow packages to specify whether they want case folding.  The ANSI CL
>    reader folds case first, then looks for a match.  I'm aware of a few
>    skunkworks projects which try to reverse that order.  Thus CL::REQUIRE
>    will always fold case, but symbols in package PR could have their case
>    preserved.

I think that setting *PRINT-CASE* to :DOWNCASE goes a long way to
soothing the headaches of a language which defaults to
upcasing...internally everything is upcased but it displays
attractively.

Once that's done a lot of the impetus for playing with case-folding goes
away.  The only nuisance is in using strings to refer to symbols, where
one must actually use "FOO" instead of "foo."

> * Define a standard mapping between pathnames and files on the major OSs.

That's a big and important one indeed.

> * Split CL into smaller packages like CL.ALIST, CL.PLIST, etc.  Use
>    symbol macros for symbols in CL.

What's your rationale there?  Seems like it'd eat up resources without
any real benefit.  But I imagine I'm missing something important:-)

> * Provide a standard way for macros to query type-inferencing info,
>    declarations, etc.

That would be Very Nice Indeed.

> * Introduce a range api, and use it as a standard way to hook any
>    datastructure into MAP*, NTH, etc.  Something like Clojure or D.
>    http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html

Is this the same as generalised sequences?

-- 
...at the end of the conversation, the guy said `Thanks a lot for
reporting this.  If you need more details on our anti-spam policies,
just hit 'refresh' on the URL you reported.'
              --Willondon Donovan in nanae



From cowan at ccil.org  Mon Sep  7 19:02:55 2009
From: cowan at ccil.org (John Cowan)
Date: Mon, 7 Sep 2009 15:02:55 -0400
Subject: [cltl3-devel] wishlist items
In-Reply-To: <m3iqfulnl0.fsf@latakia.octopodial-chrome.com>
References: <alpine.LNX.1.10.0909062339210.2494@strider2.example.org>
	<m3iqfulnl0.fsf@latakia.octopodial-chrome.com>
Message-ID: <20090907190255.GB27523@mercury.ccil.org>

Robert Uhl scripsit:

> I think that setting *PRINT-CASE* to :DOWNCASE goes a long way to
> soothing the headaches of a language which defaults to
> upcasing...internally everything is upcased but it displays
> attractively.

However, downcasing plays better with Unicode than upcasing does, because
there are many Unicode lower-case letters without upper-case equivalents,
whereas there are no upper-case letters without lower-case equivalents.
The Unicode stability policies guarantee that:

	a string properly downcased in the current version of Unicode
	will remain so in all later versions;

	if two characters form (or do not form) an upper/lowercase pair
	in the current version, they will form (or not form) one in all
	later versions.

--
John Cowan                                   cowan at ccil.org
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know



From dherring at tentpost.com  Tue Sep  8 00:44:12 2009
From: dherring at tentpost.com (Daniel Herring)
Date: Mon, 7 Sep 2009 20:44:12 -0400 (EDT)
Subject: [cltl3-devel] wishlist items
In-Reply-To: <m3iqfulnl0.fsf@latakia.octopodial-chrome.com>
References: <alpine.LNX.1.10.0909062339210.2494@strider2.example.org>
	<m3iqfulnl0.fsf@latakia.octopodial-chrome.com>
Message-ID: <alpine.LNX.1.10.0909071952390.2494@strider2.example.org>

On Mon, 7 Sep 2009, Robert Uhl wrote:

> Daniel Herring <dherring at tentpost.com> writes:
>>
>> * Allow packages to specify whether they want case folding.  The ANSI CL
>>    reader folds case first, then looks for a match.  I'm aware of a few
>>    skunkworks projects which try to reverse that order.  Thus CL::REQUIRE
>>    will always fold case, but symbols in package PR could have their case
>>    preserved.
>
> I think that setting *PRINT-CASE* to :DOWNCASE goes a long way to
> soothing the headaches of a language which defaults to
> upcasing...internally everything is upcased but it displays
> attractively.
>
> Once that's done a lot of the impetus for playing with case-folding goes
> away.  The only nuisance is in using strings to refer to symbols, where
> one must actually use "FOO" instead of "foo."

I disagree.  "He lost his mit at MIT."  "For all x in X..."  For many 
applications, case folding is fine.  For others, it is almost completely 
unworkable.  There should be a way for different conventions to peacefully 
coexist.  Test implementations indicate it is completely doable, the 
biggest question is one of acceptance by the existing CL community.


>> * Split CL into smaller packages like CL.ALIST, CL.PLIST, etc.  Use
>>    symbol macros for symbols in CL.
>
> What's your rationale there?  Seems like it'd eat up resources without
> any real benefit.  But I imagine I'm missing something important:-)

So a package can (:use CL.ALIST) to only get CL's symbols for manipulating 
alists, etc.  These packages would also provide convenient namespaces for 
renamed symbols like copy-alist -> alist:copy or pairlis -> 
alist:add-pairs.  But such renames may be outside the CLtL3 charter. 
Another possibile package would be CL.GENERIC for things like a + generic 
function.


>> * Introduce a range api, and use it as a standard way to hook any
>>    datastructure into MAP*, NTH, etc.  Something like Clojure or D.
>>    http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html
>
> Is this the same as generalised sequences?

Yes modulo the details; they are closely related ideas.

- Daniel



From antoniotti.marco at disco.unimib.it  Tue Sep  8 15:27:55 2009
From: antoniotti.marco at disco.unimib.it (Marco Antoniotti)
Date: Tue, 8 Sep 2009 17:27:55 +0200
Subject: [cltl3-devel] Case wars.  Re:  wishlist items
In-Reply-To: <alpine.LNX.1.10.0909071952390.2494@strider2.example.org>
References: <alpine.LNX.1.10.0909062339210.2494@strider2.example.org>
	<m3iqfulnl0.fsf@latakia.octopodial-chrome.com>
	<alpine.LNX.1.10.0909071952390.2494@strider2.example.org>
Message-ID: <F2B743FF-3E15-4E2E-BD21-482E0AB79168@disco.unimib.it>

Coming up with a backward compatible case folding behavior is not that  
easy.  This is an excerpt of my half-baked proposal for case folding  
during the discussions that ensued on CLL after Franz introduced  
"Modern" mode, thus breaking backward compatibility.

Of course, one wonders what they were smoking in the Boston area when  
the California guys (who, it is understood, were at least dining with  
Sonoma Valley wine) proposed straightforward case-sensitivity for ANSI  
CL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: case-war.zip
Type: application/zip
Size: 7037 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090908/0aa0510f/attachment.zip>
-------------- next part --------------



Cheers
--
Marco



On Sep 8, 2009, at 02:44 , Daniel Herring wrote:

> On Mon, 7 Sep 2009, Robert Uhl wrote:
>
>> Daniel Herring <dherring at tentpost.com> writes:
>>>
>>> * Allow packages to specify whether they want case folding.  The  
>>> ANSI CL
>>>   reader folds case first, then looks for a match.  I'm aware of a  
>>> few
>>>   skunkworks projects which try to reverse that order.  Thus  
>>> CL::REQUIRE
>>>   will always fold case, but symbols in package PR could have  
>>> their case
>>>   preserved.
>>
>> I think that setting *PRINT-CASE* to :DOWNCASE goes a long way to
>> soothing the headaches of a language which defaults to
>> upcasing...internally everything is upcased but it displays
>> attractively.
>>
>> Once that's done a lot of the impetus for playing with case-folding  
>> goes
>> away.  The only nuisance is in using strings to refer to symbols,  
>> where
>> one must actually use "FOO" instead of "foo."
>
> I disagree.  "He lost his mit at MIT."  "For all x in X..."  For many
> applications, case folding is fine.  For others, it is almost  
> completely
> unworkable.  There should be a way for different conventions to  
> peacefully
> coexist.  Test implementations indicate it is completely doable, the
> biggest question is one of acceptance by the existing CL community.
>
>
>>> * Split CL into smaller packages like CL.ALIST, CL.PLIST, etc.  Use
>>>   symbol macros for symbols in CL.
>>
>> What's your rationale there?  Seems like it'd eat up resources  
>> without
>> any real benefit.  But I imagine I'm missing something important:-)
>
> So a package can (:use CL.ALIST) to only get CL's symbols for  
> manipulating
> alists, etc.  These packages would also provide convenient  
> namespaces for
> renamed symbols like copy-alist -> alist:copy or pairlis ->
> alist:add-pairs.  But such renames may be outside the CLtL3 charter.
> Another possibile package would be CL.GENERIC for things like a +  
> generic
> function.
>
>
>>> * Introduce a range api, and use it as a standard way to hook any
>>>   datastructure into MAP*, NTH, etc.  Something like Clojure or D.
>>>   http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html
>>
>> Is this the same as generalised sequences?
>
> Yes modulo the details; they are closely related ideas.
>
> - Daniel
>
> _______________________________________________
> cltl3-devel mailing list
> cltl3-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

--
Marco Antoniotti, Associate Professor				tel.	+39 - 02 64 48 79 01
DISCo, Universit? Milano Bicocca U14 2043
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.






From sthalik at test123.ltd.pl  Mon Sep 14 17:52:14 2009
From: sthalik at test123.ltd.pl (Stanislaw Halik)
Date: Mon, 14 Sep 2009 19:52:14 +0200
Subject: [cltl3-devel] RFC: CLtL3 Charter
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
Message-ID: <87my4x8ldd.fsf@test123.ltd.pl>

drew.crampsie at gmail.com writes:

> ANSI included FORMAT and LOOP, and similar arguments could have been
> (and were) made against them.

ANSI CL included lots of useless cruft because little children that
formed the commission threatened to pull out if crufts from their
implementation weren't supported. It wasn't enough for them if there was
a compatibility package (for instance ?cl-maclisp?), they wanted to have
all that in the ?cl? package.

I don't think there's much reason to standardize regexes, sockets and
the like. If something's implemented as a library, setting it in stone
with a specification actually makes matters worse. It only appeases
jerks blaming CL for ?not having sockets? because there's no standard
library for IO. If CLtL3 implements sockets, they'll find a new thing to
blame CL for.

-- 
polscy Lispnicy, ??czmy si? -- #lisp-pl na freenode
Lisp stuff: <http://tehran.lain.pl>




From cowan at ccil.org  Mon Sep 14 18:42:50 2009
From: cowan at ccil.org (John Cowan)
Date: Mon, 14 Sep 2009 14:42:50 -0400
Subject: [cltl3-devel] RFC: CLtL3 Charter
In-Reply-To: <87my4x8ldd.fsf@test123.ltd.pl>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
	<87my4x8ldd.fsf@test123.ltd.pl>
Message-ID: <20090914184250.GG31137@mercury.ccil.org>

Stanislaw Halik scripsit:

> ANSI CL included lots of useless cruft because little children that
> formed the commission threatened to pull out if crufts from their
> implementation weren't supported. 

More seriously, the whole point of standardization was code mobility,
and without all that stuff, major applications would have to have been
rewritten.  Code was much more important (as in C standardization)
than implementations were.

-- 
John Cowan  cowan at ccil.org  http://ccil.org/~cowan
If I have seen farther than others, it is because I am surrounded by dwarves.
        --Murray Gell-Mann



From fade at deepsky.com  Mon Sep 28 22:01:06 2009
From: fade at deepsky.com (Brian O'Reilly)
Date: Mon, 28 Sep 2009 15:01:06 -0700
Subject: [cltl3-devel] Fwd:  RFC: CLtL3 Charter
In-Reply-To: <bc10d2190909011840s4213fas5ff88194b45cbb8c@mail.gmail.com>
References: <bc10d2190909011243n27b9b67bla4da15f88d3fbb39@mail.gmail.com>
	<0016e648fca6bc77dc04728a295a@google.com>
	<4be8713d0909011753k412c1990r543925766852fcb3@mail.gmail.com>
	<bc10d2190909011837x5b346643m523d68e20552f7c2@mail.gmail.com>
	<bc10d2190909011840s4213fas5ff88194b45cbb8c@mail.gmail.com>
Message-ID: <5A044338-0A8F-44A2-981E-65037D4B688A@deepsky.com>


On 1-Sep-09, at 6:40 PM, Drew Crampsie wrote:

> did it again .. somebody smack me upside the head!
>
>
> ---------- Forwarded message ----------
> From: Drew Crampsie <drew.crampsie at gmail.com>
> Date: 2009/9/1
> Subject: Re: [cltl3-devel] RFC: CLtL3 Charter
> To: Gustavo <gugamilare at gmail.com>
>
>
> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>>
>>
>> 2009/9/1 <drew.crampsie at gmail.com>
>>>
>>> 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..
>>
>> cl-ppcre allow the use of sexps as regexps. I think that they are  
>> "verbose"
>> and "understandable".
>
> So it might ... but as per section 4 "Preference will be given to
> topics that cannot be implemented portably and have multiple existing
> implementations.".

Well, as far as these kinds of lisp<->os interactions go, splitting  
things up into packages or modules has worked out pretty well for  
python and (I think) ruby. It seems natural not to clutter the cl-user  
namespace with a lot of symbols that aren't needed universally, and it  
is just as easy to (require 'cl-net) || (require 'cl-os) || (require  
'cl-sys), for networking, system interfaces, and path operations  
respectively, especially if their presence in a 'standard' library was  
pretty much guaranteed. There's also the fact that making updates to  
these subsystems within the context of a library is much easier than  
updating the core system, particularly if cltl3 ends up with a large  
deployment base of legacy applications.


Kind Regards.,

Brian O'Reilly