manheime@nbs-amrf.UUCP (Ken Manheimer) (08/01/86)
Since i've contended with the eccentricities of the parameter binding scheme in Gosling/Unipress Emacs i've developed a bit of frustration about it. Here's some excerpts from the discussion on it and my perspective. > > [the credit for this reference has been lost in the discussion...] > > Conclusion: Due to the way the 'arg' function is defined, local > > variables are not entirely insulated from other variables > > (local or global) that have the same name. > > > > This is a problem, since the major selling point of local variables > > is supposed to be that you are free to choose names for them > > without bothering to check if those names are already being used > > somewhere else. The peculiarity of the Mlisp binding scheme stems from the on-demand evaluation of function parameters. Since the called function is already proceeding when the actual parameters are evaluated (and no compensatory mechanism like invocation-time frame reference is built in), the actual parameters are evaluated with respect to the binding environment of the *called* function instead of that of the caller. This is entirely contrary to binding transparency, and when there is a name conflict between actual parameters and function locals the locals will obscure the value of the parameters being passed in. (There is also a problem with purely localized variables names remaining interned (eg for command-completion to find) even after the variables are no longer extant; this problem is shared by gnuemacs, though.) Mike Gallaher of Unipress comments: > > This is indeed one of the most confusing subtleties of MLisp. (It wasn't > even documented anywhere before V2.10!) Once you understand what is going > on, it is not hard to avoid problems. The MLisp coding guidelines > (doc/mlisp-std) recommend that local variable names be prefixed by some > string unique to the function it is defined in. For instance, a function > called describe-moused-word might have a variable $dmw-count. (The '$' is > a naming convention indicating that it is a local variable.) > > Also, be careful about evaluating args that may depend on which buffer is > current, or where the region is, etc. For instance, suppose you have > [...] > Once you come to properly love MLisp, you will realize that you wouldn't > want it to be any other way. :-) > > Mike Gallaher > Unipress Software I supose that last comment was appropos of the buffer specific bindings, not the parameter-passing defect! Even if you go to extremes to give function variables distinctive names you will have variable name collisions when a function is called somewhere within its own scope (ie recursively)! My feelings: In general it's a blast to program in a lisp like emacs-language environment, but the closer the language is to "genuine" lisp the better. I know i can expect to be able implement straightforward problems in straightforward ways in GNU Emacs lisp ('elisp') - and i can't expect that with Mlisp. The binding scheme is important. even miniscule details in the binding scheme of any language have pervasive consequences, and the defect in Mlisp, subtle (though definitely not miniscule!) on its face, can be very insidious and have enourmous impact on applications. You lose recursion and function-call abstraction ("now what variable names do i have to avoid using this time?") to the Mlisp binding bug. (Incidentally, you also don't have another essential feature of lisp in Mlisp, list data structures, so you have no efficient way to organize objects bigger than single characters (which you can deal with using the one data structure in Mlisp, strings). These are *not* trivial irritations. (BTW, re the fun-arg exacerbation when debugging, has anyone else modified the old version of the emacs debugger, where the filename formal parameter was called something like 'fn'? Damn, did i have some awful problems when debugging mlisp library functions that used the same variable name! On the other hand, though, that debugger is much nicer than the GNU Emacs debugger just for the on-source stepping it provides - if only the coupling of filenames to functions was cleaner... Any GNU Emacsers know of a comparable system for gnuemacs (maybe extensions of the standard debugger)? I'd love to get my hands on screen-oriented source-code debugger (like Unipress/GosMacs') for that Emacs! RMS? For that matter (Unipress), are there any plans to implement binding-frames (or something) in mlisp to solve the binding problem in GosMacs? We never received our update here ("doc/mlisp-std"??), so i may be out of date on my criticisms. (Though if i was neglected on a maintenance distribution then i have another bone to pick, don't i...-) Wrimbly, Ken Manheimer. ...!seismo!nbs-amrf!manheime
manheime@nbs-amrf.UUCP (Ken Manheimer) (08/01/86)
> [Excerpt from my prior article:] > (Incidentally, you also don't have another essential feature of > lisp in Mlisp, list data structures, so you have no efficient way > to organize objects bigger than single characters (which you can > deal with using the one data structure in Mlisp, strings). On a little further thought it occurred to me that the text buffers (and all their paraphenalia, eg marks) can be considered to be data structures of Emacs lisps, so that mlisp isn't just confined to strings. None the less, a list data structure (and oblists, arrays, plists, ...) is crucial. Ken.