Hello everyone,

it's an immense pleasure to welcome Richard P. "dick" Gabriel as the first keynote speaker of the 7th European Lisp Symposium. You can read about his talk on this page. This will hopefully make people wake up early on the fist day :-)

EDIT and we now have 2 more guest speakers: Pascal Costanza and Gábor Melis! Can't wait!

2014 is going to be a busy year for Lisp. The 7th European Lisp Symposium (Paris, May) will be followed by the International Lisp Conference (August, Montréal). ILC 2014's Call for Papers is just out! And this year, we have a special focus for you...

	       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

If you work in the academy, you are surely already getting a lot of spam from fake conferences asking for papers, PC participation etc. You also know that several years ago, a new form of harassment appeared: fake academic journals. There seems to be more and more of those everyday.

Sometimes, they're a bit hard to spot, especially if their focus seems to be in accordance with your activities. A hint is that you've never heard of them before, though. And sometimes, they're not hard to spot... at all. Meet the stupidest fake academic journal ever: the Journal of Bioinformatics and Biological Engineering.

Here's what I recieved yesterday:

We recently noticed your outstanding paper “Lisp: Report on the 5th workshop ELW at ECOOP 2008” and it well suits the focus and scope of Journal of Bioinformatics and Biological Engineering(JBBE). Considering that we share the same interests in Bioinformatics and Biological Engineering, we are now sending this message to you and sincerely invite you to share your new research or updated results in JBBE.

So, here are a couple of remarks:

1. It's cool that you have noticed this paper "recently", although it's almost 6 years old now.
2. The paper in question is actually not a paper. It's a conference proceedings for which I was programme chair, so basically, I wrote only the cover in it.
3. Finally, there is nothing related to Biology in there. It's about a dynamic programming language.

Well done, guys. You almost got me! Ah, one more thing: I do have some interest in Computer Science and Biology, and I even wrote two papers in this area. Apparently, you failed to spot them, though...

Here's the end of the message:

Please kindly forward this email to your colleagues and students. We shall be greatly appreciated to hear from you at any time.

No, I won't forward this email to my colleagues. And no, you shan't be "greatly appreciated" to hear from me at any time!

Note: the feature described below is now available in the cutebar branch of my Emacs fork on GitHub.

A huge peeve of mine on OS X is the mixture of the (application) menu bar, starting on the left, and the status bar, starting on the right: when you have a lot of status indicators like me, even a reasonably sized application menu bar will irreparably hide a lot of status, which is really annoying.

One day, I had this idea that application menu bar (wide) titles could be replaced with (narrow) icons, hence leaving more space to the status bar. Of course, it shouldn't be up to the menu, or even to the application itself to choose which icon to use. It should be up to the user. A user will want a single icon set to work with all applications (e.g. you choose a nice File icon, and you want all applications to use it instead of the word "File").

So one day, I implemented a SIMBL plugin and preference pane for doing exactly that. Don't look for it, it's never been released. It lets the user create associations between menu titles and icons and hijacks OS X applications to modify the appearance of their menu bar. Alas, it doesn't work very well. Native Cocoa applications not doing anything fancy with their menus are ok, but most other applications are not.

Today, let me introduce some support for this feature in Emacs. Attached to this article is a patch against the current trunk plus a small image file. For this to work, you will need to put the image file (barsplit.png) in the etc/images/ directory of Emacs'source tree, apply the patch and recompile (--with-ns of course). Then, find yourself a nice set of icons and go customize the options menu-bar-use-icons, menu-bar-icons-directory and menu-bar-icons in the "menu" custom group. The docstrings should be self-explanatory. As you can see on the screenshot, what you get is a much narrower, visual menu bar. The first menu (the so-called "application menu") always uses the official application's icon. The other ones are your choice. Finally, the menu bar ends with a visual separator allowing to better distinguish its end from the start of the status bar.

The current implementation is very naive (sorry, I meant highly dynamic): titles / icons associations are recomputed every time the menu bar is redrawn. But this has in fact some advantages:

1. the code is quite simple,
2. customizations made by the user are visible immediately, without the need for a complex event listener / notification / whatever machinery (this machinery may already exist in the Emacs codebase though).

In fact, I've been using this patch for quite a while now and I didn't notice any performance impact on my 3 years-old Mac Book Pro. One last thing you need to know: the behavior of this feature may be unreliable (even if implemented correctly, which I think I did) because messing with the menu bar like this is uncharted territory, totally unsupported by Apple. Enjoy anyway :-)

