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/~trittweiler/talks/sequence-iterators-2009.pdf

If you want to help out on that instead, drop me a mail.

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

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

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

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

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

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



Out of scope as well.


Environments are worth looking into, yes.


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


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?


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



Because it's crap, and we have SHADOW.


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.


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


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

Cheers,

drewc

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

[...]

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.


[...]


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?

[...]


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


[...]

Or Ron Garret's ideas.


[...]

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.

[...]


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

[...]


Why not?


Yes.

[...]


?

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

[...]