Hello,
I have a few questions about some issues:
Are user extensible streams ala: http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdfgoin... to be catered for in cltl3?
There is no functional converse to SORT & STABLE-SORT. All the other operations that I can think of have functional / destructive operations, why the non uniformity?
Are Generators & Series being thought of? :)
Thats all for now, Edward Tate
Am 22.12.2009 um 14:08 schrieb Edward Tate:
Hello,
I have a few questions about some issues:
Are user extensible streams ala: http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf going to be catered for in cltl3?
Short: yes See the thread about "RFC: CLtL3 Charter" in august/september '09. Drew Crampsie has posted a CLtL3-Charter and started a discussion about it. I've put a copy on here:
http://pmeta.net/projects/cltl3/charter/cltl3-charter-draft-2.txt
There is no functional converse to SORT & STABLE-SORT. All the other operations that I can think of have functional / destructive operations, why the non uniformity?
Actually I don't know why - but it is important to understand that SORT is "potentially destructive". You cannot rely on an old reference of the sorted sequence. So SORT being destructive is specified to _allow_ efficient implementation of sorting sequences - not to enable users to safe some characters by "in-place-modification". Not that you meant that :-) just because it is a quite common error not to use the return value of SORT "because it is destructive".
Regarding CLtL3: To me this never was a real problem since COPY-SEQ isn't actually very difficult to add and I think of it more as a library issue (its easy to add portably using some utility-library). I personally would have nothing against adding a "non-destructive SORT"; though I fear the name debate would come up again with people demanding SORT to be called NSORT or even SORT! ;-) . Naming issues are explicitely NOT part of the CLtL3-Charter.
Are Generators & Series being thought of? :)
Similar to the non-destructive SORT: Those facilities should be easy to do using libraries in a portable way and only an ASDF:OOS away. It would only make the mudball bigger without making anything easier. So yes - Generators and Series make a cool (library-)extension to CL but they need not necessarily be a part of CLtL3. I understand the idea behind it and the symbolic/political value though. There already was the idea to make a CLtL3-Core without any library-add-ons and some CLtL3-Extensions which would be documented extensions. This could be an alternative.
ciao, Jochen Schmidt
Edward Tate wrote
Are user extensible streams ala: http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdfgoin... to be catered for in cltl3?
(ITYM "extensible sequences", not "extensible streams".)
People who want extensible sequences should implement them for their favorite Open Source implementation, or ask their commercial vendor to do it. (Even if they, the commercial vendors, may not consider it now, expressing your need is important so they will consider it some day.)
The implementation-dependent bits that are needed are not difficult -- and you can borrow the bulk of the implementation (the generic protocol, plus the generic implementation of the sequence functions specified in the standard) just from Christophe Rhodes' code.
The code was placed in the public domain so can also be reused by the commercial vendors without problem.
I'm pretty sure a dedicated hacker will probably be able to do it in the days between the years.
So if you have some free time at hand, and do not know what to do, try it. Fame and glory awaits. :-)
-T.
PS.
The alternative, portable route is described here
http://common-lisp.net/~trittweiler/talks/sequence-iterators-2009.pdf
If you want to help out on that instead, drop me a mail.
-
Edward Tate -
Jochen Schmidt -
Tobias C. Rittweiler