We're happy to announce that the next European Lisp Symposium will be held at the AGH University of Science and Technology in Kraków, Poland, on May 9-10. Stay tuned for updates, upcoming CfP, invited speakers and lots of good stuff!
|Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff.|
Monday, October 5 2015
We're happy to announce that the next European Lisp Symposium will be held at the AGH University of Science and Technology in Kraków, Poland, on May 9-10. Stay tuned for updates, upcoming CfP, invited speakers and lots of good stuff!
Wednesday, August 5 2015
I was watching the discussion between Gilad Bracha and Matthias Felleisen on gradual typing this afternoon (it's available on YouTube). This was the last event at the STOP workshop, part of ECOOP 2015 in Prague. I couldn't attend it because I was somewhere else (Curry On) at the time. The discussion is interesting, but if you go all the way, in the last 10 minutes or so, you will notice that Matthias seems to be completely obsessed with what he calls the "Return of the SegFaults".
Basically, the point is the following. Mathias dislikes the optional types in Common Lisp because it's opening the door to unsafety. Initially, any dynamic language has a sound type system (all type errors are caught; at run-time, yes, but they are caught). As soon as you introduce an optional type system ala Lisp, the compiler implementors are "pushed" to use the provided type information for optimization, hence weakening the type system and breaking soundness. It's the "return of segfauts".
Of course, I agree with that, at least on the principle. Yes, Common Lisp's weak, optional type system is an antiquated thing. However, it seems to me that Matthias is forgetting two important things on the practical level:
(defun plus (a b) (+ a b))works on every possible numerical value, but add
(declare (type fixnum a b))in there and it will suddenly stop working on anything else but integers. It's only if you require the compiler to optimize for
speedat the expense of
safetythat you effectively weaken your type system.
So my impression is that Matthias is largely exaggerating the problem, but I'm not really qualified to tell. That's why I would like to know from you guys, working with Lisp in the industry, writing large applications, lots of type annotations, and
(declaim (optimize (speed 3) (safety 0) (debug 0)) (EDIT: that's exaggerated of course, I really mean breaking safety for performance reasons): how much of a problem the "return of the segfaults" really is in practice ?
As a side note, this reminds me of the dynamic vs. lexical scoping debate. Many people were and still are strongly opinionated against dynamic scoping by default. Of course, I too, at least in principle. But how dangerous dynamic scoping really is in practice (EDIT: I'm not talking about expressiveness, e.g. closures, here. Only unsafety.)? What I can tell you is that in the 15 years I was actively maintaining the XEmacs codebase, I may have run into name clashes due to dynamic scoping... twice.
Monday, July 13 2015
Declt 2.0 "Kathryn Janeway" is out. This release doesn't contain any change in functionality, yet deserves a major version upgrade since it contains 3 important changes: an infrastructure revamp (along the lines of what Clon endured not so long ago), a license switch from the GNU GPL to a BSD one, and finally a system / package name change. The prefix is now
net.didierverna instead of
com.dvlsoft. Do I need to apologize for this again? :-)
Find it at the usual place...
Monday, June 29 2015
as promised last week, I've just released a new version of Declt, my reference manual generator for ASDF systems. This new version (1.1) is now able to document Clon again (the documentation of which has been updated on the website).
New in this release:
But the most important addition is the ability to document several ASDF systems in the same reference manual. More precisely, Declt now documents not only the main system but also all its subsystems. A subsystem is defined as a system on which the main one depends on in any way, and which is also part of the same distribution (under the same directory tree). Declt also understands multiple system definitions from the same
Thursday, June 25 2015
I'm happy to announce the release of the next beta version of Clon, the Common Lisp / Command Line Options Nuker library. This release doesn't contain much change in terms of functionality, but it contains a lot of change in terms of infrastructure, plus very important and backward-incompatible modifications. So if you're a Clon user, please read on.
First of all, a huge revamp of the library's infrastructure (package hierarchy, ASDF and Make implementations) occurred. A large portion of this work is actually not mine, but Fare's (big thanks to him, 'cause the level of ASDF expertise required just means that I couldn't have done that by myself). The purpose here was twofold: first, remove all logic from the ASDF files (so that other system managers could be used; not sure that's actually useful right now) and second, split the library in two: the core, basic functionality and the non-standard platform-dependent bells and whistles (read: termio support). The result is that Clon now comes with 4 different ASDF systems! A setup system allows you to configure some stuff prior to loading the library, a core system allows you to load only the basic functionality and the regular one loads everything, autodetecting platform-dependent features as before. The fourth system is auxiliary and not to be used by hand. All of this is properly documented. For a code maniac like me, this new infrastructure is much more satisfactory, and I've learned a lot about ASDF less known features.
Next, I've moved the repository to Github. Please update your links! It seems that I've lost all my former tags in the process, but oh well...Only the Git repo has moved. The main Clon web page still contains the full history of tarballs, the preformatted documentation, and will continue to do so in the future.
Finally (I've kept this to myself until the last possible minute because I'm scared like hell to tell): I've changed the systems and packages names... The
com.dvlsoft prefix has been replaced with
net.didierverna. All other libraries of mine will eventually endure the same surgery. It's for the best, I apologize for it and I swear I will never ever do that again, EVER (fingers crossed behind my back).
So what's next? Before considering an official 1.0 release, there are two things that I want to do. First, cleanup some remaining Fixmes and some shaky error handling. Second, provide an even simpler way of using Clon than what the Quick Start chapter in the doc demonstrates. The idea is to just implement a
main function with keyword arguments, and those argument magically become command-line options.
A side-effect of this work is that Declt now chokes on Clon, because some ASDF features that it doesn't understand are in use. So Declt has a couple of new challenges ahead, and you should expect a new release in the weeks to come.
Tuesday, May 19 2015
Monday, January 19 2015
The programme committee members for this year's European Lisp Symposium has just been announced. Ladies and gentlemen, please welcome, on the keyboards...
Wednesday, January 14 2015
Reported to me by Craig Norvell: Haystax appears to have some interesting Lisp projects in the works. Combining Lisp, Prolog, RDF (AllegroGraph), and a BBN for insider threat detection solutions.
From their website:
Haystax's predictive models are continuously updated based on the prevailing threat environment making it highly suitable for both detection and continuous evaluation of threats. These unique models go beyond traditional web and business intelligence to enable organizations to achieve contextual real-time situational awareness by fusing all operationally relevant information - private, public, video and live feeds - into consolidated views to show patterns and identify threats that are usually buried in too much noise or not placed in proper context.
Friday, December 5 2014
ELS'15 - 8th European Lisp Symposium Goldsmiths College, London, UK April 20-21, 2015 http://www.european-lisp-symposium.org/ Sponsored by EPITA, Franz Inc. and Lispworks Ltd. The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 8th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - 22 Feb 2015: Submission deadline - 15 Mar 2015: Notification of acceptance - 29 Mar 2015: Early registration deadline - 05 Apr 2015: Final papers - 20-21 Apr 2015: Symposium Programme chair: Julian Padget, University of Bath, UK Local chair: Christophe Rhodes, Goldsmiths, University of London, UK Programme committee: To be announced Search Keywords: #els2015, ELS 2015, ELS '15, European Lisp Symposium 2015, European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium, European Lisp Conference 2015, European Lisp Conference '15
Tuesday, January 21 2014
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!
Tuesday, January 7 2014
The preliminary Programme Committee for the next European Lisp Symposium has just been selected! We have a nice team coming in hot... See http://www.european-lisp-symposium.org/content-organization-full.html.
Wednesday, December 18 2013
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
Saturday, November 30 2013
ELS 2014 is finally settled. I have the pleasure to welcome Kent Pitman as the Programme Chair, and Gérard Assayag as a co Local Chair ! The symposium is going to be held at IRCAM, a French institute for research on music and acoustics, so I hope there's going to be a lot of Lisp & music talks!
ELS'14 - 7th European Lisp Symposium IRCAM, Paris, France May 5-6, 2014 http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 7th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Please note that IRCAM, the conference venue, is a French institute for research on music and acoustics. Submissions relating Lisp to music or other acoustical matters will hence be particularly welcome, although given no heightened favor during the review process. We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - TODAY: Mark your calendar. Start planning now! - 09 Mar 2014: Submission deadline - 31 Mar 2014: Notification of acceptance - 21 Apr 2014: Final Papers due - 05 May 2014: Symposium. Join us there! Program Committee: Chair: Kent Pitman, Hypermeta Inc., U.S.A. Local Organizers: Didier Verna, EPITA Research Lab, France Gérard Assayag, IRCAM, France Members: To be announced later Search Keywords: #els2014, ELS 2014, ELS '14, European Lisp Symposium 2014, European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium, European Lisp Conference 2014, European Lisp Conference '14 Ircam STMS Lab, IRCAM / CNRS / UPMC
Tuesday, November 12 2013
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:
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!
Monday, September 23 2013
I am thrilled to announce that I will be a keynote speaker at the next ACCU conference. The abstract of my keynote is given below. Looking forward to see you there!
In biology, evolution is usually seen as a tinkering process, different from what an engineer does when he plans the development of his systems. Recently, studies have shown that even in biology, there is a part of good engineering. As computer scientists, we have much more difficulty to admit that there is also a great deal of tinkering in what we do, and that our software systems behave more and more like biological realms every day.
This keynote will take you to a journey through the bonds between biology and computer science. Starting with an epistemological and historical view, we will see how these bonds developed over the years, but we will also ask ourselves whether these bonds were intentionally created, or whether they already existed, before we even found them. We will also meet the Engineer and the Tinkerer, and see that they are not necessarily different persons. Finally, through such notions as Determinism, Predictability and Control, we will envision and explain a possible future for our software systems seen as living organisms; a future that's in fact already here, but that we are reluctant to accept.
Tuesday, September 3 2013
EDIT: 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-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:
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...
Saturday, August 24 2013
After 15 betas, I'm happy enough with the current state of Declt to finally make a 1.0 release.
A lot of things have changed since the previous version, sometimes in a backward-incompatible way. Many more items are documented (including, as you have recently seen, method combinations). In addition to the reference manual, generated by Declt itself, there is now a real user manual.
Declt is still SBCL-only, requires ASDF 3 and Texinfo 4 but generates code that is compatible with Texinfo 5. Also, beware, I've deleted the old repository and moved the project to GitHub. Below is a more precise description of what Declt currently does.
Declt (pronounce "dec'let") is a reference manual generator for Common Lisp libraries. It works by loading an ASDF system and introspecting its contents. The generated documentation contains the description for the system itself and its components (modules and files), the packages defined in that system and the definitions found in those packages.
Exported and internal definitions are listed separately. This allows the reader to have a quick view on the library's public API. Within each section, definitions are sorted lexicographically.
In addition to ASDF system components and packages, Declt documents the following definitions: constants, special variables, symbol macros, macros, setf expanders, compiler macros, functions (including setf ones), generic functions and methods (including setf ones), method combinations, conditions, structures, classes and types.
The generated documentation includes every possible bit of information that introspecting can provide: documentation strings, lambda lists (including qualifiers and specializers where appropriate), slots (including type, allocation and initialization arguments), definition source file etc.
Every documented item provides a full set of cross-references to related items: ASDF component dependencies, parents and children, classes direct methods, super and subclasses, slot readers and writers, setf expanders access and update functions etc.
Finally, Declt produces exhaustive and multiple-entry indexes for every documented item.
Reference manuals are generated in Texinfo format (compatible, but not requiring Texinfo 5). From there it is possible to produce readable / printable output in info, HTML, PDF, DVI and PostScript with tools such as makeinfo, texi2dvi or texi2pdf.
The Declt reference manual is the primary example of documentation generated by Declt itself.
Friday, August 16 2013
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...
Tuesday, July 16 2013
I have just compiled the proceedings for ELS 2013, the 6th European Lisp Symposium. I have also asked Manuel and Nick to add them to their respective pages, the official ELS 2013 page and the audio recordings page.
Thanks to both of them for their support !
Wednesday, June 26 2013
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.
« previous entries - page 1 of 7