- pro - mailman3.common-lisp.net

[pro] [Extended Deadline] European Lisp Symposium 2013 - Madrid - June 1-4
by Didier Verna 05 Mar '13

05 Mar '13

;; ______ _ _____ _ __ ____ ;; | ____| | | / ____| ( ) /_ | |___ \ ;; | |__ | | | (___ |/ | | __) | ;; | __| | | \___ \ | | |__ < ;; | |____ | |____ ____) | | | ___) | ;; |______| |______| |_____/ |_| |____/ ;; ;; European Lisp Symposium 2013 - ELS'13 ;; Madrid, Spain ;; ;; June 1-4, 2013 ;; ;; http://els2013.european-lisp-symposium.org/ ** DEADLINE EXTENSION: March 17th ** 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 main theme of the 2013 European Lisp Symposium is on the use of these languages with respect to the current grand challenges: big tables, open data, semantic web, network programming, discovery, robustness, runtime failures, etc. The European Lisp Symposium 2013 solicits the submission of papers with these specific themes in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 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. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. 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. Invited speakers: Florian Loitsch, Google: Dart, why you should care. Gérard Assayag, Ircam: Lisp and Music Research. Important dates: March, 17th 2013: submission deadline ** EXTENDED ** April, 5th 2013: acceptance results June, 1-4 2013: symposium Program Commitee: Pascal Costanza, Intel, Belgium Ludovic Courtes, INRIA, France Theo D'Hondt, Vrije Universiteit Brussel, Belgium Florian Loitsch, Google, Denmark Christian Queinnec, UPMC, France Kurt Noermark, Aalborg University, Denmark Olin Shivers, Northeastern University, USA Manuel Serrano, INRIA, France Didier Verna, EPITA, France Chair: Juan Jose Garcia-Ripoll, local organizer Christian Queinnec, PC co-chair Manuel Serrano, PC co-chair -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[pro] common-lisp.net down...
by Pascal Costanza 01 Jan '13

01 Jan '13

Hi, Happy new year to you all! As the subject line says, common-lisp.net seems to be down. Does anyone here on the list happen to be able to fix this? Thanx! Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

2 1

[pro] What was wrong with environments as in CLTL2 pp. 207-214?
by Jean-Claude Beaudoin 15 Dec '12

15 Dec '12

Dear all, I am currently implementing the environments interface described in section 8.5 of CLTL2 (pp. 207-214) for MKCL. It feels like a very natural extension of what was already part of the code of the Lisp-to-C compiler MKCL inherited. It feels so natural in fact that I cannot figure out why that feature has been pulled out of the final ANSI CL specification. [And I have a hell of time standing all those (declare (ignore env)) sprinkled all over the MKCL source code.] I think that some of you reading this list were there, part of the action, during those standardization days. Maybe you could shed some light on what was wrong with this part of the spec and motivated its removal. Cheers, Jean-Claude Beaudoin

4 4

[pro] Phylosophical question on "syntactic" constructors
by Marco Antoniotti 05 Dec '12

05 Dec '12

Dear all, I was fooling around with reader macros to implement some - let's say - "tuple" syntax. Now, I am just curious about the general thinking on this. First of all, let's note that the problem here in the conflating of the "constructor" with the "printed representation" of an item. I.e., in Matlab you say >> [1, 2, 40 + 2] ans = 1 2 42 In CL, doing the simple thing, you get cl-prompt> [1 2 (+ 40 2)] [1 2 42] but cl-prompt> #(1 2 (+ 40 2)) #(1 2 (+ 40 2)) So, suppose you have your [ … ] reader macro, would you have it work "functionally" or "quoting-ly" (for want of a better word)? I am curious. Note that the Matlab-style version would not break referential transparency if you did not have mutations. best Marco Antoniotti -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

5 4

[pro] ELS'13 CfP
by Christian Queinnec 02 Dec '12

02 Dec '12

