gmane.lisp.cltl3.devel

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

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

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

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

Types

Levente Mészáros — 2009-09-02T12:12:08

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

RFC: CLtL3 Charter

Drew Crampsie — 2009-08-31T19:57:10

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.