Vladimir Sedach
Vladimir Sedach is a person that started programming in CL in 2002.

Blog: https://oneofus.la/have-emacs-will-hack/

Projects: Parenscript | Vacietis | CLiki | Eager Future2 | uri-template | cl-moneris | vas-string-metrics | css-lite | mouse-copy

His Common Lisp library wish/TODO list:

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:

    A repackaging of the core package namespaces, for example...

    - std.cl

    This includes the cl namespace + cl-ppcre + usocket + bordeaux-threads, trivial-gray-streams, etc. This would be an extensible, cross-platform, unified API for an extended core language tied back to documentation.

    - std.util (anaphors, expanded string facilities, etc.)

    This may even be included in std.cl - but I think there is room for much discussion and debate here. Of course to make practical progress there needs to be one or a few people who make the final calls.

    - std.contrib.me

    Leave room for people to include project-specific or personal variations that nevertheless can remain in this common namespace. People can propose that a utility be migrated into a common namespace like std.cl, std.util, etc.

    - std.? (.net, .xml, .json)

    Rename common, existing libraries into a coherent package namespace and index on the web so users can find common functions and libs easily and via one portal. With the cooperation of the authors, the underlying libraries can be fully renamed, or we can simply provide packages that re-export these names in the interim.

    I made a stab at this earlier and at least 3 or 4 of the primary popular utility library developers expressed a willingness to move over to such a model and release their code for use here.

    Ian Eslick's original comment

  • 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.

  • 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!):