- pro - mailman3.common-lisp.net

Congruence of lamda-lists of methods with their generic-function
by Jean-Claude Beaudoin 09 Feb '14

09 Feb '14

Hello CL Pros, I am trying to understand the meaning in conforming ANSI CL of the following code snippet and I am not quite sure what to think of it: (defgeneric foo (a b &key)) (defmethod foo (a b &key c d) (or c d 42)) At this point should a call to foo accept any keyword argument, no keyword argument or only :c and/or :d? What would be the outcome of this: (foo 1 2 :d 3) Is it an error being signaled or the value 3 being returned? I am inclined to believe that an error should be signaled, since the generic function lambda-list contains no explicit keyword argument and no &allow-other-keys. Reading CLHS 7.6.4 it seems to me that (defgeneric foo (a b &key)) and (defgeneric foo (a b &key &allow-other-keys)) are two different things as to the set of keyword arguments they each will accept. The first one being the empty set and the second the set of all possible sequence of keyword arguments (limits set aside). Am I right? Also if I go for (defgeneric (a b &key &allow-other-keys)), is the lambda-list of the method as here above still congruent? Doesn't it need to be rewritten as: (defmethod foo (a b &key c d &allow-other-keys) ...) or (defmethod foo (a b &rest other-args) ...) to be properly congruent? Thanks, Jean-Claude Beaudoin

5 4

loop conformance
by Steve Haflich 30 Jan '14

30 Jan '14

I'm in a grumpy mood today, so I decided to take out my frustrations on the ANS for CL, or implementations thereof. Consider carefully what the following form should return: (let ((v (make-array 10 :initial-contents '(0 1 2 3 4 5 6 7 8 9) :fill-pointer 5))) (loop for x across v when (eql x 2) do (incf (fill-pointer v)) collect x)) ACL and SBCL both return (0 1 2 3 4). Probably every other implementation does too. I believe the ANS requires the return to be (0 1 2 3 4 5), although the definition in *6.1.2.1.5 The for-as-across subclause* uses various undefined terminology. (We of X3J13 understood that the loop specification was not our best work.)

7 10

Fwd: ASDF walkthrough
by Faré 25 Jan '14

25 Jan '14

Reminder for those who knew, late announcement for the others: the ASDF walkthrough will happen on Google Hangouts tomorrow Sunday 2014-01-26 from 1400 to 1600 EST (1900 to 2100 UTC). If you want to attend and didn't register yet, send me a personal email specifying which hangout address I should invite tomorrow. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The older I grow, the more I distrust the familiar doctrine that age brings wisdom. — H.L. Mencken On Fri, Jan 3, 2014 at 2:10 AM, Faré <fahree(a)gmail.com> wrote: > Dear Lisp hackers, > > I'm considering recording a walk through the ASDF sources. > > I'd like to have an interactive session over Google Hangout > with one or a few people, explaining the current code in asdf/defsystem > (i.e. not going into uiop, except to minimally explain what asdf uses). > That should take about 2 hours. > > To enjoy the walkthrough, you need to be somewhat fluent in Common Lisp, > and somewhat familiar with how to use ASDF, though not necessarily with > either extending it or hacking its internals. > > If at least one person is familiar with ASDF 2 and has questions, > that could be interesting, or that could be a separate session. > > Please respond me to this email (privately or publicly) if you're interested. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > We are always in anarchy. But we pay a hefty price maintaining the illusion > that we aren't, and another one being misled by the illusion.

1 0

Fwd: ASDF walkthrough
by Faré 04 Jan '14

04 Jan '14

Dear Lisp hackers, I'm considering recording a walk through the ASDF sources. I'd like to have an interactive session over Google Hangout with one or a few people, explaining the current code in asdf/defsystem (i.e. not going into uiop, except to minimally explain what asdf uses). That should take about 2 hours. To enjoy the walkthrough, you need to be somewhat fluent in Common Lisp, and somewhat familiar with how to use ASDF, though not necessarily with either extending it or hacking its internals. If at least one person is familiar with ASDF 2 and has questions, that could be interesting, or that could be a separate session. Please respond me to this email (privately or publicly) if you're interested. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If a trainstation is where the trains stop, what is then a workstation... — Lars Lundgren <d95lars(a)dtek.chalmers.se>

12 13

Enumerated Types in CL.
by Antoniotti Marco 03 Jan '14

03 Jan '14

Hello I created a small library to define “enums” in Common Lisp. It is Yet Another^n DEFENUM macro. The site is defenum.sourceforge.net. A blog entry with some comments (especially by Farè) is here: http://within-parens.blogspot.gr/2014/01/enumerated-types-in-cl.html I would not mind having a discussion about the beast. The design is simply “let’s do in CL what they do in Java and C/C++”, so it does have some shortcomings and the implementation is still sub-optimal. All the best -- Marco Antoniotti

1 0

STM advice
by Paul Tarvydas 21 Dec '13

21 Dec '13

I'm about to look into Software Transactional Memory techniques for some financial code I'm involved with. Any advice about which libraries to look at (and why) would be quite welcome. Thanks pt

3 2

[CfP] International Lisp Conference, Aug. 14-17 2014, Montréal, Canada
by Didier Verna 18 Dec '13

18 Dec '13

