Re: What's so great about lisp?

Pascal Costanza wrote:
If that were available then I'd want the final statically-checked code to be
compiled efficiently, i.e. without unnecessary run-time checks and with
optimised pattern matches and so on.

That doesn't make sense. The majority of a program is executed very rarely, typically only few parts are executed most of the time. It's one of those 80:20 things: 80% of the time only 20% of the code is executed. (These are, of course, not the exact numbers, but that's the idea.)

This means that the "efficiency" of the resulting code doesn't really pay off in the majority of the code - you wouldn't actually notice any

Maybe not, but the reduced size of the code could still make a (small) difference. Anyway, why have checks that aren't needed? In Lisp you need those checks, and that's perfectly fine, but in ML you don't, so I'd rather that the compiler doesn't insert them ;)

difference. On the other hand, the removed run-time checks are areas where potential problems can occur. Think about security leaks or lack of information in case the program fails in unexpected ways.

That can only happen in a language with a non-sound or incomplete type system. In C many things aren't part of the type system, and there are ways (unchecked typecasts) that circumvent the type system. Of course that's unsafe. But for instance a well-typed ML program will never have any security problems (that are type-related). Likewise if you can statically prove that an array subscript is always in range, then you can *safely* remove it in the code. It's not unsafe because it's statically proved that it can *never* happen.

The only reasonable way to get efficient programs is to try to identify the "hot spots" and optimize them and only them. The best way to optimize them is to completely get rid of them. This boils down to finding better algorithms / execution stratetegies rather than fine-tuning what are essentially bad algorithms, etc.

True, but I don't mind the compiler removing (proven) unneeded runtime checks anyway.

--
We're glad that graduates already know Java,
so we only have to teach them how to program.
	somewhere in a German company
(credit to M. Felleisen and M. Sperber)
.