[Please accept our apologies if you receive this message more than once]
CALL FOR CONTRIBUTIONS
International Lisp Conference 2005
http://www.international-lisp-conference.org
Stanford University
June 19-22, 2005
Sponsored by:
The Association of Lisp Users
Symbolic Systems Program, Stanford University
General Information:
The Association of Lisp Users is pleased to announce that Stanford
University will host the next International Lisp Conference
between June 19 and 22. ILC 2005 marks the 25th anniversary of
the seminal 1980 Lisp conference held at Stanford in August of
1980.
This year, the Organizing Committee of ILC 2005 is encouraging
submissions in the particular areas of: functional language design
and implementation, mathematical and scientific computing,
artificial intelligence, data mining, business intelligence,
bioinformatics, telecommunications and networking, the semantic
web, music, and entertainment technologies.
Further details are available at the conference web site.
General correspondence on ILC 2005 may be sent to ilc2005(a)alu.org.
Technical Program:
Original submissions in all areas related to the conference themes
are invited for the following categories: papers, exhibits,
workshops, tutorials, and panel discussions. The official
language of the conference is English.
Important Dates:
Deadline for abstract submissions: March 15, 2005
Author notification: March 31, 2005
Deadline for final paper submission: April 30, 2005
Organizing Committee:
Chair: Carl Shapiro (SRI International)
Members: Rusty Johnson (ALU)
Peter Lindahl (ALU)
Contact: ilc05-organizing-committee(a)alu.org
Program Committee:
Chair: JonL White (ALU)
Members: Jans Aasman (Franz, Inc.)
John Adams (Space Telescope Science Institute)
John Amuedo (Signal Inference Corporation)
Kazuyuki Hashimoto (Electronic Arts)
Larry Hunter (UCHSC)
Nick Levine (Ravenbrook Limited)
Christian Queinnec (Universite Paris 6)
Nancy Reed (University of Hawaii)
Jeff Shrager (Stanford University)
Mark Stickel (SRI International)
Taiichi Yuasa (Kyoto University)
David Wilkins (SRI International)
Contact: ilc05-program-committee(a)alu.org
Here is an announcement of the Closer Project. This project is an
umbrella project for a few subprojects whose aim is to improve the
usability of the CLOS MOP across different Common Lisp implementations.
The project website is at http://common-lisp.net/project/closer/
The first step (which already exists to a large degree) is a library
that checks what features of the AMOP specification is supported by a
given CL implementation. This results in a number of keywords that
describe the various aspects of a MOP which can, for example, be used
to conditionalize one's source code (when added to *features*).
Currently, the following Common Lisp implementations are supported:
* Allegro Common Lisp, 6.2 Trial Version
* CLisp, 2.33.80
* CMU CL, experimental port to Mac OS X, 2004-01-28-020
* LispWorks 4.3 for Macintosh, Personal Edition
* OpenMCL 0.14.2-p1
* SBCL 0.8.18
...and some other implementation that I am not allowed to talk about.
The second step (which exists as a rough sketch) is a compatibility
library that provides a package that adds missing features and/or
replaces existing features with versions that better reflect the AMOP
specs. If the latter is not possible, I try to provide utility
functions that allow one to work around restrictions.
Finally, the Closer project should host a few example metaclasses,
including some of the examples given in AMOP, and probably others as
well. For example, my goal is to move some of the stuff from AspectL to
the Closer project in order to turn this into a more coherent library.
It is important to provide example applications of the MOP because they
implicitly provide test cases against which new MOP implementations can
be checked for compatibility.
So in the long run, the Closer project should help to bring the MOP
into a shape that Common Lisp programmers can better rely on across
many implementations.
Pascal
Disclaimer: This project is in a very early stage. Don't publish any
findings about existing MOP implementations based on the software
offered there with the implicit suggestion that they are facts. It is
very likely that the code includes bugs and misinterpretations of the
AMOP specification. You have been warned!