Vladimir Sedach

Blog: http://carcaddar.blogspot.com/ Twitter: http://twitter.com/vsedach

Parenscript and EAGER-FUTURE are some of the projects he is involved in.

His Common Lisp library wish/TODO list:

• Library to provide CLtL2 environment-style declaration and environment information for macros (many implementations provide most of this functionality internally; see the definition of variable-special-p in CLOCC sys.lisp)

• Cross-platform library for detecting SMP/multicore information and setting thread affinity; to later be merged into Bordeaux-Threads (see Alexey Voznyuk's shootout entry for the start of a phtreads implementation). Also Nikodemus Siivola's sb-cpu-affinity.

• zeroconf/Avahi library for Lisp network cluster autodiscovery. [I should probably look at CL-ZEROCONF now that I know about it]

• Lease-based resource management library (like in Jini), which can be used for making fault-tolerant distributed systems

His Common Lisp projects-that-would-be-cool list:

• Implement Ian Eslick's meta-library for de-facto standard utility and language extensions. This is probably the most realistic plan for moving Common Lisp forward as a language, as it relies only on work that's already been done and widely adopted by the community, and uses the package system for incremental changes.

• Integrate CL-JavaScript into the Closure web browser.

• Add HTML5 support to the Closure web browser.

• Something like SERIES for Parenscript and a server-side DOM that would provide a better stream processing library for the web (better than jQuery, anyway) and use compiler macros for doing optimizations like map fusion.

• Something like Clojure's Enlive for doing HTML templating based on CSS selectors. This would enable a much faster workflow for doing websites where the HTML is driven by designers - instead of having to re-do the templates when the designer changes an HTML page, no changes would need to be made if the CSS selectors stay the same (they essentially act as an API between the markup and the code). Closure-html is a good starting point for this. It would be nice if this was also integrated on the client side with Parenscript (perhaps with the above mentioned "SERIES for Parenscript" library).

• The above library will probably need something like jQuery's Sizzle CSS selector search for DOM. Again, look at Closure.

• Library specifying a protocol for web application user authentication and session management, exposing orthogonal implementation interfaces for web servers and storage backends (so you can use web server X with database Y without having to write an implementation for every cross-product of web servers and databases), with implementations for currently popular web servers and databases.

• Portable cross-platform server daemonization library ala RESTAS-daemon (because screen/detachtty don't work well with certain things, such as runit/daemontools supervise). cl-daemonize does this for SBCL on Linux, but needs to be made portable.

• StarLisp library for CL that can compile to vector co-processor (SSE, AltiVec) code, multi-threaded code, GPU (CUDA) code (see cl-gpu), and multi-machine (simple s-exp over socket (philip-jose, ddist, cl-mw), as well as MPI (cl-mpi)) code. Write your parallel Lisp code once, run it on any parallel machine without changes. Alexander Gavrilov (author of cl-gpu) has the ECL-compute project which does this for SSE and CUDA for ECL.

• Lisp as a shell but with reader conveniences and Unixisms. outer-parentheses-free-repl probably gets you 80% towards something convenient. com.informatimago.common-lisp.interactive has ls/cd/etc. Unix file browsing commands. While it might be tempting to use INFIX for some things, there's no need to resolve to using reader macros; this can probably be done with a regular macro (much like LOOP). Learn from the mistakes of scsh. linedit provides readline-like editing.

• Extend cl-l10n FORMAT to provide better support of quantity/inflection printing directives and other pretty-printing things, taking the best ideas from MediaWiki and Locale-Maketext. Related: vana-inflector pluralizes and singularizes English words. Investigate whether the Unicode Common Locale Data Repository data can be used.

• Native Common Lisp NX client. Use Neatx for protocol specification (it might be possible to use CLPython to run Neatx protocol libs directly, since Neatx is written in Python; on that note, it might be possible to port Neatx server itself to run on CLPython). Use CLXS for talking X11 protocol, but discard the legacy X font and drawing stuff (support XRender only). Use something based on Cairo (McCLIM?) as the drawing backend. Combined with a native Lisp port of Neatx as a library for applications (maybe use parts of xlyb to help with this) and direct-to-hardware rendering, this can form the basis of the graphics system of a hypothetical Lisp OS. Use zen as a replacement for Xnest to start work on a new Lisp OS display system. Stand-alone, it would be a really useful application.

• Hazelcast for CLOS. GBBOpen might already be able to do this. Also might try to contact Lothar Hotz to resurrect NetCLOS.

• Extend Walter Pelissero's make-exe-op ASDF operator idea (Walter's implementation for SBCL: http://wcp.sdf-eu.org/software/asdfa.lisp) to be as multi-platform as possible so that Creating Executables from Free Software Lisps becomes trivial.

• Terminal emulator for Common Lisp. Port either Paddy Mullen's rxvt-js or the suckless st terminal emulator to CL. Use this to replace xterm on your *nix desktop, add terminal emulation to McCLIM, terminal emulation modes to Climacs and Portable Hemlock, and eventually as the terminal emulator in a Lisp OS.

• Port Tony Garnock-Jones' Racket-SSH to Common Lisp. Get a CL SSH client so you can talk to *nix servers securely, an SSH server so Lisp processes can talk to each other securely. Combine with terminal emulator above to get rid of your OpenSSH client. Will be needed for a Lisp OS.

• Replicated transactions for bknr-datastore for high-availability, persistent CLOS objects.

Things I used to want, but don't think are such a good idea anymore:

• A "usocket-event" library that adds simple epoll/kqueue/select functionality that can be used with usocket and existing code.

• User-space threading library based on CPS conversion (something like Java's Kilim for CL). Note that this would need to shadow and re-implement those CL special forms (special variable binding, catch/throw, conditions and restarts) that rely on the dynamic environment, so it would in effect involve writing many parts of a new (portable) CL implementation in CL. ContextL provides a Scheme-like dynamic-wind and first-class dynamic binding environments that could serve as a start for this. Should be integrated with the above proposed "usocket-event" library.

• Once Closure has JavaScript support, adapt rxvt-js (a JavaScript/DHTML port of urxvt) to run as a stand-alone native application (using Closure as a library), to serve as a replacement for xterm/rxvt. [write CLIM xterm instead]

Things on the it-would-be-cool-list that turned out to have been done already (people are wrong when they say there's no Lisp libraries out there; it's hard to keep track and to find them!):

• An s-exp tree search library based on cl-unification and/or fare-matcher. This would be a light-weight alternative to parsing HTML into a DOM as suggested by the two libraries above. SPath and s-query both do this.

• RFC 2898 library for hashing passwords in web applications Ironclad comes with PBKDF2 but that isn't advertised. bcrypt and scrypt still need CL implementations.

This page is linked from: CLiki Bugs   Favorite Lisp books   GSoC 2011 Parenscript project page   proposed extensions to ANSI   The Great Macro Debate   uri-template  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively