Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 11:02 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (25 Oct 2005 19:11 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (25 Oct 2005 19:22 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:11 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:12 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (25 Oct 2005 22:08 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:28 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:22 UTC)
Re: Common Lisp solved this problem 20 years ago Aubrey Jaffer (25 Oct 2005 21:54 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 22:23 UTC)
Re: Common Lisp solved this problem 20 years ago Aubrey Jaffer (26 Oct 2005 02:25 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 03:52 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 05:46 UTC)
Re: Common Lisp solved this problem 20 years ago Taylor Campbell (26 Oct 2005 20:05 UTC)
Re: Common Lisp solved this problem 20 years ago John.Cowan (26 Oct 2005 20:12 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 20:38 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 21:53 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 22:13 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 22:20 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 23:31 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 00:20 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (27 Oct 2005 03:20 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 05:52 UTC)
Re: Common Lisp solved this problem 20 years ago Taylor Campbell (26 Oct 2005 23:51 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 00:14 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (27 Oct 2005 03:21 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 05:41 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 21:52 UTC)
Re: Common Lisp solved this problem 20 years ago John.Cowan (26 Oct 2005 22:14 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 22:17 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 06:15 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 06:51 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 07:15 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 07:38 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 07:49 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (26 Oct 2005 09:09 UTC)

Re: Common Lisp solved this problem 20 years ago Alan Watson 26 Oct 2005 07:49 UTC

Per Bothner wrote:
>> Unless the compiler has the ability to see into the future, this
>> assumption can be rather dangerous in an interactive system.
>
> Not very, I believe: Redefining a standard function is not a wise thing
> to do, and not very common.

It may not be very wise, and may not be very common, but it is very
dangerous!

> Moreso: redefining a standard function (or even a non-standard builtin
> function) in a *different* separately-compiled compilation unit (module)
> is even more foolish and rare.

Eh? The arithmetic operators, for example, are regularly redefined to
work on aggregate types, so that you can, for example, add vectors of
numbers.

> But I'm sure Common Lisp allows inlining standard function like (+ ...).
> Otherwise how could you possibly generate good code?

You can declare a function to be inline. However, I was unable to find
the place that said the compiler could assume the function value is the
value at the point the expression continaining the function is compiled.
It must be there somewhere, though.

> Kawa is similar, I think: A module exports a set of bindings.
> require-ing the module imports the bindings into the current
> (lexical) scope.

If I recall correctly, the crucial point is that Dylan allows modules to
be "sealed", which guarantees that the values of exported values do not
change.

Regards,

Alan
--
Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México