Now, if somebody comes up with a nice and comprehensive set of menu bar icons for Emacs (and other OS X apps), I'd be delighted...

In the process of writing Declt, I had to deepen my knowledge of some Lisp corner cases, notably in the area of introspection. As you know, Lisp has in fact more than 2 namespaces. Sometimes, introspecting a potential symbol definition in one namespace is trivial. COMPILER-MACRO-FUNCTION is one example. The "functional" namespace is heterogeneous but you can still make your way out of macros, regular or generic functions very easily. In the same vein, distinguishing constants, special variables and symbol macros in the "variables" namespace is more complicated because there is no standard way to access that information, but with the help of some vendor-specific machinery (e.g. SB-INT:INFO), it's still doable.

At some point, I tackled the case of method combinations, and to my greatest surprise, found out that introspecting a method combination by name is not simple. In fact, it's not even doable. The reason is that method combinations don't have a namespace proper. Let me explain why.

You define a new method combination of some NAME with DEFINE-METHOD-COMBINATION, and you use it with the :METHOD-COMBINATION option to DEFGENERIC. But how do you introspect a NAME for a potential method combination definition? Well, you can't do exactly that. First, there is no standard way to do so. Next, let's look at what the MOP provides. One would expect something along the lines of FIND-CLASS...

There is indeed something called FIND-METHOD-COMBINATION, but either I'm missing something, or it is really, and I mean really badly designed. The arguments to this function are: a generic function meta-object, a method combination name and some method combination options. So if this function is supposed to be the equivalent of FIND-CLASS for method combinations, what in the hell are the 1st and 3rd arguments for? In fact, it's not supposed to do what its name suggests. According to the AMOP, p.191, the purpose of this function is to "determine the method combination object used by a generic function". In practice however (at least in SBCL), it's not doing that either (see below), and anyway, determining the method combination object used by a generic function is better achieved by using the GENERIC-FUNCTION-METHOD-COMBINATION accessor.

So this protocol doesn't seem to make any sense. In order to understand what to make of all this, I looked at how SBCL handles method combinations (I don't know what other vendors do) and here is what I found. When you call DEFINE-METHOD-COMBINATION for some NAME, SBCL creates a new method for FIND-METHOD-COMBINATION, eql-specialized on that NAME. This method is encapsulated in a closure containing the method combination's definition, ignores its first argument (the generic function meta-object; that's why I said that it's not really doing what the AMOP says it does), recreates and returns a new method combination object on the fly every time it is called.

This has several consequences. First, the notion of "method combination named NAME" doesn't really make sense. Method combinations don't have a proper namespace. Every time you create a new generic function, the method combination essentially becomes local to that function. Redefining a method combination has no effect on existing generic functions using a method combination of the same NAME. To put it differently, you can end up with several generic functions using different yet equally named method combinations.

In Declt, I'm now assuming that programmers behave and only define method combinations once. Which brings us to the second consequence. With that assumption in mind, the "proper" way to introspect a NAME for a method combination definition (at least in SBCL) is to first look for the existence of a FIND-METHOD-COMBINATION method eql-specialized on that NAME, and then call it to retrieve the actual definition.

I haven't thought about it a lot yet, but it would be interesting to investigate the idea of cleaning this up a bit. I mean, establishing a real global namespace for method combinations, creating an alternate FIND-METHOD-COMBINATION protocol more along the lines of FIND-CLASS. And then, it could also be interesting to investigate on the potential applications of allowing method combination redefinition to affect live generic functions, just like class redefinition affects live instances...

This morning, I came up with a nice little trick which made my day. Perhaps this is already well known or even idiomatic, but in case it is not, it goes like this.

Sometimes, I have to read a whole Lisp file containing more than just one toplevel form and get the contents as an unprocessed list of expressions. This happens for instance when loading a DSL program that needs post-treatment.

Usually, I end up doing something like this:

(with-open-file (stream filename)
  (loop :for expr = (read stream nil :eof)
	  :if (eq expr :eof)
	    :return exprs
	  :else
	    :collect expr :into exprs)))

But for some reason, this has always felt clunky to me. I mean, instead of ogling the family jewels of this poor shy file, I should be able to read it as a whole (hint: read-delimited-list) and preserve its intimacy.

