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/