Anomalies in behavior of AKCL - is it supposed to be this way?

[att!ihlpf!lgm@sun.com]

I'm running KCL with the Austin enhancements on an AT&T UNIX PC.
I'm encountering some anomalies, however, and I'm wondering
whether the behavior I'm observing is "normal" for Austin KCL
or if there's a problem with the version I have in particular.
Here are the scenarios that are confusing me.  Note that I
am using simple, albeit improbable, examples.

1) I interpretively define

	(defun and nil nil)

yet evaluation of

	(and)

still yields  T .  That is, AKCL uses its own built-in definition
of 'and' instead of mine.  I could understand this if 'and' were
a special form, but the Steele book lists it as a macro.
Macro redefinition such as

	(defmacro and nil nil)

does not change 'and's behavior either.

2) I interpretively define

	(defun car (arg) (cdr arg))

I then compile and load a file consisting only of the following
definition:

	(defun func (arg) (car arg))

I then evaluate

	(func '(a b))

The result is  A  rather than the  (B)  I expected.  I only get
(B)  if I precede the compilation with

	(proclaim '(notinline car))

Why do I need this proclamation?  Why doesn't AKCL automatically
"invalidate" the original inline definition of 'car' as soon
as I redefine that function's meaning?

3) I compile and load a file containing

	(defun f1 nil t)
	(defun f2 nil (f1))

Evaluating

	(f2)

of course yields  T .  I then interpretively redefine 'f1' using

	(defun f1 nil nil)

At this point evaluating

	(f2)

again still yields  T .  That is, 'f2' is still linked to the old
version of 'f1'.  But if I toggle the Austin-fast-linking flag via

	(use-fast-links nil)
	(use-fast-links t)

then the evaluation of

	(f2)

now yields  NIL .  That is, 'f2' is now linked to the new version of
'f1'.  I very much like the ability to redefine functions, even
compiled ones, but should I really have to toggle the fast-link
flag to get that effect?

In any of these three areas, please don't hesitate to tell me that
"it's supposed to work that way" if indeed that is the case.


	Larry Mayka
	AT&T Bell Laboratories
	att!ihlpf!lgm