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.

mardi, mai 14 2013

Emacs session bootstrap tweaks

This article essentially describes the top of my Emacs init file. That part of the code is devoted to modify the session bootstrap process, that is, some things that are normally done very early. It mostly deals with the package infrastructure but also contains a couple of other tricks that some people may consider useful. It goes like this…

The first line is self-explanatory (and please, be warned that I will discard any comment about it. You know why).

(require 'cl)

Platform-specific tweaks

A self-contained Emacs.app on MacOS X has its own site-lisp directory, but I want to make sure that the standard Unix one is here as well, and takes precedence.

(when (featurep 'ns)
  (add-to-list 'load-path "/usr/local/share/emacs/site-lisp"))

When not starting Emacs from the command-line (e.g. MacOS X app clicks or Quicksilver, Unitiy launcher on Ubuntu etc.), I don't necessarily get my environment-based exec-path so I need to restore it. Note that this trick works because the standard value is (I think) computed when Emacs is built, and I happen to build it myself, in my own environment.

(let ((standard-exec-path (cadar (get 'exec-path 'standard-value))))
  (mapc (lambda (path) (setq exec-path (remove path exec-path)))
            standard-exec-path)
  (setq exec-path (append standard-exec-path exec-path)))

ELPA infrastructure

Initialize ELPA now so that the rest of the initialization process may rely on packages without having to go through after-init-hook.

(require 'package)

I want system-wide directories to be named emacs-packages instead of site-lisp/elpa.

(setq package-directory-list
      (let (result)
        (dolist (path load-path)
          (and (stringp path)
                 (equal (file-name-nondirectory path) "site-lisp")
                 (push (expand-file-name "emacs-packages"
                                                     (file-name-directory
                                                       (directory-file-name path)))
                          result)))
	(nreverse result)))

I want my local directory to follow the same convention.

(setq package-user-dir "~/.emacs.d/emacs-packages")

Now, it's okay to initialize ELPA.

(package-initialize)

Now that the packages have been initialized, I actually want ELPA to install in /usr/local/share/emacs/emacs-packages by default, and keep my local directory for manual installations. One simple way to achieve that is to set my local directory to /usr/local/share/emacs/emacs-packages and to remove that from the system-wide directory list. One small drawback of this is that my local path is gone, so any new package installed there won't be seen until the next restart. This is not much of a problem though.

(setq package-user-dir "/usr/local/share/emacs/emacs-packages"
        package-directory-list (remove "/usr/local/share/emacs/emacs-packages"
				                     package-directory-list))

Site and local (non ELPA) packages infrastructure

The purpose of this other infrastructure is to support packages that would be installed manually, outside ELPA, and in a way similar to XEmacs packages. A packages directory has lisp/, etc/ and info/ subdirectories. Every package installs its stuff directly in etc/ and info/, but adds its own subdirectory to lisp/ and puts its code (including a potential autoloads file) in there.

This additional infrastructure comes in handy in several situations. For instance, having Slime (auto)loaded in your session now becomes as simple as this:

ln -s /path/to/slime /usr/local/share/emacs/local-packages/lisp/

(defun dvl-initialize-packages (directory)
  "Initialize non-ELPA packages DIRECTORY.
This means:
  - adding the whole lisp/ subtree to LOAD-PATH,
  - loading the autoload files found there.
  - adding DIRECTORY to INFO-DEFAULT-DIRECTORY-LIST."
  (let ((default-directory (expand-file-name "lisp" directory)))
    ;; 1. Update LOAD-PATH
    (setq load-path
	  (append
	   (let ((load-path (copy-sequence load-path)))
	     (append (copy-sequence (normal-top-level-add-to-load-path '(".")))
		          (normal-top-level-add-subdirs-to-load-path)))
	   load-path))
    ;; 2. Load autoload files
    (loop for directory in load-path
	    while (string-prefix-p default-directory directory)
	    do (mapc #'load (directory-files directory t "-autoloads\\.el$"))))
  ;; 3. Update the default Info directory list
  (add-to-list 'Info-default-directory-list
   (expand-file-name "info" directory)))
 
(require 'info)

Be sure to do this by increasing priority order.

(mapc #'dvl-initialize-packages
      `("/usr/local/share/emacs/local-packages"
	 "~/.emacs.d/local-packages"))

And now we can re-initialize Info with the proper defaults.

(setq Info-directory-list nil)
(info-initialize)

Custom settings

Now that we have bootstrapped the complete packages infrastructure, we can set the Custom file to something that makes sense and load it now.

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

That completes my session bootstrap process.

So long, TweetDeck

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.

mardi, avril 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...

lundi, avril 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 !

dimanche, mars 24 2013

COP'13 - 5th international workshop on context-oriented programming

			   Call for Papers

				COP'13
     Fifth International Workshop on Context-Oriented Programming
      Worokshop in conjunction with ECOOP, ECMFA, and ECSA 2013
		 Montpellier, France, July 2nd, 2013

	       http://www.fos.kuis.kyoto-u.ac.jp/COP13/
	  https://www.easychair.org/conferences/?conf=cop13

Overview
--------

Context information plays an increasingly important role in our
information-centric world. Software systems must adapt to changing
contexts over time, and must change even while they are
running. Unfortunately, mainstream programming languages and
development environments do not support this kind of dynamic change
very well, leading developers to implement complex designs to
anticipate various dimensions of variability. Starting from this
observation, Context-Oriented Programming (COP) has emerged as a
solution to directly support variability depending on a wide range of
dynamic attributes, making it possible to dispatch run-time behaviour
on any property of the execution context.

The goal of the 5th International Workshop on Context-Oriented
Programming (COP’13) is to further establish context orientation as a
common thread to language design, application development, and system
support. Several researchers are working on Context-Oriented
Programming and related ideas, and implementations ranging from
prototypes to mature platform extensions used in commercial
deployments have illustrated how multi-dimensional dispatch can indeed
be supported effectively to achieve expressive run-time behavioural
variations.

Topics of interest include but are not limited to:

- Interesting application domains and scenarios
- Programming language abstractions for context-oriented programming
  (e.g. dynamic scoping, roles, traits, prototype-based extensions)
- Theoretical foundations for context-oriented programming (e.g.,
  semantics, type systems)
- Configuration languages (e.g. feature description interpreters,
  transformational approaches)
- Interaction between non-functional programming concerns and
  context-oriented programming (e.g. security, persistence,
  concurrency, distribution)
- Modularization approaches for context-oriented programming
  (e.g. aspects, modules, layers, plugins)
- Guidelines to include context-oriented programming in programs
  (e.g. best practices, patterns)
- Runtime support for context-oriented programming (e.g. reflection,
  dynamic binding)
- Tool support


Important dates
---------------

 * Paper submission:   April 19, 2013
 * Notification:       May 8, 2013
 * Final papers due:   May 22, 2013 (to be confirmed)
 * Early registration: May 31, 2013


Submission guidelines
---------------------

COP invites submissions of high-quality papers reporting original
research, or describing innovative contributions to, or experience
with context-oriented programming, its implementation, and
application. Papers that depart significantly from established ideas
and practices are particularly welcome.  Submissions must not have
been published previously and must not be under review for any another
refereed event or publication. The program committee will evaluate
each contributed paper based on its relevance, significance, clarity,
and originality.  

It is planned to publish accepted papers in the ACM Digital Library,
unless the authors choose not to. In case of publication in the ACM
Digital Library, authors must transfer copyright to ACM upon
acceptance (for government work, to the extent transferable), but
retain various rights (see ACM Copyright Policy. Authors are
encouraged to publish auxiliary material with their paper (source
code, test data, etc.); they retain copyright of auxiliary material.

Papers should be submitted electronically via EasyChair (URL TBA) in
PDF format.  Submissions must be written in English (the official
language of the workshop) and must not exceed 6 pages. They should use
the ACM SIGPLAN 10 point format, templates for which are available at
http://www.acm.org/sigs/sigplan/authorInformation.htm


Program Committee
-----------------

  Tomoyuki Aotani, Japan Advanced Institute of Science and Technology, Japan
  Pascal Costanza, Intel, USA
  Carl Friedrich Bolz, Heinrich-Heine-Universität Düsseldorf, Germany
  Sebastián González, UCLouvain, Belgium
  Atsushi Igarashi (Chair), Kyoto University, Japan
  David Lorenz, Open University of Israel, Israel
  Didier Verna, EPITA Research and Development Laboratory (LRDE), France


Organising committee
--------------------

  Malte Appeltauer, SAP Innovation Center, Germany
  Sebastián González, UCLouvain, Belgium
  Robert Hirschfeld, Hasso-Plattner-Institut, Germany
  Atsushi Igarashi, Kyoto University, Japan (primary contact)
  Hidehiko Masuhara, University of Tokyo, Japan


More information
----------------

See the workshop website at 
http://www.fos.kuis.kyoto-u.ac.jp/COP13/ 

mardi, février 26 2013

Dyla'13, 7th Workshop on Dynamic Languages and Applications

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

lundi, janvier 28 2013

FiXme 4.2 is out

I'm pleased to announce that, after more than two years, I've managed to put up a very small release of FiXme (my collaborative annotations tool for LaTeX2e) in which I didn't even author the two included changes...

Keep the faith. FiXme is still alive !

New in this veresion (4.2):

** Improve Danish translation
thanks to Lars Madsen.
** Fix buglet in redefinition of \@wrindex
reported by Norman Gray.

Get it at the usual place.

dimanche, décembre 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...

mardi, octobre 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...

mercredi, septembre 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.

mardi, septembre 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.

jeudi, juillet 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.

lundi, juin 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.

mardi, mai 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.

Call for Papers: ACM SAC'13 PL: ACM Symposium on Applied Computing, Programming Languages track

CALL FOR PAPERS

SAC'13 - ACM 2013 SYMPOSIUM ON APPLIED COMPUTING
Technical Track on "Programming Languages"
March 18-22, 2013
Coimbra, Portugal


SAC '13
Over the past 27 years, the ACM Symposium on Applied Computing has become a
primary forum for applied computer scientists,
computer engineers, software engineers, and application developers from around
the world to interact and present their work.
SAC 2013 is sponsored by the ACM Special Interest Group on Applied Computing
(SIGAPP). For additional information, please
check the SAC web page: http://www.acm.org/conferences/sac/sac2013/. This
document is also available at:
http://www.cse.unt.edu/~bryant/sac2013/PL-SAC13-CFP.pdf

PROGRAMMING LANGUAGES (PL) TRACK

A technical track on Programming Languages will be held at SAC'13. It will be
a forum for engineers, researchers and practitioners throughout the world to
share technical ideas and experiences relating to implementation and
application of programming languages. Original papers and experience reports
are invited in all areas of programming languages. Major topics of interest
include but are not limited to the following:
− Compiling Techniques,
− Domain-Specific Languages,
− Formal Semantics and Syntax,
− Garbage Collection,
− Language Design and Implementation,
− Languages for Modeling,
− Model-Driven Development and Model Transformation,
− New Programming Language Ideas and Concepts,
− New Programming Paradigms,
− Practical Experiences with Programming Languages,
− Program Analysis and Verification,
− Program Generation and Transformation,
− Programming Languages from All Paradigms (Agent-Oriented, Aspect-Oriented,
Functional, Logic, Object-Oriented, etc.),
− Visual Programming Languages.

GUIDELINES FOR SUBMISSION

Paper submissions must be original, unpublished work. Submissions should be in
electronic format, via the START site:
https://www.softconf.com/c/sac2013/.
Author(s) name(s) and address(es) must not appear in the body of the paper,
and self-reference should be avoided and made
in the third person. Submitted papers will undergo a blind review process. 
Authors of accepted papers should submit an
editorial revision of their papers that fits within six two-column pages (an
extra two pages, to a total of eight pages,
may be available at a charge). Please comply with this page limitation already
at submission time. For accepted papers,
registration for the conference is required and allows accepted papers to be
printed in the conference proceedings.
For each accepted paper, an author or a proxy attending SAC MUST present the
paper. This is a requirement for the paper
to be included in the ACM/IEEE digital library. A set of selected papers,
which did not get accepted as full papers,
will be accepted as poster papers and will be published as extended 2-page
abstracts in the symposium proceedings.
After the conference, selected accepted papers will be invited to a special
issue of the Computer Languages, Systems and
Structures journal
(http://www.journals.elsevier.com/computer-languages-systems-and-structures/).

IMPORTANT DATES
September 21, 2012: Full Paper Submissions
November 10, 2012: Author Notification
November 30, 2012: Camera-Ready Copy

The SAC 2013 Programming Language Track Program Committee Members
Vasco Amaral, Universidade Nova de Lisboa, Portugal
Roberto da Silva Bigonha, Universidade Federal de Minas Gerais, Brasil
Haiming Chen, Chinese Academy of Sciences, China
Johan Fabry, University of Chile, Chile
Sebastian Guenter, Vrije Universiteit Brussel, Belgium
Gopal Gupta, University of Texas at Dallas, USA
Christian Haack, University of Nijmegen, The Netherlands
Christian Hammer, Saarland University, Germany
Matthias Hauswirth, University of Lugano, Switzerland
Pedro Henriques, University of Minho, Portugal
Michael Hind, IBM, USA
Nigel Horspool, University of Victoria, Canada
Zoltan Horvath, Eotvos Lorand University, Hungary
Bo Huang, Intel, China
Geylani Kardas, Ege University, Turkey
Shih Hsi "Alex" Liu, California State University, Fresno, USA
Hanspeter Moessenboeck, Johannes Kepler Universitat Linz, Austria
Jesús García Molina, University of Murcia, Spain
Nikolaos Papaspyrou, National Technical University of Athens, Greece
Corneliu Popeea, Technical University of Munich, Germany
Andre Santos, Universidade Federal de Pernambuco, Brazil
Bostjan Slivnik, University of Ljubljana, Slovenia
Didier Verna, EPITA, France
Wuu Yang, National Chiao-Tung University, Taiwan
Youtao Zhang, University of Pittsburgh, USA

Track Chairs
Marjan Mernik, University of Maribor, Slovenia, marjan.mernik@uni-mb.si
Barrett Bryant, University of North Texas, USA, Barrett.Bryant@unt.edu

lundi, mai 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.

mercredi, mars 21 2012

Star TeX, the Next Generation

I'm happy to announce that my contribution to TUG 2012, the next TeX Users Group International conference, has been accepted. Please find the title and abstract below.



Star TeX, the Next Generation

In 2010, I asked Donald Knuth why he chose to design and implement TeX as a macro-expansion system (as opposed to more traditional procedure calls). His answer was that:

  1. he wanted something relatively simple for his secretary who was not a computer scientist,
  2. the very limited computing resources at that time practically mandated the use of something much lighter than a true programming language.

The first part of the answer left me with a slight feeling of skepticism. It remains to be seen that TeX is simple to use, and when or where it is, its underlying implementation has hardly anything to do with it.

The second part of the answer, on the other hand, was both very convincing and arguably now obsolete as well. Time has passed and the situation today is very different from what it was 50 years ago. The available computing power has grown exponentially, and so has our overall skills in language design and implementation.

Several ideas on how to modernize TeX already exist. Some have been actually implemented. In this talk, I will present mine. Interestingly enough, it seems to me that modernizing TeX can start with grounding it in an old yet very modern programming language: Common Lisp. I will present the key features that make this language particularly well suited to the task, emphasizing on points such as extensibility, scriptability and multi-paradigm programming. The presentation will include reflections about the software engineering aspects (internals), as well as about the surface layer of TeX itself. Most notably, I will explore the possibilities of providing a more consistent syntax to the TeX API, while maintaining backward compatibility with the existing code base.

lundi, mars 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.

jeudi, mars 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...

- page 1 de 6

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