Re: introspection in SML

In article <fj3kjg$ccv$1@[EMAIL PROTECTED]
>,
 Vesa Karvonen <vesa.karvonen@[EMAIL PROTECTED]
> wrote:

....

> > An interesting point of view, but I am still convinced that one can
have
> > *both* abstraction and efficiency without loosing introspection and
> > interactivity, as Common Lisp shows.
> 
> Common Lisp gives fairly good performance, good enough for many uses,
> but I must challenge you to transliterate my vector arithmetic example
> to Common Lisp.  There really are many reasons as to why a language
> like Common Lisp is much more difficult to compile to efficient
> machine code.  If there is a Common Lisp compiler that can *safely*
> optimize high-level functional code as well as MLton, then I would be
> pleasantly surprised.  Just the simple fact that any top-level binding
> might be mutated at almost any point (any time you call a procedure
> that the compiler doesn't know) makes many optimizations significantly
> more difficult to perform *safely*.  That is why you can declare the
> level of safety you want (UGH!) in Common Lisp (or at least some CL
> implementations).  Unless you have the whole program, and I'm not
> aware of any whole program compiler for Common Lisp, you can't safely
> evaluate even something as simple as the expression (+ 1 2) statically
> in Common Lisp.  But, really, I have nothing against Common Lisp.  It
> has some features that I find interesting.  However, being amenable to
> static analysis is *not* one of the features of Common Lisp.

....

That's not completely true. You might need to check out the
chapters about compiling code in the ANSI CL standard.

See here for semantic constraints for the compiler:

  http://www.lispworks.com/do***entation/HyperSpec/Body/03_bbc.htm

The standard for CL for example says

* any Common Lisp built-in construct is not changeable.
  The compiler does not need to make them changeable.
 
  this (CL:+ 1 2) has always a fixed semantics and is using
  the CL function +

  You are not allowed to redefine CL:+ .

  Many implementations have the idea of protected packages
  and will (warn or give an error) when you attempt
  to redefine a built-in function or macro.

* the compiler can assume inside a function that all references
  to the function itself do not change

* the compile can assume that inside a file the
  function defined and used does NOT change.

Several compilers have the idea of larger compilation units
and make assumptions based on those.
See for example the chapter on block compilation
in the manual of CMUCL :

http://common-lisp.net/project/cmucl/doc/cmu-user/compiler-hint.html#toc176

So, in Common Lisp calls do not go necessary through some
dynamic lookup mechanism - there are also situation, where
static assumptions can be made.

....

-- 
http://lispm.dyndns.org/