Re: Common Lisp solved this problem 20 years ago Per Bothner 26 Oct 2005 07:38 UTC
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 xxxxxx@bothner.com http://per.bothner.com/