[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Higher level languages as part of the core of SVN

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-10-19 19:37:34 CEST

So, one of the contentious topics at the Subversion Summit earlier
this week was a choice of language for Subversion 2.0. There are many
people who want to think about things like using some subset of C++
for parts of the application (the "batons suck damn it, lets have
objects!" crowd), and many other people who hate C++ with the fires of
a thousand hells, and just don't want to see that happen.

Another group advocated (and I'm not sure how serious this was) the
idea of writing things like the command line client and other tools in
something like Python, rather than doing so in C. This kind of thing
would mean that our bindings would get a lot more attention, which
would be nice.

I'd like to propose another idea for how we could write parts of
Subversion itself (not just the command line clients, but actual
portions of the libraries) in a higher level language, but still
expose a C level interface to the rest of the world, without dealing
with the binary compatibility and other issues that come with C++.
Ideally I'd see us writing the code at the level of libsvn_client in a
language other than C, and that would call into things like libsvn_ra
and libsvn_wc. If we went forward with ideas like reimplementing the
working copy in a newer better faster way, we could decide then if it
would be written in C or something else.

So, the way I'd propose doing this would be to start making use of Lua
for our higher level language. Now this may seem a little weird,
since we don't even have Lua bindings at the moment, and most of you
have probably never used it, but bear with me here. Lua is a
scripting language that's designed to both embed C code (i.e. call
into C libraries, like we do with the bindings today) and be embedded
within C code (i.e. act as an embedded scripting language for a big
application, this is actually done within things like World of
Warcraft and other similar games). With decent Lua bindings for the
lower level performance critical parts of the application, we could
fairly easily implement chunks of the application in Lua, while still
providing a C interface that would enable us to build bindings for
other languages.

Actual code written in Lua looks pretty much like code in other common
scripting languages today. Here's an example:

-- defines a factorial function
function fact (n)
  if n == 0 then
    return 1
    return n * fact(n-1)

print("enter a number:")
a = io.read("*number") -- read a number

That does basically what you expect it to.

The real kicker though, and the reason that Lua is in my opinion a
more practical solution than doing the same sort of thing in a
language like Perl or Ruby or Python is that Lua is tiny. The entire
lua5.1 interpreter on my Ubuntu machine is 124k. The actual Lua 5.1
codebase is just under 17000 lines of code, and is written in pure C89
(with the exception of some platform specific code for dlopen type
stuff, but it's already at least as portable as APR is, so no worries
there). It's also built for doing this sort of thing, calling C and
being called from it, which means it's far more practical to do things
like that in Lua than it is to do similar things in the other popular
scripting languages.

Anyway, this has gone on long enough, and it's really just something I
think people should think about, since it provides some intriguing
possibilities for the future. You can find more info on Lua at the
following URLs:

  http://www.lua.org/ - The main Lua web site
  http://www.luaforge.org/ - A site that hosts Lua related projects
  http://www.swig.org/Doc1.3/Lua.html - The SWIG Lua docs


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 19 19:38:03 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.