gmane.lisp.cltl3.devel

Re: Some questions

Tobias C. Rittweiler — 2009-12-22T17:45:11

Edward Tate wrote


(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/~t

Re: Some questions

Jochen Schmidt — 2009-12-22T14:56:25

Am 22.12.2009 um 14:08 schrieb Edward Tate:


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


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

Some questions

Edward Tate — 2009-12-22T13:08:22

_______________________________________________
cltl3-devel mailing list
cltl3-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

Re: Bug tracker at Launchpad

Tobias C. Rittweiler — 2009-12-21T19:20:43


Does not seem possible at the moment:

  https://bugs.launchpad.net/launchpad-registry/+bug/208238

I'd like you (and everyone else!) to press on the "This bug also affects
me" link right below the title.

Hopefully a big number will make things change quicker.

  -T.

Re: Bug tracker at Launchpad

Luis Oliveira — 2009-12-21T14:58:12

"Tobias C. Rittweiler" <tcr< at >freebits.de>
writes:


Is it possible to read the bug activity through gmane?

Bug tracker at Launchpad

Tobias C. Rittweiler — 2009-12-12T14:44:16

I just registered

  https://bugs.launchpad.net/cltl3

From my experience, Launchpad's bug tracker is quite nice to work
with. And it offers more persistence and organization than a mailing
list. Hence I thought it'd be a good idea for cltl3 to make use of one.

(I hope I didn't step on anyone's foot by taking initiative and just
registering one before asking.)

If people have time, it'd be a good idea to convert Cliki's Proposed
ANSI Revisions etc. over to the bug tracker.

  -T.

PS.

The bug tracker is /not/ supposed to become everyone's Christmas
Wishlist, please be modest. :-)

Re: Fwd: RFC: CLtL3 Charter

Brian O'Reilly — 2009-09-28T22:01:06

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


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

Re: RFC: CLtL3 Charter

John Cowan — 2009-09-14T18:42:50

Stanislaw Halik scripsit:


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.

Re: RFC: CLtL3 Charter

Stanislaw Halik — 2009-09-14T17:52:14


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.

Case wars. Re: wishlist items

Marco Antoniotti — 2009-09-08T15:27:55

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.





Cheers
--
Marco



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


--
Marco Antoniotti, Associate Professortel.+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.





_______________________________________________
cltl3-devel mailing list
cltl3-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

Re: wishlist items

John Cowan — 2009-09-07T19:02:55

Robert Uhl scripsit:


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-PrmTNUR8zL8< at >public.gmane.org
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know

Re: wishlist items

Daniel Herring — 2009-09-08T00:44:12


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.



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.



Yes modulo the details; they are closely related ideas.

- Daniel

Re: wishlist items

Robert Uhl — 2009-09-07T16:35:39

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


That's a big and important one indeed.


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


That would be Very Nice Indeed.


Is this the same as generalised sequences?

Pathnames

Marco Antoniotti — 2009-09-07T09:25:46

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

Re: RFC: CLtL3 Charter

John Fremlin — 2009-09-07T05:31:31

Fair enough.


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.


No :-)


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?


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 ;-)


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

wishlist items

Daniel Herring — 2009-09-07T04:44:42

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

Re: RFC: CLtL3 Charter

Gustavo — 2009-09-06T21:15:32

_______________________________________________
cltl3-devel mailing list
cltl3-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

Re: RFC: CLtL3 Charter

Robert Uhl — 2009-09-06T18:48:35

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.

Re: RFC: CLtL3 Charter

Gustavo — 2009-09-06T18:26:44

_______________________________________________
cltl3-devel mailing list
cltl3-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel

Re: RFC: CLtL3 Charter

Drew Crampsie — 2009-09-06T17:24:26

2009/9/6 John Fremlin <john-F7Dg16nrplxAfugRpC6u6w< at >public.gmane.org>:

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.


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


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



Something like this is

Re: RFC: CLtL3 Charter

John Fremlin — 2009-09-06T14:20:29

[...]

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.

[...]

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.

[...]

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