thomas (02/11/83)
That's not a bug, that's a feature! In "technical" (lisp) language - all functions in Gosling's emacs are Fexprs. In Algol terminology, they are all call by name. This does make recursion a little more difficult, you have to use a helper function: (foo i (setq i (arg 1)) ... (foor (+ i 1)) ... ) (foor j (setq j (arg 1)) (foo j) ) =Spencer
mrose.uci@Rand-Relay (02/14/83)
From: Marshall Rose <mrose.uci@Rand-Relay> Regardless of whether you want to classify MockLisp functions as FEXPRs, the point still remains that the semantics of dynamic-binding are being violated. The fact that recursion gets mangled is a side-effect of this. If we define (defun (foo1 i (foo2) ) ) (defun (foo2 (message "i = " i) ) ) then if you invoke (foo1), the "i" that (foo2) uses must be the "i" defined in (foo1) by virtue of the fact that the "i" in (foo1) was the most recently declared variable with name "i". Similarly, if (foo2) defines a variable named "i", then the "i" that (foo2) uses must be that "i" since that "i" was the most recently declared variable with name "i". The bottom line is that this doesn't work in MockLisp. If some other binding strategy is used, say, lexical-binding, then that's fine, but it'd be nice to know the rules that the MockLisp interpreter is using when it decides which instantiation of a variable it's going to access. /mtr
thomas@Utah-CS (02/15/83)
From: <utah-gr!thomas@Utah-CS> No, I don't see that "the semantics of dynamic binding are being violated". This is exactly the behaviour I would expect from an un-compiled FEXPR. (I was wrong in classifying it as "call by name", the evaluation of this is generally done in the calling environment.) I do agree, however, that this should be more explicitly spelled out. It bit me the first time, too. Given that expressions must be either all FEXPRs or all EXPRs, I think I prefer the FEXPR interpretation. =Spencer