And then I realized that the only thing that prevents me from using read-delimited-list is the lack of an ending parenthesis. But as always, Common Lisp immediately comes to the rescue, this time with its rich streams API. The idea is that you can create a string stream that just contains the closing parenthesis, and concatenate this stream at the end of the file one. I can now do something like this instead:

(with-open-file (stream filename)
  (read-delimited-list #\) (make-concatenated-stream stream (make-string-input-stream ")"))))

Not only it is shorter, it also looks much more elegant to me.

I've been using this for years, but never bothered to make it public until now.

el-rcfiles is a very small and simple library which provides Unix-like RC files for Emacs Lisp libraries. It's compatible with GNU Emacs and XEmacs, available in ELPA form, as a tarball and from GitHub. More details (including download) available here, but here is also the library's commentary section, for quick reference.

;;; Commentary:

;; The purpose of el-rcfiles is to provide the equivalent of traditional
;; Unix rc files (i.e. configuration files) for Emacs Lisp
;; libraries. The advantages of using configuration files are the
;; following:
;;   - your initialization file is less bloated,
;;   - since configuration files are lazily loaded, your Emacs session
;;     is (or begins) lighter. That is unless you already use lots of
;;     EVAL-AFTER-LOAD forms...

;; Usage:

;; 1. Load the library, go to the rcfiles Custom group and tweak (or not).
;; 2. Put a call to (rcfiles-register-rc-files) in your initialization
;;    file. This function can also be called interactively anytime you
;;    add, remove or modify a configuration file.
;; 3. Put your configuration code for a library `foo' in a file called
;;    `<rcfiles-directory>/foo<rcfiles-pseudo-extension>.el'.

In a recent blog full of marketting crap, Twitter announced that they are dropping all versions of TweetDeck except for the web-based app, and that they are also dropping support for Facebook integration. Well, that's too bad because these were the only two things that made me use it.

The annoucement starts like this:

To continue to offer a great product that addresses your unique needs ...

Yeah, right. Great product? Not so much. For starters, it would have been really great if it had gotten support for Google Plus at some point. Something that many of us were desperately hoping for.

As for my "unique needs", thank you very much but you don't know squat about them obviously, and besides, they're not even "unique". Again, for many of us, what were the 2 crucial features of TweetDeck, compared to the other alternatives?

1. Social net aggregation (including Twitter and Facebook) plus sorting and filtering facilities; something that many other tools (such as HootSuite) do,
2. Social net merging, something that to the best of my knowledge, no other tool does.

This second feature was absolutely crucial to me. The ability to have the "Home" column displaying all social feeds all at once, all in one place. The "Interactions" column displaying a merge of all my interactions on both Facebook and Twitter all at once, all in one place. Boy, did I wish Google Plus was there as well. And now this is all gone.

So I guess I'm back to the stone age now. One freaking web page for every social net. Or I could finally switch to HootSuite, with its so ugly and so much bloated interface. Correct me if I'm wrong, but I don't think HootSuite does social merging (is there a tool left that does it now?). But at least, it has some partial support for Google Plus (only pages; let's hope that this will change soon).

The annoucement starts like this:

From the whole TweetDeck team, we’re excited about what the future holds. We hope you are too.

Well, you know, not so much, really.

So long, TweetDeck, and thanks for your help until today.

Hint: the next social net killer app will need to do social merging, sorting and filtering, with at least Twitter, Facebook and Google Plus. Now, to your keyboards, you geeks.

Hello,

just a quick note to let you know that we have finally opened the registration process for ELS 2013. See the bottom the page for more information. It is possible to register via PayPal or via direct bank transfer.

Looking forward to see you all !

Dyla'13, 7th Workshop on Dynamic Languages and Applications
Colocated with ECOOP, ECMFA and ECSA
1–5 July, Montpellier, France

http://rmod.lille.inria.fr/web/pier/Events/Dyla13

!! Important dates

- Submission deadline:  April 19th
- Notification: mid-May
- Workshop: July 1st
- Ecoop early registration: mid-May

!! Abstract

The advent of Java and C# has been a major breakthrough in the adoption of
some important object-oriented language characteristics. This breakthrough
turned academic features like interfaces, garbage collection, and
meta-programming into technologies generally accepted by
industry. Nevertheless, the massive adoption of these languages now also gives
rise to a growing awareness of their limitations. A number of reactions from
industry testify this: invokedynamic bytecode instruction has been included in
latest Java virtual machine release; the dynamic language runtime (DLR) is
gaining popularity; C# adopted dynamic as a valid static type. Gartner
prognoses further growth (http://blogs.gartner.com/mark_driver/2008/12/10) of
dynamic languages.

Researchers and practitioners struggle with static type systems, overly
complex abstract grammars, simplistic concurrency mechanisms, limited
reflection capabilities, and the absence of higher-order language constructs
such as delegation, closures and continuations. Dynamic languages such as
Ruby, Python, JavaScript and Lua are a step forward in addressing these
problems while getting more and more popular. Making these languages
mainstream requires practitioners to look back and pick mechanisms up in
existing dynamic languages such as Lisp, Scheme, Smalltalk and
Self. Practitioners also need to further explore discover new dynamic
approaches in the context of new challenging fields such as pervasive
computing.

The goal of this workshop is to act as a forum where practitioners can discuss
new advances in the design, implementation and application of dynamically
typed languages that, sometimes radically, diverge from the statically typed
class-based mainstream. Another objective is to discuss new as well as older
"forgotten" languages and features in this context. Topics of interest
include, but are not limited to:

- programming language extensions
- programming environment extensions
- executing environments
- static and dynamic analyses
- optional type-checking
- meta-object protocols
- reserve engineering
- domain-specific languages/tooling
- testing environments
- live programming

!! Targeted audience

The expected audience of this workshop is practitioners and researchers
sharing the same interest in dynamically typed languages. Lua, Python, Ruby,
Scheme and Smalltalk are gaining a significant popularity both in industry and
academia. Nevertheless, each community has the tendency to only look at what
it produces. Broadening the scope of each community is the goal of the
workshop. To achieve this goal we will form a PC with leading persons from all
languages mentioned above, fostering participation from all targeted
communities.

!! Workshop Format and Submission Information

The workshop will have a demo-oriented style. The idea is to allow
participants to demonstrate new and interesting features and discuss what they
feel is relevant for the dynamic-language community. To participate to the
workshop, you can either

- submit (before __April 19th 2013__) an article (ACM Tighter Alternate style
http://www.acm.org/sigs/publications/proceedings-templates) describing your
presentation and/or tool. Articles whose length ranges from 2 to 15 pages will
be carefully reviewed by a program committee including but not limited to the
organizers. Each accepted paper will be presented for 20 to 30 minutes and be
published to the ACM Digital Library (at the option of each author) and the
workshop's web site. The submission website is
http://www.easychair.org/conferences/?conf=dyla2013.

- or give a 10-minute lightning demo of your work. A dedicated session will be
allocated for this, provided there is ample time available.

A session on pair programming is also planned. People will then get a chance
to share their technologies by interacting with other participants.

!! Program committee

- Carl Friedrich Bolz, Heinrich-Heine-Universität Düsseldorf, Germany
(http://cfbolz.de)
- Camillo Bruni, Inria Lille-Nord Europe, France
(http://rmod.lille.inria.fr/web/pier/team/bruni)
- Adrian Kuhn, University of British Columbia, Canada
(https://www.cs.ubc.ca/people/adrian-kuhn)
- Lukas Renggli, Google, Switzerland (http://www.lukas-renggli.ch/)
- Juan Pablo Sandoval Alcocer, University of Chile
(http://users.dcc.uchile.cl/~jsandova/)
- Bastian Steinert, Hasso-Plattner-Institute, Germany
(http://www.bastiansteinert.org)
- Veronica Uquillas Gomez, Vrije Universiteit Brussel, Belgium
(http://soft.vub.ac.be/~vuquilla/)
- Simon Urli, University of Nice-Sophia Antipolis, France
(http://www.simonurli.fr/)
- Didier Verna, EPITA Research and Development Laboratory, France
(http://www.lrde.epita.fr/~didier)
- the 4 workshop organizers

!! Workshop Organizers

- Alexandre Bergel (http://bergel.eu)
- Damien Cassou (http://damiencassou.seasidehosting.st)
- Jorge Ressia (http://www.jorgeressia.com)
- Serge Stinckwich (http://www.doesnotunderstand.org)

!! News feed

Follow us on twitter: http://twitter.com/dyla2013
For further information: http://rmod.lille.inria.fr/web/pier/Events/Dyla13