Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 187

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 188

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 189

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 194

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 195

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 196

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 197

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 241

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 264

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 269

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 275

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 285

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 286

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 296

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 297

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 298

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 308

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 309

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 310

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 311

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 321

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 322

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 323

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 324

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 325

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 497

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 527

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 540

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 587

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 626

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 670

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 673

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 682

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 688

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 693

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 699

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 272

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 110

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 130

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 295
Lisp - Didier Verna's Scientific Blog - page 3
About Lectures Research Software Blog
Musical Site
MySpace
Facebook

Moods Blog

Dojo Shin Kaï

RSS Feed
Thank you!

XHTML 1.0 conformant
CSS 2.0 conformant
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff.

Wednesday, June 26 2013

Nice little trick du jour

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.

Friday, June 14 2013

ELS 2013 Material

ELS 2013, the 6th European Lisp Symposium, took place in Madrid on June 3th and 4th.

During the symposium, Nick Levine recorded audio versions of the presentations and collected them here. Nick has also agreed to collect other material from the presenters (slides notably) and put it at the same location. The page is growing up as we speak.

It was good to see you all in Madrid. Thanks to all the presenters and thanks Nick for doing this!

Tuesday, April 23 2013

Lisp, GSoC and CDRs

Here's a bright idea: why not take the GSoC opportunity to have someone implement all current CDRs in every major Common Lisp implementation? Not that I'm volunteering for anything. I'm justing throwing the though out in the open...

Monday, April 22 2013

ELS 2013 registration now open

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 !

Sunday, December 2 2012

ELS 2013

We are pleased to announce the next edition of the European Lisp Symposium: ELS 2013, to be held on June 3/4 2013 in Madrid, Spain.

This year we have the pleasure and honor of having Christian Queinnec and Manuel Serrano as co-chairs, and Juan-Jose "Juanjo" Garcia Ripoll, leader of the ECL project, as local organizer.

What's more, and for the first time, we are also delighted to announce that the symposium will be held in co-location with ECLM, the next European Common Lisp Meeting!

A couple of exciting days to come...

Tuesday, October 23 2012

Declt 1.0b15 "Kyoto" is out

This is Declt 1.0b15, the "Kyoto" release... Declt is a reference manual generator for Common Lisp libraries.

This version underwent a major internals overhaul, required by some of the new features described below:

  • Packages sections now advertise all definitions instead of just the symbols naming them. They also advertise their use-list and used-by-list, with cross-references.
  • Conditions, structures and classes now advertise their sub- and super-classes, direct methods, initargs and slots, with cross-references.
  • Slots documentation include docstring, type, initargs, initforms, readers and writers with cross-references.
  • Declt now documents symbol macros and compiler macros.
  • The *LINK-FILES* special is gone (M-x all-hail-purely-functional-style).
  • All ASDF components now advertise their descriptions and long descriptions, if any.
  • Docstrings are displayed in a more reader-friendly fashion.
  • Documentation entries for methods are nested within the corresponding generic function entry.

Grab it at the usual place.

The European Lisp Symposium website is back on (sort of)