ILC 2014 - International Lisp Conference "Lisp on the Move" August 14-17 2014, Université de Montréal, Montréal, Canada Sponsored by the Association of Lisp Users http://www.international-lisp-conference.org Scope: Lisp is one of the greatest ideas from computer science and a major influence for almost all programming languages and for all sufficiently complex software applications. The International Lisp Conference is a forum for the discussion of Lisp and, in particular, the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. We invite high quality submissions in all areas involving Lisp dialects and any other languages in the Lisp family, including, but not limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript, Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc. This year's focus will be directed towards integrated solutions, including mobile computing. We especially invite submissions in the following areas: * Pervasive computing * Interoperability * Portability * Implementation challenges/tradeoffs for embedded/mobile platforms * Language support for mobile toolkits and frameworks * Language support for distribution * Language support for reliability, availability, and serviceability * Mobile IDEs * Mobile applications Contributions are also welcome in other areas, including but not limited to: * Language design and implementation * Language integration, inter-operation and deployment * Applications (especially commercial) * Reflection, meta-object protocols, meta-programming * Domain-specific languages * Programming paradigms and environments * Efficient parallel and concurrent computation * Language support for managing both manual and automatic GC * Theorem proving * Scientific computing * Data mining * Semantic web Technical Programme: Original submissions in all areas related to the conference themes are invited for the following categories: Papers: Technical papers of up to 10 pages that describe original results. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries and applications. Workshops: Abstracts of up to 2 pages for groups of people who intend to work on a focused topic for half a day. Tutorials: Abstracts of up to 2 pages for in-depth presentations about topics of special interest for 1 to 2 hours. Panel discussions: Abstracts of up to 2 pages for discussions about current themes. Panel discussion proposals must mention panel member who are willing to partake in a discussion. The conference will also provide slots for lightning talks, to be registered on-site every day. For inquiries about any other kind of participation (commercial exhibits, advertising, prizes, book signing etc.), please see the contacts below. Important Dates: - May 18, 2014: Submission deadline - June 09, 2014: Notification of acceptance - June 29, 2014: Final Papers due - August 14, 2014: Conference All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=ilc14 Organizing Committee: General Chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Committee: to be announced Contacts: * General Questions: ilc14-organizing-committee at alu.org * Programme Committee: ilc14 at easychair.org For more information, see http://www.international-lisp-conference.org -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

7th European Lisp Symposium, May 5-6 2014, Paris, France
by Didier Verna 30 Nov '13

30 Nov '13

ELS'14 - 7th European Lisp Symposium IRCAM, Paris, France May 5-6, 2014 http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 7th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Please note that IRCAM, the conference venue, is a French institute for research on music and acoustics. Submissions relating Lisp to music or other acoustical matters will hence be particularly welcome, although given no heightened favor during the review process. We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - TODAY: Mark your calendar. Start planning now! - 09 Mar 2014: Submission deadline - 31 Mar 2014: Notification of acceptance - 21 Apr 2014: Final Papers due - 05 May 2014: Symposium. Join us there! Program Committee: Chair: Kent Pitman, Hypermeta Inc., U.S.A. Local Organizers: Didier Verna, EPITA Research Lab, France Gérard Assayag, IRCAM, France Members: To be announced later Search Keywords: #els2014, ELS 2014, ELS '14, European Lisp Symposium 2014, European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium, European Lisp Conference 2014, European Lisp Conference '14 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Landing page?
by Pascal Costanza 24 Nov '13

24 Nov '13

Hi, Meta-question: Where does this mailing list have a webpage that can be referred to, and that explains how to subscribe / unsubscribe? Thanks, and sorry if this is a too-obvious question, Pascal -- Pascal Costanza

2 1

:DBG
by Faré 21 Nov '13

21 Nov '13

In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp). Yes, it's in the keyword package. Why? Because it's the one and only macro I want to be accessible from everywhere without a prefix, yet without modifying existing defpackage forms to make it accessible — because it's only used temporarily for debugging. :DBG is a macro for print-debugging. The syntax is (:DBG tag forms... last-form) The semantics is that if tag is true, print the tag, then for each form, write its source and its values; return the values of the last form. If tag is false, just evaluate the last form and return its values. (Tag is typically a constant keyword or string, identifying the point where values are printed.) The expansion is rather space and time efficient, as far as the semantics permit. I find :DBG soooo useful for print-debugging. I've seen tens of variants of it, but every time with something not quite right in the syntax, semantics or implementation. I just wanted one variant that got everything right, and make it ubiquitous. Because when you need it, you need it now, and there's no time to modify things to load an additional library. And when you're done, you want minimal cleanup, too: just delete the form, except maybe keep the last subform. Previously, I was using (uiop:uiop-debug) from uiop/utility which allows you to load a magic file of your choice that defines a debug mode. The default one I provided was mine, which define :DBG as DBG in your current package (thereby avoiding symbol import issues). But that still adds a new definition everytime and an extra line or form to cleanup. I was recently convinced that using the keyword package instead makes perfect sense: on the one hand, that's using a shared namespace that it is polite to not pollute, but on the other hand, such a temporary print-debugging macro the only use case I imagine of otherwise wanting something to be immediately accessible without package prefixing yet without modifying the package definition form. It's still time to remove that macro before the next release, but I believe it's the right thing to include it, and maybe some of you will agree with me and start using it, if not from the yet unrelease ASDF 3.1.1, perhaps from a copy in your .sbclrc. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The common argument that crime is caused by poverty is a kind of slander on the poor. — H. L. Mencken

16 24