[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:
3.2.2.3 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
notinline.
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/