On Sun, Feb 10, 2008 at 06:33:52PM -0800, Andrew Lentvorski wrote:
David Brown wrote:
- Globals can be arbitrarily assigned to. This means, technically,
inlining is forbidden, since the definition could be changed later.
I'm not sure this is specified on way or the other in R5RS. I think
implementations can choose to have immutable builtins.
I'm not talking about just builtins. User-defined top-level bindings can
be reassigned arbitrarily. You can't inline and comply with R5RS.
- call/cc. Conceptually nice, since everything else can be implemented
with it. But, it requires such a different execution model that
generating good code is hard.
That simply isn't true. Gambit and Chicken chew through call/cc just fine.
By not using a stack at all, and allocating all call frames on the heap.
This is the "different execution model" I was referring to.
Chicken uses a wonderful trick of writing C functions that never return,
and using setjmp/longjmp after garbage collecting the stack variables. The
C stack basically becomes the nursery for the generational GC.
It doesn't get along very well with C that wants to do callbacks. Suddenly
you have call frames that can't be collected. Chicken handles this, but if
you do it a lot it is easy to exhaust your stack.
Chicken's generated code is a lot less efficient than SBCL, mostly because
of the handling of stack frames.
Other implementations do call/cc poorly. Bigloo makes it optional, since
enabling it makes all code execution less efficient.
So, my feeling so far is that Scheme is a nice toy for learning lisp, but
that common lisp is a more useful tool.
Maybe. However, I find that even as large as the Common Lisp standard is,
it still doesn't handle enough (threads? FFI? OS interfaces?) so I'm back
in the same boat whether I'm in Common Lisp or Scheme. I have to run with
a particular implementation.
CFFI seems to be settling nicely on a de facto standard for FFI. Code
using CFFI will then be portable across all platforms supported by CFFI.
The others are lacking more.
David
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
