Common Lisp for OM (Was: Programming OM)

[Shawn Rutledge]

On Wed, May 7, 2008 at 7:32 AM, Oliver Uvman <oliver.uvman at gmail.com> wrote:
> Jesus! I thought I was the only one wanting to program CL on the OM.
>  I've had lots of interesting ideas on how to use a gesture-based
>  interface for writing CL, which could work only thanks to the sparse
>  syntax, and plan to make that some of the first things I program for
>  my OM. Hooray!

A couple of us Chicken Scheme people have run it on OpenMoko.
Somebody needs to write the BitBake recipe for building Chicken and
its "eggs" (extensions).  (Maybe I will get around to that, but it's
my first time, and I imagine enough things will go wrong that it will
become frustrating, like BitBake often is.)  The latest version I
actually cross-compiled using the OpenMoko toolchain, so it's not
hard.  Then provided I have installed gcc and the other development
stuff (headers, binutils, etc.) I can actually compile Scheme code
right on the phone (slowly).

I wrote (laid?) an "egg" to support DBus, and next I'm writing one to
support gpsd.  Likewise there will need to be another to support GSM
functions, when that becomes stable enough (ideally it will only need
the DBus interface, which would make it pretty trivial since the DBus
egg provides the means).

Those are components I needed for Display Scheme, which will be an
alternative framebuffer-based GUI.  DS will be a display server (like
an X server) which (being a Scheme interpreter rather than an
X-protocol interpreter) will allow you write client-server
applications where the client code runs within the display server
itself.  (Or you can write client-only applications, but there are
limitations, the big one being that Chicken does not support native
threads, only lightweight threads.  I'm thinking that message-passing
between processes is the future on many-core systems anyway.  So each
app should be its own process.)  It is the same model that was used
for NeWS except Scheme replaces Postscript.  I have a couple of very
basic widgets working, and next need to work on IPC techniques so that
it's possible to write client-server apps.  Then when I have GSM and
GPS apps working, maybe there could be some sort of early release
(installable packages), but that's still fairly far out.  Then after
that I need to work on making the application-programming process as
high-level and terse as possible.  The main purpose of this project is
to pursue my ideas about "metawidgets" (describe what the application
should do, rather than exactly how to lay it out on the screen,
because then it can be more portable).  And apps can run on
network-connected servers, of course, so using Scheme rather than
HTML/Javascript/Flash will provide a solution to many of the problems
the web-application folks are working on now, and much more
efficiently.  The client will be able to connect to the server via
various transports like HTTP, SSH, plain sockets, maybe DBus, etc.
Depending how much code the server "exports" to be run on the client
(which may ultimately be a dynamic tradeoff, taking into account the
available bandwidth and the processing power and memory on both ends),
client-server apps could work offline too.

Common Lisp isn't to my taste.  But I imagine you can write a
"compiler" that generates Scheme for the UI portions of your
application, and then you'd be able to write applications in Common
Lisp.  Likewise in the distant future there should be some bindings
for other languages like Python and C++.  Chicken has the advantage
that the apps can be compiled too, so not very much code is going to
end up being interpreted: just the "glue" that is actually
communicated across the connection between the server and client.
Eventually maybe I could find a way for the client to ask the server
to cross-compile code on its behalf, so that nothing would need to be
interpreted.  Now if only I had enough time to do all this stuff. :-)

http://sourceforge.net/projects/dscm/
http://callcc.org/
http://chicken.wiki.br/cross-compilation