Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's certainly easier to declare a function in LuaJIT - you can take the definition directly from the header file, rather than transcoding it into s-exps.

Compare:

  (define memcpy
	       (let ((this (dynamic-link)))
	         (pointer->procedure '*
	                             (dynamic-func "memcpy" this)
	                             (list '* '* size_t))))

vs.

  ffi.cdef [[
	void * memcpy ( void * destination, const void * source, size_t num );
  ]]

You also get the ability to add metamethods and finalizers to returned C objects (so you can use Lua's built-in GC to clean up after, for example, your FILE*).

As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster.

Of course, macros are awesome, and a huge point in Guile's favor. On the plus side, Lua is very easy to understand, especially if you're coming from Javascript.

"As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster."

[Citation Needed]

I know of old benchmarks (pre Crankshaft) that showed the interpreter being faster than V8, but my own tests using the same benchmarks from the computer language shootout show V8 to be about 1.5x faster than luaJIT now.

I did some searching, and the most recent (though still way out of date) comparison I could find was this: http://attractivechaos.github.com/plb/

You can compare v8 to vanilla lua on the computer language shootout benchmarks page, and then compare luajit to lua on the luajit page. V8 has definitely made up some ground, and the luajit interpreter isn't generally faster than v8, but the jit is still way faster on almost all tests. The one area where luajit isn't great is on tests that stress garbage collection, since luajit still uses vanilla lua's GC. I think that's luajit's next area of focus.

My definition of an FFI was simply about fully supporting native threads. Simplifying FFI definitions has not been a big deal for me. It is either a few hours of work, or if more than that, then I simply use Swig.

As for finalizing arbitrary objects, please see http://community.schemewiki.org/?guile-guardian

I agree on the speed part. But guile 2 is getting better. The reason guile cannot be as blazing fast as say gambitc is their need to inter-operate with all sorts of C code. Native threading included.

> Can't get more functional than scheme :)

Rich Hickey: "Functional has been applied, you know, for a whole spectrum of things. I think there’s the haskell meaning of functional, which is sort of, the pure notion of function applied to absolutely everything in the language. And then there’s another notion of functional... lisps claimed to be functional early on, only for the simple reason that functions were first class objects or values that you can pass around. Those are the two ends. Somewhere in the middle, i think, is a style of programming that emphasizes programming with pure functions, in other words functions that are free of side effects, that operate only upon their arguments, which are values, and that only produce values as results. So that’s a pure function. Clojure emphasizes the style of programming using pure functions, where lisps, traditionally, have not. You could do it, but it was a choice. The key thing in forcing you to make that choice, is to have the core data structures be immutable, so they now can be treated as values, in a way that mutable things cannot. So Clojure emphasizes functional programming, by providing a set of immutable core data structures, including those ones that you use to represent code. They’re also persistent, which is a special characteristic we could talk about. Because of that, it encourages the functional style of programming, because you cannot change [the core data structures], so you have to write a function that produces a new value as a result. but there’s no enforcement. if you write a function and that does IO, well that’s not a pure function anymore, and I don’t preclude it, and there’s no type system to preclude it, its a dynamically typed language, which just respects the programmer’s right to do whatever they please." [1]

[1] https://docs.google.com/document/pub?id=1Vgbw3hGCye2rtmnZ6iS...

> And guile offers all of this while supporting native threading with a single heap.

What is Guile's synchronization model for shared-state multithreading?

> Guile is available on n900. So there.

This appears to be a Linux-based phone, so that's not very surprising or impressive. Lua is straight ANSI C and can compile on much more limited systems than a Linux-based smartphone.

One other data point: Guile is 5x the size of Lua, in both source and binary forms.

> To continue, guile has continuations (delimited or otherwise), and macros (hygienic or otherwise), both of which are effectively missing in lua.

One of the authors of Lua made an interesting point in his slides describing Lua 5.2: if you think "goto" is evil, continuations are much worse. And yet it's considered "cool" to support continuations. http://www.inf.puc-rio.br/~roberto/talks/novelties-5.2.pdf

> One other data point: Guile is 5x the size of Lua, in both source and binary forms.

This. We were considering using Guile before we ended up going with Lua and this was actually a big factor for us.

With a small patch to add coroutine.clone[1], you can have continuations in Lua[2].

[1] http://lua-users.org/lists/lua-l/2006-01/msg00652.html

[2] https://github.com/torus/lua-call-cc

Which is to say, Lua's coroutines are isomorphic to single-shot continuations* - you can implement either in terms of the other.

* Full continuations, with copying.

Great paper: "Revisiting Coroutines" (ftp://ftp.inf.puc-rio.br/pub/docs/techreports/04_15_moura.pdf)

Can't get more functional than scheme :) Sure, per his def of FP, scheme is numbers 1 through 18 on the league table ;-} Other defs:

http://dl.dropbox.com/u/7810909/docs/what-does-fp-mean/what-...

http://existentialtype.wordpress.com/2011/03/16/what-is-a-fu...

http://stackoverflow.com/questions/2254368/if-java-people-go...

I'm not taking sides, i like haskell, scala, clojure just fine, I'm sure I would like racket or CL if i picked them up.

> Can't get more functional than scheme :)

Try telling that to the Haskell guys!

Scheme community frowns upon mutating code. R6RS even forced that by default, though the rest of the specification was a mess.

So, scheme style these days is all about pure functions, tail calls and continuations. To think about it, that really is setting it apart from common lisp.

Th Scheme language allows, and the Scheme community encourages, functional style, but it's still up to the programmer to write their programs that way. In Haskell, there is no other way -- even imperative programs in Haskell are functional!

Any JVM support? These days JVM sells good.