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

Re: Common Lisp solved this problem 20 years ago

Alan Watson wrote:
Per Bothner wrote:

Common Lisp allows a compiler to *assume* / is defined to the standard
/ operation, unless there is a visible re-definition.
Kawa makes more-or-less the same assumpions.
I think that is a reasonable default mode for a compiler.

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.

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.

(I compile most of Kawa's Scheme code with --warn-undefined-variable
which is very nice for catching errors, and which encourages proper
module imports.  It doesn't preclude a typo or otehr error which
accidentally matches a predefined function, I concede.)

Can you tell me where in the HyperSpec this behaviour is sanctioned? I had a quick look before posting my last message, but couldn't find it.

I can't find it either.  I may have been thinking of: Semantic Constraints
  A call within a file to a named function that is defined in the same
  file refers to that function, unless that function has been declared

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

If I recall correctly, one of the advances of Dylan over Common Lisp was that that Dylan modules export names and *values* not whereas Common Lisp packages export names. This helps the compiler reason about the value of imported procedures. Bigloo is able to do this too, I think.

Kawa is similar, I think: A module exports a set of bindings.
require-ing the module imports the bindings into the current
(lexical) scope.
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/