In the recent months, the European Lisp Symposium steering committee has been seeking to improve its organization, notably on the financial level. To this aim, we created a non-profit organization in France (it's called ELSAA) which will help by providing a legal entity for all kinds of transactions.

A couple of days ago, I bought the domain name elsaa.org and started to re-install the ELS website that disappeared some time ago. I also took the opportunity to move the pages of the former European Lisp Workshop there (european-lisp-workshop.org now points to it). If you want to access the ELS pages, you can do so right now by using this URL: http://els.elsaa.org. The domain name european-lisp-symposium.org has not been redirected yet, but this will come soon I hope.

Sorry to all of you who asked for those pages recently...

Wednesday, September 26 2012

Clon 1.0b23 is out

A new version of Clon, the Command-Line Options Nuker is out.

Amongst other things, the following improvements have been made:

  • Support for ABCL has been updated, now that it provides a full MOP.
  • A workaround for SBCL's CC environment variable problem has been implemented. If the variable is not set (required for sb-grovel), Clon now switches to restricted mode instead of aborting.
  • The DUMP macro has been extend to accept a &rest argument that will be passed on to the underlying, implementation-specific, dumping facility.
  • A contrib directory has been added, for storing unapplied patches, suggestions etc.

Grab it at the usual place.

Tuesday, September 25 2012

Declt 1.0b14 is out

I've just released a new version of Declt, my reference manual generator for ASDF systems.

This release containts some improvements based on Sabra Crolleton's feedback. The most notable improvements are support for two new license types (MIT and LGPL), a new :DECLT-NOTICE keyword argument that gives you control on the "automatically generated by Declt" notice that appears in the reference manuals, and a bug fix (missing support for empty lists in lambda-lists).

Grab it at the usual place.

Thursday, July 12 2012

Language wars

Programming languages are tools. Just like hammers. There's nothing personal about them. They just help you build stuff. Yet, there are many religious wars about programming languages out there. Wars which despite being all about science, are much more related to emotions, beliefs and personal aggressions than about objective arguments.

This is funny because do you know of any religious wars about hammers? So what's the difference?

Here's a recent personal example. A guy explaining how the static typing of Common Lisp works (type declarations) and what kind of performance-oriented optimization can be achieved with it (C-like, static but weak typing in SBCL for instance). And then, there's inevitably the troll (whom I know knows better) in the audience who goes:

So, yeah, what you're doing is just C code, and you have to type manually, and it's ugly. So if it's just for writing C code, I don't see the point in using another language.

Hmmm. Let's see. So, yes indeed, static typing in Common Lisp is ugly. And yes, it's not even strong typing. And yes, it would be nicer to have run-time hotspot detection and automatic type-dependant optimization like what's found in some other languages or virtual machines, rather than having to do it by hand (BTW, that would make for a nice Ph.D. I think). But what does that really tell you? That no language is perfect? Wow, thank you very much, that's new. For as much as I think that Lisp The Idea™ is perfect, I don't think anyone ever pretended that Common Lisp (or any Lisp for that matter) was. But is that a reason for not using it at all and sticking to C? Any sane computer scientist knows that the choice of a language doesn't boil down to only one parameter. Any computer scientist who tells otherwise is a troll.

In spite of all its defects, I still have a gazillon reasons to prefer Common Lisp over C, C++, or any language that I know of currently (and this may very well change in the future). The flexibility of lambda lists, the macros, the MOP or more generally its structural and behavioral reflexivity. Its run-time compilation, debugging, introspection and intersession capabilities. These are just a few examples. Still, I don't deny anyone the right to prefer another language for whatever purpose and whatever reasons they may feel legitimate.

So, I normally just ignore those purposedly trollesque and completely idiotic remarks. Yet, sometimes like yesterday, I snap. It gets on my nerves and I become all upset and angry. Why? I never get angry when someone tells me that my hammer is a piece of crap (it's not). I do enough Aikido to know how to control my temper, but for some reason, it doesn't always work when it comes to programming languages. So what is it about them that in spite of all your efforts, you can't help from getting personally and emotionally involved once in a while?

I think the answer becomes apparent when you consider the artistic aspect in programming. When an artist creates a piece (music, theater, dance, painting, architecture, whatever you like), (s)he exposes a very intimate part of himself through his creation. The art "is" the artist, and the artist "is" his art. In doing so, he puts himself in danger. It's like yelling out to the whole world Hey, look, I'm vulnerable right here!!. It's a well know fact that many artists are very fragile, in the sense that they suffer from their creation not being liked. Because a piece of art is intrinsically a piece of the artist himself, when you say I don't like this piece of art, you're actually saying I don't like the artist. Then, it's up to artist to handle the fact of not being liked.

And that's the whole problem, which, as a musician, I know all too well. Where does the artistic fiber come from? It's an urge to express yourself. To express something that you can't express in any other way. A very deep and perpetual wound of some sort, a feeling of not really belonging. More importantly, it's a calling. Sometimes, the simple fact of creating is enough to heal you a bit, but more often, you create in order for your creation to be seen or heard. So yes, it's a calling to the Others. You expect them to answer your call by telling you that they like you (your art, but that is the same). Artists often have this urge to be liked by the Others. So when you dislike some artwork, you're also not liking the artist himself (the part of him that lives in his creation) and you're actually giving him the exact opposite of what he was looking for. And that hurts.

Back to programming languages. Why do we get all emotional about them, and not about hammers? The answer is in fact quite simple. Look at an architectural masterpiece. Do you see the hammer that was used to build it? Now look at a software masterpiece. Do you see the language that was used to write it? That's the crucial difference. You cannot decouple the language from the software, even once it has been written (the art is not in the executable; it's in the source code). The language itself will always be here for you to contemplate.

All in all, I think that's why there will always be language wars. Languages are not just tools, actually. They're not just like hammers. As soon as you care about the code you write, your software becomes artwork, you become an artist, and you start to be personally and emotionally involved. Your software becomes part of you. And contrary to the hammer, your sticky programming language, being intrinsically bound to the artwork, also becomes part of you. That's when the battle for objectivity is lost. By criticizing the language, the troll also criticizes your artwork, and in doing so, he tells you that he doesn't like you. That may hurt.

It's good to consider programming as art. Unfortunately, this also means that there will always be language wars.

Monday, June 4 2012

Declt 1.0b13 is out

I've just released a new version of Declt, my reference manual generator for ASDF systems. This release includes some uninteresting internals update, plus an important bug fix: there were two calls to FIND-METHOD missing an ERRORP flag set to nil, leading to Declt throwing an error where it shouldn't have.

Grab it at the usual place.

Tuesday, May 22 2012

Clon 1.0b22 is out

A new version of Clon, the Command-Line Options Nuker is out.

The most important change in this release is the support for LispWorks, which brings the number of supported implementations to 8. One left to go, and I may eventually switch to RC status. Thanks to Martin Simmons for providing a fully functionnal version of LW 6.1. As for CLISP and Allegro, there is an optional dependency on CFFI for LispWorks.

Two backward incompatible changes that may affect you:

  • Variables renamings: *current-context* has been renamed *context*, and *default-synopsis* has been renamed *synopsis*. This should remain transparent unless you're using Clon in a somewhat advanced way.
  • clon:exit has been upgraded to SBCL's new quitting protocol. If you use this function (or if you want to compile the demo programs), please upgrade to SBCL 1.0.57.

Finally, support for terminal autodetection and stream handling in general has been improved for all implementations.

Grab it at the usual place.

Monday, May 14 2012

Monday Troll: the syntax extension myth

Here's a little Monday Troll.

To my greatest disappointment, I discovered today that it is not possible to replace Lisp parenthesis by, say, ... curly braces. What a shame. Hell, it's not even possible to freely mix the two. Very naively, I had expected that:

(set-macro-character #\{ (get-macro-character #\())
(set-macro-character #\} (get-macro-character #\)))

would suffice, but no. All implementations that I have tested seem to agree on this, although the error messages may differ. For instance, trying to evaluate {and} gives you an "unmatched close parenthesis error" except for CMU-CL which chooses to ignore it, but then report an end-of-file error. The unmatched close parenthesis, of course, is the closing curly brace! So what is going on here?

When an opening curly brace is read, the original left paren macro function is called. In SBCL for instance, this is SB-IMPL::READ-LIST, which looks for a hardwired right paren on the stream. Yuck. It doesn't find one, but it finds my closing brace which triggers the "standalone" right paren behavior (spurious paren alert). In passing, it also surprised me that SB-IMPL::READ-LIST is not implemented in terms of READ-DELIMITED-LIST.

EDIT: as mentioned in several comments, we could use read-delimited-list to look for a closing curly brace, but even this won't work completely. The problem is with dotted lists (see Pascal's comment). SBCL hard-wires #\) in its dotted lists parsing procedures.

So it appears that dispatching macro characters are only shaky. What we miss is a true concept of syntactic categories (Common Lisp character syntax types are close, but not quite there yet). In fact, TeX, with its notion of catcodes (category codes), seems to be the only language that gets this right. Ideally, any character with associated status LIST TERMINATOR should do as good as a right paren (the problem is only with closing, not opening).

Instead of hard-wiring the right paren in the Lisp parser, a quick workaround would be to check whether the next character on the stream is a dispatching one, and in such a case, whether its macro function is the one originally associated with the right paren. If so, it should then simply stand as a list terminator. This is actually an interesting idea I think: could the built-in macro functions become equivalent to actual category codes, and could we completely remove hard-wired characters in Lisp parsers?

Anyway, this whole story is a true scandal because it ruined an otherwise cool live demo of mine. So much for syntax extensibility. I will immediately complain to the concerned authorities.

Looking for the concerned authorities to complain to... please wait.

Monday, March 12 2012

Clon 1.0b21 is out

One year between b19 and b20. 4 days between b20 and b21...

This new version of Clon introduces support for a new compiler, Allegro Common Lisp, in both standard and modern form. Support for dumping is only rudimentary for ACL (although it's only a marginal feature of the library). The dump macro uses Allegro's dumplisp mechanism to dump a lisp image which is not directly executable (full application delivery is complicated and only available in the Enterprise edition). Apart from that, the rest should work fine. As in the case of CLISP, Allegro may benefit from the presence of CFFI in order to provide terminal autodetection. This is an optional dependency only.

Grab it at the usual place.

Thursday, March 8 2012

Clon 1.0b20 is out

I'm happy to announce a new release of Clon, the Command-Line Options Nuker for standalone Common Lisp executables. In addition to a lot of uninteresting code and infrastructure changes, this new release comes with several important improvements and new features.

At the end-user level

  • there is a new error handler available via the --clon-error-handler option, called "interactive". This error handler provides the same restarts as the one called "none" (which actually triggers the Lisp debugger), but in a less frightening way for end-users not knowing about Lisp at all. In particular, the error and restart messages are more readable and you don't see a Lisp stack anywhere. See the end-user manual and the user manual for more information.
  • there is a new option called --clon-lisp-information which, as its name suggests, provides information about the underlying Lisp (implementation type and version). This will in fact be more useful for developers than for end-users, but it's still and end-user level feature. See the end-user manual for not much more information.

At the user-level

  • Clon now provides a command-line polling API through the functions cmdline-options-p and cmdline-p. See the user manual for more information.
  • Support for using Clon interactively, that is, without dumping executables has been improved. This is mostly useful for debugging purposes. See the user manual for more information.
  • Clon now provides a compile-time / run-time unified configuration facility thanks to a variable named cl-user::com.dvlsoft.clon.configuration that is handled before the ASDF system is loaded. Thanks to this, Clon is now able to communicate its own indentation information to (X)Emacs directly (thanks to a process that I've previously described here), and also handles portability problems in a smoother way (see below).
  • One of the available configuration options is called :restricted mode. In this mode, Clon never attempts to communicate with ttys via ioctl calls, at the expense of terminal autodetection (size and highlighting). This is implemented by making a termio ASDF module conditionally loaded in the system definition. There are cases where Clon will switch to restricted mode automatically (e.g. when using CLISP compiled without FFI support). However, some other situations are more problematic, for instance when using SBCL under MinGW, in which case the SB-GROVEL module is available but doesn't work. In such situations, it is necessary to configure Clon explicitely for restricted mode before loading the system. See the user manual for more information.


That's it. Grab it at the usual place. Yesterday, I realized that it's been slightly more than a year since the b19 release. Gee, time flies like the wind...

Monday, February 13 2012

ILC 2012 (International Lisp Conference)

The next ILC has been announced. It's going to take place in my favorite city in the whole world. Here's the original call for papers with all the important deadlines.

+----------------------------------------------------------------------+
|                                                                      |
|                  INTERNATIONAL LISP CONFERENCE 2012                  |
|                                                                      |
|             http://www.international-lisp-conference.org             |
|                                                                      |
|       Campus Plaza Kyoto, Kyoto, Japan -  October 21-24, 2012        |
|                                                                      |
|            Sponsored by:  The Association of Lisp Users              |
|                                                                      |
+----------------------------------------------------------------------+

   General Information:

     The Association of Lisp Users is pleased to announce the 2012
     International Lisp Conference will be held in Kyoto, Japan at
     Campus Plaza Kyoto from October 21st to 24th, 2012.

     This year's program consists of tutorials at beginners' and
     advanced levels, prominent invited speakers from the Lisp
     communities, an excellent technical session, tours of
     Jidai-Matsuri: festival enjoyed by people of all ages,
     participating in its historical reenactment parade dressed in
     authentic costumes representing various periods, and characters
     in Japanese feudal history.

     General conference announcements are made on a very occasional
     basis to the low-volume mailing list
     ilc12-announce. http://www.alu.org/mailman/listinfo/ilc12-announce

   Technical Program:

     Original submissions in all areas related to the conference themes
     are invited for the following categories:

     Papers: Technical papers of up to 15 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 focussed topic for half a day.

     Tutorials: Abstracts of up to 2 pages for indepth presentations
     about topics of special interest for 90 - 180 minutes.

     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.

     Lightning talks: Abstracts of up to one page for talks to last
     for no more than 5 minutes.


   Important Dates:

     Please send contributions before the submission deadline, including
     abstracts of 4 pages for technical papers and abstracts of 2 pages
     for all other categories.

     Deadline for abstract submissions: July 15, 2012
     Notification of acceptance or rejection: July 31, 2012
     Deadline for final paper submissions: August 31, 2012

     Papers to be presented should be submitted electronically at
     easychair 
     (https://www.easychair.org/account/signin.cgi?conf=ilc2012)
     and need to use the ACM format
     (http://www.acm.org/sigs/publications/proceedings-templates)

   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, etc.

    Topics may include any and all combinations of Lisp and:

      * 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
      * Parallel and distributed computing
      * Theorem proving
      * Scientific computing
      * Data mining
      * Semantic web


   Organizing Committee:

     General Chair: KURODA Hisao (Mathematical Systems Inc. / ALU)
     Members: Daniel Herring (ALU)
              Jon L White (ALU)
              Rusty Johnson (ALU)

     Program Chair: Hiroshi Okuno (Kyoto Univ.)
     Members: Keith Corbett (Clozure Associates)
              Alex Fukunaga (University of Tokyo)
              Antonio Leitao (INESC-ID)
              Joe Marshall (MIT)
              Scott Mckay (ITA software)
              Nancy Reed (University of Hawaii)
              Kent Pitman (nhplace.com)
              Duane Rettig (Franz Inc.)
              Didier Verna (EPITA)
              Takuo Watanabe (Tokyo Institute of Technology)
              Edi Weitz (weitz.de)
              Taiichi Yuasa (Kyoto University)

     Local chair: Tetsuya Ogata (Kyoto Univ.)
     Members: CHIBA Masaomi
              SANO Masatoshi

  Contacts:

    * General Questions: ilc12-organizing-committee at alu.org
    * Program Committee: ilc2012 at easychair.org

For more information, see http://www.international-lisp-conference.org

Monday, November 28 2011

CL-RCFiles 2.0

Just a quick note to mention the release of CL-RCFiles 2.0. This version adds pre-loading initialization files. From the README file:

This very small Common Lisp library provides a way to add initialization files to ASDF systems. Every time ASDF loads <system>, one or several corresponding <system>.lisp files are loaded automatically afterwards. This lets you conditionally plug in additional behavior on a per-system basis without cluttering up any global Common Lisp init file.

By default, these initialization files are expected to be found in: - ~/share/common-lisp/rc/pre/ for pre-loading initialization, - ~/share/common-lisp/rc/post/ for post-loading initialization.

For backward-compatibility, files found directly in the rc/ directory are considered to be post-loading initialization files.

You can modify the rc-files location by changing the values of the global variables *directory*, *pre-directory*, and *post-directory*.

Get it here.

Tuesday, October 25 2011

ILC 2012

The ALU has announced the next International Lisp Conference. ILC 2012 will take place at the end of October or Early November. I can't wait to meet the international Lisp crowd again, and what's more, in Kyoto, my favorite city in the world! I think I will take the opportunity to buy a new Hakama there. Maybe a Noren or two as well...

In the meantime, stay tuned for the next European Lisp Symposium, to occur in Zadar (Croatia) sometime around end April / early May 2012 !

John McCarthy died last night

John McCarthy John McCarthy, the creator of the most elegant and powerful language ever, has died. I won't repeat what others in the Lisp community are and will be saying all over the place in the next few days. There is only one thing I would like to say right now: I remember him, and I am very happy (for him) that he was still here with us to celebrate the 50th anniversary of his wonderful baby...

 

Wednesday, July 20 2011

One more indentation hack

Here's yet another indentation hack that I came up with recently.

All the work done by Nikodemus on the Slime indentation contrib is pretty cool, especially the notion of indentation style (though I wish the styles were Custom variables, but that is another story). I tend to use indentation styles for global, maybe collaborative preferences, but on several occasions however, I find that this approach has a couple of drawbacks.

  • One of them is that the indentation information is far away from the corresponding symbol, in a separate file. If you change a function's prototype for instance, you may also need to load the file(s) in which the corresponding style(s) is (are) defined and edit them.
  • The other problem is that if you want to let other people edit your source code and honor your indentation style, you also need to provide them with the style definition, and they need to load it separately.

For those reasons, I tend to think that the indentation style approach is not very well suited for project-specific indentation settings. What I would like is to provide indentation information close to the function definition, and also to have that information automatically available when anyone loads the project into Slime. Here's a way to do it.

The key to success here is the function swank:eval-in-emacs which, as its name suggests, sends some Emacs Lisp code to your (X)Emacs session for evaluation. This function effectively allows you to trigger some Emacs Lisp computation from a Common Lisp file. Remember that indentation information is stored in the common-lisp-indent-function property of a symbol. The function clindent below does this:

(defun clindent (symbol indent)
  "Set SYMBOL's indentation to INDENT in (X)Emacs.
This function sets SYMBOL's common-lisp-indent-function property.
If INDENT is a symbol, use its indentation definition.
Otherwise, INDENT is considered as an indentation definition."
  (when (and (member :swank *features*)
	     (let ((configuration
		     (find-symbol "MY.PACKAGE.CONFIGURATION" :cl-user)))
	       (when (and configuration (boundp configuration))
		 (getf (symbol-value configuration) :swank-eval-in-emacs))))
    (funcall (intern "EVAL-IN-EMACS" :swank)
	     `(put ',symbol 'common-lisp-indent-function
		   ,(if (symbolp indent)
			`(get ',indent 'common-lisp-indent-function)
		      `',indent))
	     t)))

As explained in the docstring, this function will ask (X)Emacs to put SYMBOL's common-lisp-indent-function property to a definition, either provided directly, or retrieved from another symbol. For example, if your package defines an econd macro, you may want to call it like this:

(clindent 'econd 'cond)

This function ensures that Swank is actually available before using it (first condition in the and clause). I will explain the other weird bits later on.

The next question is when exactly do we want to call this function? The answer is: pretty much on all occasions. Your code might be loaded from source and interpreted, or it might be compiled. But then, it might be compiled within or outside a Slime environment. In any case, you want your indentation information to be sent to (X)Emacs everytime it's possible. So obviously, we're gonna wrap this function in an eval-when form thanks to a macro. This is also a good opportunity to save some quoting.

(defmacro defindent (symbol indent)
  "Set SYMBOL's indentation to INDENT in (X)Emacs.
SYMBOL and INDENT need not be quoted.
See CLINDENT for more information."
  `(eval-when (:compile-toplevel :execute :load-toplevel)
     (clindent ',symbol ',indent)))

And now, right on top of your econd definition, you can just say this:

(defindent econd cond)

Now here's one final step. If your package uses its own readtable, it's even more convenient to define a reader-macro for indentation information. I choose #i:

(defun i-reader (stream subchar arg)
  "Read an argument list for the DEFINDENT macro."
  (declare (ignore subchar arg))
  (cons 'defindent (read stream)))
 
(set-dispatch-macro-character #\# #\i #'i-reader *readtable*)

And now, the code in my package will look like this:

#i(econd cond)
(defmacro econd #|...|#)

Pretty cool, eh?

All right. We still have two weirdos to explain in the clindent function.

First, you noticed that the function's computation is conditionalized on the existence of a cl-user::my.package.configuration variable, which actually stores a property list of various compiling or loading options for this package. The option we're interested in is :swank-eval-in-emacs, which must be set to non-nil. Here's why. The execution of Emacs Lisp code from Swank is (rightfully) considered as a security risk so it is disabled by default. If you want to authorize that, you need to set the (Emacs) variable slime-enable-evaluate-in-emacs to t. Otherwise, calling swank:evaluate-in-emacs is like calling 911. So we have a chicken-and-egg problem here: if we want to avoid an error in clindent, we would need to check the value of this variable, but in order to do that, we would need to evaluate something in (X)Emacs ;-)

The solution I choose is hence to disable the functionality by default, and document the fact that if people want to use my indentation information, they need to set both the Slime variable and my package-specific option to non-nil before loading the package (possibly setting them back to nil afterwards). They also need to trust that I'm not going to inject anything suspicious into their (X)Emacs session at the same time...

The last bit we need to explain is the final t argument passed to swank:eval-in-emacs. The corresponding parameter is called nowait in the function's prototype. It has something to do with asynchronous computation, and in fact, I don't really know what's going on under the hood, but what I do know is that if you set it to t, Swank doesn't care about the return value of your form anymore, which is fine because we're only doing a side effect. On the other hand, if you omit that parameter, Swank will try to interpret the return value in some way, and you will most probably get a serialization error. Indeed, the return value is the indentation definition itself, so for example, (&rest (&whole 2 &rest 1)) doesn't make (Common Lisp) sense.

That's it. Happy indenting!

- page 3 of 6 -

French Flag English Flag
Copyright (C) 2008 -- 2018 Didier Verna didier@lrde.epita.fr