The organizers of this year’s European Lisp Symposium made available all the videos of the talks with the respective slides, as well as the PDF containing all the accepted papers.
This is really great and everyone involved in making this happening should be congratulated! For everyone that didn’t attend (like me) it’s a good opportunity to see what happened at ELS. Even though the talks, discussions and networking between participants is the most valuable thing while attending a conference, this is very nice for everyone who was not able to be there.
Once again, kudos to the organizers!
Recently I was doing some data processing and since it fit nicely in a parallel setup, I changed my pipeline to use the Array.Parallel module. An easy and simple change that can speed up your task especially if it’s time consuming.
Nonetheless, I also needed Array.filter and to my surprise it wasn’t available in the Parallel module. After some searching, I realized that perhaps the common way to do what I wanted was to use the PSet module (see for example here).
However, I found this nice little example in F# Snippets. In short, a very simple extension of the Parallel module is done to include the filter operation and then it can be used like all others. The relevant code is summarized below:
To me this shows the elegance of F# in two simple aspects: 1) we are able to extended quite easily a standard module; 2) The use of Options. Initially, one could think that special care would be necessary to handle the case where no results are returned from collect. Using Some and None not only makes the coder shorter but also easy to understand and rather elegant.
I was looking for examples of Lisp implementations using F# and found these 3 interesting series of blog posts. You can find other posts about implementing Lisp or Scheme using F# but these were the ones I found more comprehensive and different enough to compare different implementations. Although these Lisp implementations are learning experiments and not for production use, it’s fun to see how they are implemented. The series are the following ones:
Tim Robinson’s Lisp Compiler in F#:
- Parsing with fslex and fsyacc
- Expression trees and .NET methods
- What’s next?
Ashley Nathan Feniello’s FScheme series:
- Scheme in F#
- Just ‘let’ Me Be Already!
- Lambda the Ultimate!
- Rinse and Recurse
- What ‘letrec’ Can’t Do
- What’s Lisp Without Lists?!
- No Wait, Macro the Ultimate!
- Oh, The Humanity!
- Language vs. Library
- Turning Your Brain Inside Out with Continuations
- Playing Dice with the Universe
- Functional I/O (or at least “O”)
- Functional I/O (including “I” this time)
- Functional I/O (Historical Debugging)
Luca Bolognese’s Write Yourself a Scheme in 48 Hours in F#:
Last December I decided to start to learn properly F#. Before that I only had done the usual explore and play to have an idea of the language. Anyway, I started to read Programming F# 3.0 by Chris Smith complemented by Expert F# 3.0 by Don Syme, Adam Granicz and Antonio Cisternino. Two excellent books without a doubt.
However, nothing beats actual practice and after I felt a bit comfortable with F#, I started my usual “Hello World” project: an Evolutionary Algorithm library/framework. Personally, this is my ideal beginner project since I can only focus in the learning the language and the task has a good deal of complexity that allows to explore the programming language in many ways. Until now I have completed three iterations, starting with a simple Genetic Algorithm using only the more basic constructs and focusing more in the functional approach, to something more generic and library-like exploring the multi-paradigm functionality of F#.
The impressions so far have been very positive. It mixes very well the functional and object-oriented approaches and the support to switch to parallel programing is very good (for example, you can just change Array.map to Array.Parallel.map). The thing I miss most so far it’s macros like in Common Lisp. I’ve already faced two/three situations which were “screaming” for a macro but I assume this is also a sign that I still need to program more in F#. I haven’t used F# so much in a script way like many people do but that’s something that I need to explore more. I feel it’s a nice language and should be worth knowing it better, especially if you need to work with .NET.
For the past months I have spent most of my time on .NET using C# but I also would have liked to use Common Lisp on it. I do not know of a CL implementation for .NET and I read some time ago that probably doing one is not that easy, as this answer in Stack Overflow states. I wonder if it is related to floating-point exceptions (if someone knowledgeable in this area would like to comment, I thank you in advance!).
Anyway, I decided to look more carefully to see if I could find something and discovered four projects. Initially I was a bit excited that probably there is something after all. But after a more careful observation, they are far from what you would expect or want. For future reference:
The first project, ClearLisp, looked promising but it’s not even CL. Looking at the documentation you realize some differences between it and CL. Also, the project shows no sign of life since 2008 and after playing with it a little bit, it’s far from a modern CL implementation. The second one is not a proper implementation since it’s using ABCL and IKVM. The third one seems to be a way to connect ECL to .NET and uses it as a scripting language. The fourth one also looks more like an attempt than a real implementation (I didn’t explore it).
In the end, there is really no CL implementation for .NET or even one that compiles to bytecode. There is RDNZL which lets you call .NET libraries from a Common Lisp application. However, it’s not the same as having a real implementation.
Furthermore, the state of Lisp-languages on .NET is not much better since you can find lots of half-baked, abandoned languages/implementations or just without real followers (for example, L#, Yarr, dotlisp, Common Larceny, ayaka and others). The major exceptions are probably IronScheme and Clojure. And even the CLR Clojure implementation is just playing catch-up with the Java one.
The set of programmers interested in CL (or even just Lisp) and .NET is probably extremely small and thus, the current state of affairs. However, I feel that this can still be a good area of opportunity if done right.
Edit 1: zvrba on reddit explains the floats issue, which I put here:
The problem with CLR floating-point is that the virtual machine supports only one floating-point type, double (64-bit). (32-bit) float is a storage format only, so in some cases double rounding occurs, leading to results that differ from “proper” float calculations by 1 ulp.
Edit 2: clausb also on reddit pointed out to a list of Lisp projects on .NET he compiled before.
Disclaimer: the views and opinions expressed on this blog are my own and not those of my employer.
There is an interesting thread in the Clozure Common Lisp development mailing list about argument evaluation in #'<. Until now, CCL was implementing shortcircuiting when evaluating the arguments of #'<. This essentially means that when calling (< 1 3 2 4 5) it would stop before evaluating all the arguments since it wold know it would be false. Just like and. However, as reported in the initial message by Eric Marsden, it violates the Hyperspec (section 18.104.22.168.2.3 Function Forms) since it does not allow this behaviour for functions. The thread got interesting because a small discussion followed if the correct behaviour should be the one shown by CCL and not the one demanded by the Hyperspec. I must say, while reading, my initial reaction was also to consider shortcircuiting as the desired functionality but soon afterwards, you realize that you really don’t want that. The simplest argument is that you don’t want (< x y z) to have a different semantic from (funcall #'< x y z) as Tim Bradshaw rightly pointed out. Consistency is something very good to have and in the end, if you wish lazy semantics, you can always add them yourself in the true Lisp spirit. However, this shows once more how the writers of the Hyperspec got so many things right even if for a moment you might think otherwise. It was an interesting thread to read.
After many years in academia doing research, I’ve recently joined the software industry. I am now working at Microsoft, specifically, at their Search Technology Center in Munich. It’s an exciting and challenging work!
I will continue doing my Common Lisp explorations in my free time and talk about them in here as before (disclaimer: the views and opinions expressed on this blog are my own and not those of my employer).