;; ______ _ _____ _ __ ____ ;; | ____| | | / ____| ( ) /_ | |___ \ ;; | |__ | | | (___ |/ | | __) | ;; | __| | | \___ \ | | |__ < ;; | |____ | |____ ____) | | | ___) | ;; |______| |______| |_____/ |_| |____/ ;; ;; European Lisp Symposium 2013 - ELS'13 ;; Madrid, Spain ;; ;; June 3-4, 2013 ;; ;; http://els2013.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 main theme of the 2013 European Lisp Symposium is on the use of these languages with respect to the current grand challenges: big tables, open data, semantic web, network programming, discovery, robustness, runtime failures, etc. The European Lisp Symposium 2013 solicits the submission of papers with these specific themes in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 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. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. 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 directed, before March 1st, to https://www.easychair.org/conferences/?conf=els13 Invited speakers: Florian Loitsch, Google: Dart, why you should care. GÈrard Assayag, Ircam: Lisp and Music Research. Important dates: March, 1st 2013: submission deadline April, 5th 2013: acceptance results June, 3-4 2013: symposium Program Commitee: Pascal Costanza, Intel, Belgium Ludovic Courtes, INRIA, France Theo D'Hondt, Vrije Universiteit Brussel, Belgium Florian Loitsch, Google, Denmark Christian Queinnec, UPMC, France Kurt Noermark, Aalborg University, Denmark Olin Shivers, Northeastern University, USA Manuel Serrano, INRIA, France Didier Verna, EPITA, France Chair: Juan Jose Garcia-Ripoll, local organizer Christian Queinnec, PC co-chair Manuel Serrano, PC co-chair --

1 0

[pro] Search engine development discussion.
by orange thirty 30 Oct '12

30 Oct '12

Hello all, My name is Pablo Rivera (orangethirty), founder of Nuuton.com. Been a software engineer for a while and have used LISP in various situations before. I joined this list in order to create an open discussion regarding the development of the Nuuton search engine. It is being developed with Common LISP (GNU CLISP). We are currently in the design stage, and have not written a line of LISP. That is why I'm here. I would like to learn about your opinions before doing anything. As a collective, this group has a lot of knowledge about the language. Knowledge that will allow us to build a better search engine with LISP. After searching around the web, I've found some projects aimed at developing web crawlers and the like with LISP. Though nothing too big or concrete. My guess is that no one has ever tried to write such system for production use. I hope to be wrong in those accounts. I will ask for your input in terms of judging how well the implementations currently available will fit Nuuton. The first stage for the Nuuton search engine is to build a very basic crawling system. We already have one in Python. But I refuse to port over the Python code to LISP, because it would undermine the latter. If you so wish, I can go ahead and translate the Python code to LISP and we can work from there. About the project: Nuuton is a new search engine. It is being actively developed by a team of three programmers. Our aim is to develop the search engine programmers need and want. Currently, our only focus is in serving the programming community. All the help you give us will in turn help the community in getting a good search engine that is not riddled with advertisements. Nuuton is also not in the business of selling advertising. We respect your privacy and will not demand that you hand over your personal information. Ever. I chose LISP because it provides the flexibility that we need for semantic web search. Questions, opinions, anything is welcome. (If this is the wrong mailing list, please point me in the right direction.) -- Pablo Rivera Sent from my C64 Skype: orange.thirty

3 2

[pro] Sensible interpretation of declarations in CLOS
by Juan Jose Garcia-Ripoll 30 Oct '12

30 Oct '12

Dear all, I am retaking an old question, which is the utility of type declarations in a language that has the flexibility of the MOP. In an extremely open-minded setup, where any class is prone to change, not only their structure, but also their metaclass, it would seem that a local declaration of the kind (DECLARE (MY-CLASS FOO)) would be totally useless. But... do you actually face that flexibility in real life? I mean, declarations such as (DECLARE (TYPE MY-INTEGER-TYPE FOO)) are used in actual code, where there is an implicit contract that the DEFTYPE type will not be changed in unsafe code. Can't we assume something similar when facing CLOS? What would be a reasonable optimization/safety/debug level to start considering that? Best, Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

5 6

[pro] Curating libraries
by Faré 29 Oct '12

29 Oct '12

Dear Dan, Maybe we should be moving this discussion to another list. I've asked admin(a)common-lisp.net to create lisp-interface-library-devel. >: Dan Lentz > Regarding consolidation under LIL just wondering if someone might have > suggestions for individual authors of CL data structure libraries on > how to work in a way most cooperative with the effort. For example I > have a small ctrie lib (http://github.com/danlentz/cl-ctrie) the > objective should be to refactor based on what unique interface it > could provide, such as "concurrent" or "lock-free"? > > Perhaps this question is somewhat specific to LIL but it is a project > I've been following with interest > It would be delighted to help with such an effort, either a merge of the two libraries, or a layer to make them work together. Also, considering that LIL has so few users (just drewc and I, IIUC), it is still time to rename basic API functions if you have strong opinions. While adding support for concurrent data structures has long been on my TODO list, I admit I haven't given much thought on how to automate (or not) whatever locking is required (or not) on various methods (not the same methods, depending on the data structure). So far, my hypothesis is that nothing needs to be changed as far as the signature of map interfaces goes: the underlying implementation may or may not be concurrent, that doesn't directly affect the calling conventions. Of course, concurrently accessing a non-concurrent data structure may blow up in your face, but I don't know how to express linearity constraints in Lisp, yet. That's a topic I'm actively researching, though, and suggestions are welcome. In short, I'd love that to happen, I'm ready to help, and a small data structure library is the perfect place to start. PS: I've added you as a contributor on https://github.com/fare/lisp-interface-library —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Be careful what you set your heart on — for it will surely be yours. — James Baldwin, "Nobody Knows My Name"

