Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 11:02 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (25 Oct 2005 19:11 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (25 Oct 2005 19:22 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:11 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:12 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (25 Oct 2005 22:08 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:28 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 20:22 UTC)
Re: Common Lisp solved this problem 20 years ago Aubrey Jaffer (25 Oct 2005 21:54 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (25 Oct 2005 22:23 UTC)
Re: Common Lisp solved this problem 20 years ago Aubrey Jaffer (26 Oct 2005 02:25 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 03:52 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 05:46 UTC)
Re: Common Lisp solved this problem 20 years ago Taylor Campbell (26 Oct 2005 20:05 UTC)
Re: Common Lisp solved this problem 20 years ago John.Cowan (26 Oct 2005 20:12 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 20:38 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 21:53 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 22:13 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 22:20 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 23:31 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 00:20 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (27 Oct 2005 03:20 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 05:52 UTC)
Re: Common Lisp solved this problem 20 years ago Taylor Campbell (26 Oct 2005 23:51 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 00:14 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (27 Oct 2005 03:21 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (27 Oct 2005 05:41 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 21:52 UTC)
Re: Common Lisp solved this problem 20 years ago John.Cowan (26 Oct 2005 22:14 UTC)
Re: Common Lisp solved this problem 20 years ago Thomas Bushnell BSG (26 Oct 2005 22:17 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 06:15 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 06:51 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 07:15 UTC)
Re: Common Lisp solved this problem 20 years ago Per Bothner (26 Oct 2005 07:38 UTC)
Re: Common Lisp solved this problem 20 years ago Alan Watson (26 Oct 2005 07:49 UTC)
Re: Common Lisp solved this problem 20 years ago Marcin 'Qrczak' Kowalczyk (26 Oct 2005 09:09 UTC)

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/