Valery Khamenya
Valery Khamenya is a Person.

I use C++ about 10 years and during last 5 of those years I track activity in functional programming and Lisp. I think 5 years is enough for deciding to switch to Lisp :-)

Last News:

26 Oct 2003: LLVM version 1.0 is released!

16 Aug 2003: I have successfully compiled tinyscheme with LLVM-based C frontend compiler

Remark: prerelease of LLVM package was used.

I do believe that LLVM will be a cool basis for next generation Lisp implementations.

My wishes

    Big Wish 1. Obtain a copy of good CL implementation

        I'd like to have a CL implementation with following features:
      • free or not expensive
      • compliant to ANSI standard of CL
      • portable Linux/win32
      • full support for GUI apps development (no less then in Kylix or Delphi)
      • run-time compilation to native
      • I/O no more then 20% slower in comparison to, say, gcc

      Just for example, CMUCL is not ported to win32 and has no good support for GUI development. Allegro CL is good but too expensive.

      I will buy a copy of Allegro CL for personal use when they make it no more as 300 USD for Linux+win32.

    Big Wish 2. CLVM (or how to organize CL implementation underworld a bit)

      Lisp implementor spread their efforts over a lot of platforms developing a good code generation and platform-dependent optimizations (saying "good", in particular, means run-time compilation to native code). Any transfer to any new platform is painful and should be done for every implementation with different success. Some CL-implementors try to resolve this issue in different ways. But those solutions are incomplete in a way.

      Please look at my proposal about CLVM for getting an idea how (much more) complete solution could look like.

      IMHO, one of the best engines for CLVM I believe could be a Graph Rewriting Systems (GRS)

      See also, "Functional Programming Comes of Age"

    Big Wish 3. Collection of Code Snippets on Effective Programming in CL

      I've added initial entry to Anthology. For example, I'd be happy to add some simple examples where
      • C++ lose because C++ is just not able to compile a function on-fly
      • C++ lose because C++ is just not able to compile a closure of the function on-fly
      • C++ lose with its (*this) and CL could get rid of this with on-fly compilation of method with given object.

    Middle Wish 1.

      It would be good if I/O in CL could be implemented a bit quicker.

      Indeed, following "smart" feature 

  (format s "~F" fl)
is about 10 times slower then the following non-smart one: 
fprintf(s, "%f", fl);
as a result -- there is no way to get quick enough ASCII I/O within CL (at least for floats).

remarks:

  • last versions of CMUCL and "gcc -O2" available on July 2003 were used for comparison. Comparable slowdown I got with Allegro CL.
  • if "%f" and "~F" change to dummy "12.13", then CMUCL is only 3 times slower then C.

Feedback

  • email: khamenya AT mail DOT ru
  • For Russian spoken audience I've created a web-forum with an entry for Lispers; all are welcome!