1 0

Re: [pro] pro Digest, Vol 24, Issue 5
by Dan Lentz 28 Oct '12

28 Oct '12

Regarding consolidation under LIL just wondering if someone might have suggestions for individual authors of CL data structure libraries on how to work in a way most cooperative with the effort. For example I have a small ctrie lib (http://github.com/danlentz/cl-ctrie) the objective should be to refactor based on what unique interface it could provide, such as "concurrent" or "lock-free"? Perhaps this question is somewhat specific to LIL but it is a project I've been following with interest ---- Replace the method the carefully chosen name deletes the comment On Oct 28, 2012, at 3:01 PM, "pro-request(a)common-lisp.net" <pro-request(a)common-lisp.net> wrote: > Send pro mailing list submissions to > pro(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro > or, via email, send a message with subject or body 'help' to > pro-request(a)common-lisp.net > > You can reach the person managing the list at > pro-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pro digest..." > > > Today's Topics: > > 1. Curating libraries (Far?) > 2. Re: Curating libraries (A.J. Rossini) > 3. Re: Curating libraries (Far?) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Oct 2012 09:50:18 +0900 > From: Far? <fahree(a)gmail.com> > To: Common Lisp Professionals <pro(a)common-lisp.net> > Subject: [pro] Curating libraries > Message-ID: > <CAN7nBXfK6R7xB4R_afRdLZ_aR_cyjq14=NVTdVLVEdvWmPPLEQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Dear Lisp pro, > > I think it is time for us (the Lisp professionals) to do a better job > at curating libraries. > > Now that, thanks to Quicklisp, people aren't afraid from using > libraries anymore, > we find that there are too many libraries for any given problem domain, > yet that most of these libraries do a bad 80% job max (sometimes 50% or less). > Moreover, navigating which of these libraries makes most sense to use is hard. > > Ideally, we'd have a one distinguished library providing a 100% solution > for any such domain, that we could use and recommend, and that would have > an easily recognized name. > > For instance, regarding pattern-matching libraries, I'd like to retire > fare-matcher, > and after migrating any remaining useful functionality (such as > fare-quasiquote), > recommend that all users should use optima instead. I would similarly push > toward the retirement of all other pattern-matching libraries but one. > That one library could then be called "pattern-matching" and use the package > "pattern-matching". > > Similarly, I'm trying to push for a single data structure library. > This time, I'm putting forward my own Lisp-Interface-Library (aka LIL) > because I think it has much more potential than other libraries, > including some with a lot of existing data structures (such as cl-containers): > Indeed, LIL can accommodate both pure and stateful data structures, > in both Interface-Passing Style (IPS) and > traditional Object-Oriented Programming (OOP), > with automatic mapping between the four combinations. > Moreover, its IPS allows for parametric polymorphism, > which wasn't previously available in CL, and > is great to bootstrap new data structures. > > I'd like to invite you to join me in this effort. > Whichever libraries you use or maintain, > please partake in this consolidation effort. > > ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org > The problem with being a citizen of the world is > that you don't get to travelling abroad much. > > > > ------------------------------ > > Message: 2 > Date: Sun, 28 Oct 2012 08:25:48 +0100 > From: "A.J. Rossini" <blindglobe(a)gmail.com> > To: Far? <fahree(a)gmail.com> > Cc: Common Lisp Professionals <pro(a)common-lisp.net> > Subject: Re: [pro] Curating libraries > Message-ID: > <CAA1MS4pVM0-ePAPsA1Dx_FH8dTWsxr1zHKk6YSMUhqbuFyFu=A(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Oct 28, 2012 at 2:50 AM, Far? <fahree(a)gmail.com> wrote: > >> I'd like to invite you to join me in this effort. >> Whichever libraries you use or maintain, >> please partake in this consolidation effort. > > As discussed, am looking at the data importers ((text)-file or system > to CL array, i.e. the prototypical CSV to CL-array importer), and > would be happy to work with others who want to take a lead on this > topic (I'm aware of 5-6 blog posts over the past few years to review > as part of due diligence, and 5+ different systems which range from > simple importers to a bit more sophisticated state machine parsers...) > > I eventually need something like a unified version of R's foreign > package (unified with the other data importer and exporter packages), > but of course, need to start somewhere, and somewhere is with CSV, > TSV, and similiar delimiter-separated-values (DSV). > > best, > -tony > > blindglobe(a)gmail.com > Muttenz, Switzerland. > "Commit early,commit often, and commit in a repository from which we > can easily roll-back your mistakes" (AJR, 4Jan05). > > Drink Coffee: Do stupid things faster with more energy! > > > > ------------------------------ > > Message: 3 > Date: Sun, 28 Oct 2012 17:01:58 +0900 > From: Far? <fahree(a)gmail.com> > To: "A.J. Rossini" <blindglobe(a)gmail.com> > Cc: Common Lisp Professionals <pro(a)common-lisp.net> > Subject: Re: [pro] Curating libraries > Message-ID: > <CAN7nBXcSAopSCLcWVeYM=2HQfFczLfuD-LNqBNs_xwyTmPjzDw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Oct 28, 2012 at 4:25 PM, A.J. Rossini <blindglobe(a)gmail.com> wrote: >> On Sun, Oct 28, 2012 at 2:50 AM, Far? <fahree(a)gmail.com> wrote: >> >>> I'd like to invite you to join me in this effort. >>> Whichever libraries you use or maintain, >>> please partake in this consolidation effort. >> >> As discussed, am looking at the data importers ((text)-file or system >> to CL array, i.e. the prototypical CSV to CL-array importer), and >> would be happy to work with others who want to take a lead on this >> topic (I'm aware of 5-6 blog posts over the past few years to review >> as part of due diligence, and 5+ different systems which range from >> simple importers to a bit more sophisticated state machine parsers...) >> >> I eventually need something like a unified version of R's foreign >> package (unified with the other data importer and exporter packages), >> but of course, need to start somewhere, and somewhere is with CSV, >> TSV, and similiar delimiter-separated-values (DSV). > Speaking of CSV, a few years back I reviewed the existing offering and > beefed up my fare-csv library which was lagging behind so it was > better than all other available CSV libraries (at the time): fare-csv > can be configured to be compliant with at least two conflicting CSV > standards, and more, and by default follows the more relaxed > "Creativyst" specification. > > I haven't followed recent developments, but there as in other cases, > someone who actually develops or uses these libraries should drive a > consolidation. > > ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org > You cannot teach a man anything; you can only help him find it for himself. > ? attributed to Galileo Galilei > > > > ------------------------------ > > _______________________________________________ > pro mailing list > pro(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro > > End of pro Digest, Vol 24, Issue 5 > **********************************

1 0

[pro] Curating libraries
by Faré 28 Oct '12

28 Oct '12

Dear Lisp pro, I think it is time for us (the Lisp professionals) to do a better job at curating libraries. Now that, thanks to Quicklisp, people aren't afraid from using libraries anymore, we find that there are too many libraries for any given problem domain, yet that most of these libraries do a bad 80% job max (sometimes 50% or less). Moreover, navigating which of these libraries makes most sense to use is hard. Ideally, we'd have a one distinguished library providing a 100% solution for any such domain, that we could use and recommend, and that would have an easily recognized name. For instance, regarding pattern-matching libraries, I'd like to retire fare-matcher, and after migrating any remaining useful functionality (such as fare-quasiquote), recommend that all users should use optima instead. I would similarly push toward the retirement of all other pattern-matching libraries but one. That one library could then be called "pattern-matching" and use the package "pattern-matching". Similarly, I'm trying to push for a single data structure library. This time, I'm putting forward my own Lisp-Interface-Library (aka LIL) because I think it has much more potential than other libraries, including some with a lot of existing data structures (such as cl-containers): Indeed, LIL can accommodate both pure and stateful data structures, in both Interface-Passing Style (IPS) and traditional Object-Oriented Programming (OOP), with automatic mapping between the four combinations. Moreover, its IPS allows for parametric polymorphism, which wasn't previously available in CL, and is great to bootstrap new data structures. I'd like to invite you to join me in this effort. Whichever libraries you use or maintain, please partake in this consolidation effort. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The problem with being a citizen of the world is that you don't get to travelling abroad much.

2 2