> I have to quibble with the ``heavy reliance on recursion'' comment.
> Logo isn't slow because of recursion. It's been shown that a
> tail-recursive procedure call can be compiled to a simple jump. This
> means that a tail-recursive procedure is just `syntactic sugar' for a
> goto! That's what all the fuss about tail-recursion is about. (Non
> tail-recursive procedure calls are more expensive but only because of
> the necessity of managing intermediate results.)
I mean, for example, the way Logo constructs functions by recursively
gathering their arguments. Compare that with the way Forth gathers
arguments on a stack! Forth is known for probably the fastest execution of
any language this side of assembler. Logo the slowest. Is there not some
reason for that difference? I just assume it's because Logo is entirely
recursion-oriented, while Forth is entirely stack-oriented.
> The real problem with Berkeley Logo is that it doesn't have a
> compiler. That's a significant project, though probably hacking a
> byte-code interpreter into Berkeley Logo and writing the compiler in
> Logo would be within reach, even fun.
> I've been really tempted to do something like this. But I've already
> got one Berkeley Logo project on my plate....(No I haven't forgotten
> about the X stuff, Brian. :-) )
With the fast processors of Pentium and PowerPC class becoming
available, it seems like even interpreted Logo can do pretty good
speed. I tested an old MS-DOS release of Berkeley Logo (3.0.1) on my
Pentium 90MHz system the other day. It was amazing -- and rather
embarrassing -- to see how it smoked my Amiga 4000/040. Considering
the likelyhood of Pentium II and PowerPC processors clocked over
200MHz, I don't see much advantage to be gained from further speeding
up the Logo language engine. I feel like what we really need are more
primitives to make wider use of the system resources. So we can do
things like raster graphics, simple GUI dialog boxes, load images, play
sounds samples, etc.