Re: static, dynamic and implicitely typed languages

On Sun, 12 Oct 2008 16:40:11 -0700, grande.piedra wrote:

You say:the compilers are mature, and able to perform quite a few
optimizations.

I absolutely agree with you, but this is perhaps because the
language use so many functions.

You just can't let go of your original hypothesis, can you?

For example, in python you don't have symbols, you have only symbol-
name, and this slow down the code. In python you can't use (eq, you use
= and this overload a lot the language, ...

I agree with you about compiling to native code is faster, but I'm
wondering about what features of a language make better compilers for
the language and what's the prize of it. Is this a vague idea?

Common Lisp was meant to be optimizable. You can declare types, and in
many cases the compiler will infer types for you without explicit
declaration (eg SBCL does a lot of this, even with low optimization
settings). Modern Lisp compilers are very sophisticated and take
advantage of declarations and type inference.

Consider this code:

(defun foo (n)
;; Warning: non-idiomatic, idiotic Lisp code follows.
(let ((k 0))
;; increment k n times
(dotimes (i n)
(incf k))
;; try to access an element of it --- but it is not a vector!
(aref k 12)))

When you compile, SBCL complains:

; in: DEFUN FOO
; (AREF K 12)
;
; note: deleting unreachable code
;
; caught WARNING:
; Asserted type ARRAY conflicts with derived type
; (VALUES UNSIGNED-BYTE &OPTIONAL).
; See also:
; The SBCL Manual, Node "Handling of Types"

This has nothing to do with the fact that aref expects arrays. Same
thing happens with the general sequence accessor nth. Or that the code
is compiled into machine code - type inference would help with bytecode,
too.

Also understand that Lisp hasn't always been as fast as it is know. In
fact, there is a persistent myth out there that Lisp is slow. So it is
quite amusing that you are looking for some secret that makes current CL
compiled code fast.

I still don't get your purpose. You are looking for a fast language. CL
is here. Just use it.

Tamas
.

Relevant Pages

  • Re: a dozen cpus on a chip
    ... No nontrivial language can ever be proven to be imposible to crash. ... compilers still available which implement ISO M2. ... It is a common misconception that Lisp is always interpretted. ... various X86 machines the hardware does exist that could allow the OS ...
    (sci.electronics.design)
  • Re: Lex, Yacc, and Lisp...
    ... > for most language compilers. ... some student in a CS course designs a language. ... > preceded by an open-paren and the name of the node type (from ... Why not write the compiler in Lisp? ...
    (comp.lang.lisp)
  • Re: Creating a VM in Lisp
    ... I wish to use a high level language for this. ... Now I'm sure I could use Lisp to do this, but the problem I think I ... Spanning the gap between assembler and your not-C high-level ... use will not be able to take advantage of the things that C compilers ...
    (comp.lang.lisp)
  • Re: why is lisp fast?
    ... language features which make it inherenly easier to generate effecient ... write native code compilers for it, but none of them have worked well. ... What language design features make lisp more suitable for compilers? ...
    (comp.lang.lisp)
  • Re: how is Haskell not robust?
    ... OCaml performs fewer and simpler optimizations than most C compilers, ... I wasn't referring to optimizations, but to the language itself. ...
    (comp.lang.functional)