[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Common Lisp solved this problem 20 years ago

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

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.


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