;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Introduction to Evaluation =Text: 3INTRODUCTION TO EVALUATION* The following is a complete description of the actions taken by the evaluator, given a 1form* to evaluate. If 1form* is a number, the result is 1form*. If 1form* is a string, the result is 1form*. If 1form* is a self-evaluating symbol (2nil*, 2t* or a keyword such as 2:foo*), then 1form* itself is the result. If 1form* is any other symbol, the result is the value of 1form*, considered as a variable. If 1form*'s value is void, an error is signaled. The way symbols are bound to values is explained in 4(EVAL-1)Variables and Bindings* below. If 1form* is not any of the above types, and is not a list, 1form* itself is the result. In all remaining cases, 1form* is a list. The evaluator examines the car of the list to figure out what to do next. There are three possibilities: this form may be a 1special form*, a 1macro form*, or a plain old 1function form*. If the car is an explicit function such as a list starting with 2lambda*, the form is a function form. If it is a symbol, things depend on the symbol's function definition, which may be a special form definition (see 4(FUNCTIONS-1)Special Forms and Functions*), a macro definition, or an ordinary function. If 1form* is a special form, then it is handled accordingly; each special form works differently. All of them are documented in this manual. The internal workings of special forms are explained in more detail on 4(FUNCTIONS-1)Special Forms and Functions*, but this hardly ever affects you. If 1form* is a macro form, then the macro is expanded as explained in chapter 4(MACROS-0)Macros*. If 1form* is a function form, it calls for the 1application* of a function to 1arguments*. The car of 1form* is a function or the name of a function. The cdr of 1form* is a list of subforms. The subforms are evaluated, sequentially, and each produces one argument for the function. The function is then applied to those arguments. Whatever results the function returns are the values of the original 1form*. There is a lot more to be said about evaluation. The way variables work and the ways in which they are manipulated, including the binding of arguments, is explained in 4(EVAL-1)Variables and Bindings*. A basic explanation of functions is in 4(FUNCTIONS-0)Functions*. The way functions can return more than one value is explained in 4(EVAL-4)Multiple Values*. The description of all of the kinds of functions, and the means by which they are manipulated, is in chapter 4(FUNCTIONS-0)Functions*. Macros are explained in chapter 4(MACROS-0)Macros*. The 2evalhook* facility, which lets you do something arbitrary whenever the evaluator is invoked, is explained in 4(DEBUGGING-6)Evalhook*. Special forms are described all over the manual; each special form is in the section on the facility it is part of. =Node: Introduction to Variables =Text: 3INTRODUCTION TO VARIABLES* In Zetalisp, variables are implemented using symbols. Symbols are used for many things in the language, such as naming functions, naming special forms, and being keywords; they are also useful to programs written in Lisp, as parts of data structures. But when a symbol is evaluated, its value as a variable is taken. =Node: Variables and Bindings =Text: 3VARIABLES AND BINDINGS* There are two different ways of changing the value of a variable. One is to 1set* the variable. Setting a variable changes its value to a new Lisp object, and the previous value of the variable is forgotten. Setting of variables is usually done with the 2setq* special form. The other way to change the value of a variable is with 1binding* (also called 1lambda-binding*). We say that a variable is 1bound* (past participle of active verb) by the action of binding; we also say that the variable is 1bound* (state of being) after a binding has been made. When a binding is made, the variable's old binding and value are hidden or 1shadowed* by a new binding, which holds a new value. Setting a variable places a new value into the current binding; it does not change which binding is current. In addition, shadowed bindings' values are not affected by setting the variable. Binding a variable does not affect the value in the old current binding but that binding ceases to be current so the value no longer applies. The action of binding is always followed eventually by the action of unbinding. This discards the current binding of the variable, with its value. The previous binding becomes current again, and the value in it--unchanged since the newer binding was made, in normal operation--is visible again. Binding is normally done on entry to a function and by certain special forms (2let*, 2do*, 2prog* and others). The bindings are unbound on exit from the function or the special form, even nonlocal exit such as 2go*, 2return* or 2throw*. The function or special form is said to be the 1scope* of the bindings made therein. Here is a simple example of making a binding, shadowing it, unshadowing it, examining it, and unbinding it. The inner, shadowing binding is made, examined, set, examined and unbound. 3(let ((a 5))* 3 (print a) 2;prints 5** 3 (let ((a "foo"))* 3 (print a) 2;prints "foo"** 3 (setq a "bar")* 3 (print a)) 2;prints "bar"** 3 (print a)) 2;prints 5** Every symbol has one binding which was never made and is never unbound. This is the 1global* binding. This binding is current whenever no other binding has been established that would shadow it. If you type 2(setq x 5)* in the Lisp listen loop, you set the global binding of 2x*. Programs often set global bindings permanently using 2defvar* or one of its cousins (4(EVAL-1)Defining Global Variables*). 2setq-globally* and related functions can be used to set or refer to the global binding even when it is shadowed (4(EVAL-1)The Global Binding*). 3(defvar a 5) ;2sets the global binding** 3(let ((a t))* 3 (print a)) ;2prints t** 3a => 5 ;2the global binding is visible again** A binding does not need to have an actual value. It can be 1void* instead. The variable is also called void. Actually, a void binding contains a weird internal value, which the system interprets as meaning ``there is no value here''. (This is the data type code 2dtp-null*, 4(PRIMOBJTYPE-1)Data Types*). Reference to a variable whose current binding is void signals an error. In fact, nearly all variables' global bindings are void; only those that you or the system have set are not void. 2variable-makunbound* makes the current binding of a variable void again (4(EVAL-1)Setting Variables*). `Void' used to be called `unbound', and most function names, error messages and documentation still use the term `unbound'. The variable is also called `unbound'. The term `void' is being adopted because it is less ambiguous. `Unbound' can mean `void', or `not bound' (no binding established), or the past participle of `unbind'. All bindings except global binding have a limited scope: one function or special form. This does not fully specify the scope, however: it may be 1lexical* or 1dynamic*. When a binding has lexical scope, it is visible only from code written within the function or special form that established it. Subroutines called from within the scope, but which are written elsewhere, never see the lexical binding. By contrast, a dynamic binding is visible the whole time it exists (except when it is shadowed, of course), which includes time spent in subroutines called from within the binding construct. The global binding of a symbol can be regarded as a dynamic binding that lasts from the beginning of the session to the end of the session. Lexical and dynamic bindings are made by the same kinds of function definitions and special forms. By default, the bindings are lexical. You request a dynamic binding instead using a 1special-declaration* at the beginning of the body of the function definition or special form. Also, some symbols are marked 1globally special*; every binding of such a symbol is dynamic. This is what 2defvar*, etc., do to a symbol. Dynamic bindings are also called 1special bindings*, and the variable bound is called a 1special variable*. Each use of a symbol as a variable (this includes setting as well as examining) is also marked as lexical or dynamic by the same declarations. A dynamic use sees only dynamic bindings, and a lexical use sees only lexical bindings. In the examples above it makes no difference whether the bindings of 2a* are lexical or dynamic, because all the code executed between the binding and unbinding is also written lexically within the 2let* which made the binding. Here is an example where it makes a difference: 3(defun foo ()* 3 (print a))* 3(let ((a 5))* 3 (foo))* 3>>Error: the variable A is used free but not special.* If the intention is that 5 be printed, a dynamic binding is required. A dynamic binding would remain visible for all the execution from the entry to the 2let* to the exit from the 2let*, including the execution of the definition of 2foo*. Actually, the default is to do lexical binding. Since the binding of 2a* is lexical, it is visible only for the evaluation of expressions written inside the 2let*, which does not include the body of 2foo*. In fact, an error happens when 2foo* evaluates 2a*, since 2a* there is supposed to be lexical and no lexical binding is visible. If you compile 2foo*, you get a compiler warning about 2a*. The use of 2a* inside 2foo*, not lexically within any binding of 2a*, is called 1free*, and 2a* is called a 1free variable* of 2foo*. Free variables are erroneous unless they are special. Strictly speaking, it is erroneous to type 2(setq x 5)* at top level in the Lisp listener if 2x* has not been made globally special, but this is permitted as an exception because it is so often useful. One way to make the example work is to make 2a* globally special: 3(defvar a)* 3(defun foo () (print a))* 3(let ((a 5))* 3 (foo))* prints 5. The global specialness of 2a* tells 2let* to make a dynamic binding and tells the evaluation of 2a* in 2foo* to look for one. Another way is with declarations at the point of binding and the point of use: 3(defun foo ()* 3 (declare (special a))* 3 (print a))* 3(let ((a 5))* 3 (declare (special a))* 3 (foo))* A declaration at the point of binding affects only that binding, not other bindings made within it to shadow it. Another way of stating this is that a binding is affected only by a declaration in the construct that makes the binding, not by declarations in surrounding constructs. Thus, 3(let ((a 5)) ;2this binding is dynamic** 3 (declare (special a))* 3 (let ((a "foo")) ;2this binding is lexical** 3 1no declaration here** 3 ... a ... ;2this reference is lexical since** 3 ... ;2 the innermost binding is lexical** 3 (let ()* 3 (declare (special a))* 3 ... a ... ;2this reference is dynamic, and sees value 5** 3 ...))* [Currently, for historical compatibility, bindings 1are* affected by surrounding declarations. However, whenever this makes a difference, the compiler prints a warning to inform the programmer that the declaration should be moved.] The classical case where dynamic binding is useful is for parameter variables like 2*read-base**: 3(let ((*read-base* 16.))* 3 (read))* reads an expression using hexadecimal numbers by default. 2*read-base** is globally special, and the subroutine of 2read* that reads integers uses 2*read-base** free. Here is an example where lexical bindings are desirable: 3(let ((a nil))* 3 (mapatoms (function (lambda (symbol) (push symbol a))))* 3 a)* Because the reference to 2a* from within the internal function is lexical, the only binding it can see is the one made by this 2let*. 2mapatoms* cannot interfere by binding 2a* itself. Consider: if 2mapatoms* makes a lexical binding of 2a*, it is not visible here because this code is not written inside the definition of 2mapatoms*. If 2mapatoms* makes a dynamic binding of 2a*, it is not visible here because the reference to 2a* is not declared special and therefore sees only lexical bindings. The fact that 2function* is used to mark the internal function is crucial. It causes the lexical environment appropriate for the function to be combined with the code for the function in a 1lexical closure*, which is passed to 2mapatoms*. The last example shows 1downward* use of lexical closures. 1Upward* use is also possible, in which a function is closed inside a lexical environment and then preserved after the binding construct has been exited. 3(defun mycons (a d)* 3 (function (lambda (x)* 3 (cond ((eq x 'car) a)* 3 ((eq x 'cdr) d)))))* 3(defun mycar (x) (funcall x 'car))* 3(defun mycdr (x) (funcall x 'cdr))* 3(setq mc (mycons 4 t))* 3(mycar mc) => 4* 3(mycdr mc) => t* 2mycons* returns an object that can be called as a function with one argument. This object retains a pointer to a lexical environment that has a binding for 2a* and a binding for 2d*. The function 2mycons* that made those bindings has been exited, but this is irrelevant because the bindings were not dynamic. Since the code of the lambda-expression is lexically within the body of 2mycons*, that function can see the lexical bindings made by 2mycons* no matter when it is called. The function returned by 2mycons* records two values and can deliver either of them when asked, and is therefore analogous to a cons cell. Only lexical bindings are transferred automatically downward and upward, but dynamic bindings can be used in the same ways if explicitly requested through the use of the function 2closure*. See 4(CLOSURES-0)Closures* for more information. Dynamic bindings, including the global binding, are stored (unless shadowed) in a particular place: the symbol's 1value cell*. This is a word at a fixed offset in the symbol itself. When a new dynamic binding is made, the value in the value cell is saved away on a stack called the 1special pdl*. The new binding's value is placed in the value cell. When the new binding is unbound, the old binding's value is copied off of the special pdl, into the value cell again. The function 2symeval* examines the value cell of a symbol chosen at run time; therefore, it sees the current dynamic binding of the symbol. Lexical bindings are never stored in the symbol's value cell. The compiler stores them in fixed slots in stack frames. The interpreter stores them in alists that live in the stack. It should be noted that if the lexical binding is made by compiled code, then all code that ought to see the binding is necessarily also compiled; if the binding is made by interpreted code, then all code that ought to see the binding is necessarily interpreted. Therefore, it is safe for the compiler and interpreter to use completely different techniques for recording lexical bindings. Lexical binding is the default because the compiler can find with certainty all the places where a lexical binding is used, and usually can use short cuts based on this certainty. For dynamic bindings slow but general code must always be generated. =Node: Setting Variables =Text: 3SETTING VARIABLES* Here are the constructs used for setting variables. 3setq* 1{variable* 1value}...* 1Special Form* The 2setq* special form is used to set the value of a variable or of many variables. The first 1value* is evaluated, and the first 1variable* is set to the result. Then the second 1value* is evaluated, the second 1variable* is set to the result, and so on for all the variable/value pairs. 2setq* returns the last value, i.e. the result of the evaluation of its last subform. Example: 3(setq x (+ 3 2 1) y (cons x nil))* 2x* is set to 26*, 2y* is set to 2(6)*, and the 2setq* form returns 2(6)*. Note that the first variable was set before the second value form was evaluated, allowing that form to use the new value of 2x*. 3psetq* 1{variable* 1value}...* 1Macro* A 2psetq* form is just like a 2setq* form, except that the variables are set ``in parallel''; first all of the 1value* forms are evaluated, and then the 1variables* are set to the resulting values. Example: 3(setq a 1)* 3(setq b 2)* 3(psetq a b b a)* 3a => 2* 3b => 1 variable-location* 1symbol* 1Special Form* Returns a locative to the cell in which the value of 1symbol* is stored. 1symbol* is an unevaluated argument, so the name of the symbol must appear explicitly in the code. For a special variable, this is equivalent to 3(value-cell-location '1symbol*)* For a lexical variable, the place where the value is stored is a matter decided by the interpreter or the compiler, but in any case 2variable-location* nevertheless returns a pointer to it. In addition, if 1symbol* is a special variable that is closed over, the value returned is an external value cell, the same as the value of 2locate-in-closure* applied to the proper closure and 1symbol*. This cell 1always* contains the closure binding's value, which is 1current* only inside the closure. See 4(CLOSURES-1)What a Closure Is*. 3variable-boundp* 1symbol* 1Special Form* 2t* if variable 1symbol* is not void. It is equivalent to 3(location-boundp (variable-location 1symbol*))* 1symbol* is not evaluated. 3variable-makunbound* 1symbol* 1Special Form* Makes 1symbol*'s current binding void. It is equivalent to 3(location-makunbound (variable-location 1symbol*))* 1symbol* is not evaluated. =Node: Variable Binding Constructs =Text: 3VARIABLE BINDING CONSTRUCTS* Here are the constructs used for binding variables. 3let* 1((var* 1value)...)* 1body...* 1Special Form* Is used to bind some variables to some objects, and evaluate some forms (the body) in the context of those bindings. A 2let* form looks like 3(let ((1var1* 1vform1*)* 3 (1var2* 1vform2*)* 3 ...)* 3 1bform1** 3 1bform2** 3 ...)* When this form is evaluated, first the 1vforms* (the values) are evaluated. Then the 1vars* are bound to the values returned by the corresponding 1vforms*. Thus the bindings happen in parallel; all the 1vforms* are evaluated before any of the 1vars* are bound. Finally, the 1bforms* (the body) are evaluated sequentially, the old values of the variables are restored, and the result of the last 1bform* is returned. You may omit the 1vform* from a 2let* clause, in which case it is as if the 1vform* were 2nil*: the variable is bound to 2nil*. Furthermore, you may replace the entire clause (the list of the variable and form) with just the variable, which also means that the variable gets bound to 2nil*. Example: 3(let ((a (+ 3 3))* 3 (b 'foo)* 3 (c)* 3 d)* 3 ...)* Within the body, 2a* is bound to 26*, 2b* is bound to 2foo*, 2c* is bound to 2nil*, and 2d* is bound to 2nil*. 3let** 1((var* 1value)...)* 1body...* 1Special Form* 2let** is the same as 2let* except that the binding is sequential. Each 1var* is bound to the value of its 1vform* before the next 1vform* is evaluated. This is useful when the computation of a 1vform* depends on the value of a variable bound in an earlier 1vform*. Example: 3(let* ((a (+ 1 2))* 3 (b (+ a a)))* 3 ...)* Within the body, 2a* is bound to 23* and 2b* is bound to 26*. 3let-if* 1condition* 1((var* 1value)...)* 1body...* 1Special Form* 2let-if* is a variant of 2let* in which the binding of variables is conditional. The 2let-if* special form, typically written as 3(let-if 1cond** 3 ((1var-1* 1val-1*) (1var-2* 1val-2*)...)* 3 1body*...)* first evaluates the predicate form 1cond*. If the result is non-2nil*, the value forms 1val-1*, 1val-2*, etc. are evaluated and then the variables 1var-1*, 1var-2*, etc. are bound to them. If the result is 2nil*, the 1vars* and 1vals* are ignored. Finally the body forms are evaluated. The bindings are always dynamic, and it is the user's responsibility to put in appropriate declarations so that the body forms consider the variables dynamic. 3let-globally* 1((var* 1value)...)* 1body...* 1Macro* 3let-globally-if* 1condition* 1((var* 1value)...)* 1body...* 2let-globally* is similar in form to 2let* (see 4(EVAL-1)Variable Binding Constructs*). The difference is that 2let-globally* does not 1bind* the variables; instead, it saves the old values and 1sets* the variables, and sets up an 2unwind-protect* (see 4(FLOWCTL-2)Dynamic Non-Local Exits*) to set them back. The important consequence is that, with 2let-globally*, when the current stack group (see 4(STACKGROUPS-0)Stack Groups*) co-calls some other stack group, the old values of the variables are 1not* restored. Thus 2let-globally* makes the new values visible in all stack groups and processes that don't bind the variables themselves, not just in the current stack group. Therefore, 2let-globally* can be used for communication between stack groups and between processes. 2let-globally-if* modifies and restores the variables only if the value of 1condition* is non-2nil*. The 1body* is executed in any case. Since 2let-globally* is based on 2setq*, it makes sense for both lexical and dynamic variables. But its main application exists only for dynamic variables. The 2globally* in 2let-globally* does not mean the same thing as the 2globally* in 2setq-globally* and related functions. 3progv* 1symbol-list* 1value-list* 1body...* 1Special Form* 2progv* is a special form to provide the user with extra control over binding. It binds a list of variables dynamically to a list of values, and then evaluates some forms. The lists of variables and values are computed quantities; this is what makes 2progv* different from 2let*, 2prog*, and 2do*. 2progv* first evaluates 1symbol-list* and 1value-list*, and then binds each symbol to the corresponding value. If too few values are supplied, the remaining symbols' bindings are made empty. If too many values are supplied, the excess values are ignored. After the symbols have been bound to the values, the 1body* forms are evaluated, and finally the symbols' bindings are undone. The result returned is the value of the last form in the body. Assuming that the variables 2a*, 2b*, 2foo* and 2bar* are globally special, we can do: 3(setq a 'foo b 'bar)* 3(progv (list a b 'b) (list b)* 3 (list a b foo bar))* 3 => (foo nil bar nil)* During the evaluation of the body of this 2progv*, 2foo* is bound to 2bar*, 2bar* is bound to 2nil*, 2b* is bound to 2nil*, and 2a* retains its top-level value 2foo*. 3progw* 1vars-and-vals-form* 1body...* 1Special Form* 2progw* is like 2progv* except that it has a different way of deciding which variables to bind and what values to give them. Like 2progv*, it always makes dynamic bindings. First, 1vars-and-val-forms-form* is evaluated. Its value should be a list that looks like the first subform of a 2let*: 3 ((1var1* 1val-form-1*)* 3 (1var2* 1val-form-2*)* 3 ...)* Each element of this list is processed in turn, by evaluating the 1val-form* and binding the 1var* dynamically to the resulting value. Finally, the 1body* forms are evaluated sequentially, the bindings are undone, and the result of the last form is returned. Note that the bindings are sequential, not parallel. This is a very unusual special form because of the way the evaluator is called on the result of an evaluation. 2progw* is useful mainly for implementing special forms and for functions part of whose contract is that they call the interpreter. For an example of the latter, see 2sys:*break-bindings** (4(MISCELL-2)The Lisp Listen Loop*); 2break* implements this by using 2progw*. See also 2%bind* (4(SUBPRIMITIVES-2)Special-Binding Subprimitive*), which is a subprimitive that gives you maximal control over binding. =Node: Defining Global Variables =Text: 3DEFINING GLOBAL VARIABLES* Here are the constructs for defining global variables. Each makes the variable globally special, provides a value, records documentation, and allows the editor to find where all this was done. 3defvar* 1variable* 1[initial-value]* 1[documentation]* 1Macro* 2defvar* is the recommended way to declare the use of a global variable in a program. Placed at top level in a file, 3(defvar 1variable* 1initial-value* * 3 "1documentation*")* declares 1variable* globally special and records its location in the file for the sake of the editor so that you can ask to see where the variable is defined. The documentation string is remembered and returned if you do 2(documentation '1variable* 'variable)*. If 1variable* is void, it is initialized to the result of evaluating the form 1initial-value*. 1initial-value* is evaluated only if it is to be used. If you do not wish to give 1variable* any initial value, use the symbol 2:unbound* as the 1initial-value* form. This is treated specially; no attempt is made to evaluate 2:unbound*. Using a documentation string is better than using a comment to describe the use of the variable, because the documentation string is accessible to system programs that can show the documentation to you while you are using the machine. While it is still permissible to omit 1initial-value* and the documentation string, it is recommended that you put a documentation string in every 2defvar*. 2defvar* should be used only at top level, never in function definitions, and only for global variables (those used by more than one function). 2(defvar foo 'bar)* is roughly equivalent to 3(declare (special foo))* 3(if (not (boundp 'foo))* 3 (setq foo 'bar))* If 2defvar* is used in a patch file (see 4(SYSTEMS-2)The Patch Facility*) or is a single form (not a region) evaluated with the editor's compile/evaluate from buffer commands, if there is an initial-value the variable is always set to it regardless of whether it is void. 3defconst* 1variable* 1initial-value* 1[documentation]* 1Macro* 3defparameter* 1variable* 1initial-value* 1[documentation]* 2defconst* is the same as 2defvar* except that if an initial value is given the variable is always set to it regardless of whether it is already bound. The rationale for this is that 2defvar* declares a global variable, whose value is initialized to something but will then be changed by the functions that use it to maintain some state. On the other hand, 2defconst* declares a constant, whose value will be changed only by changes 1to* the program, never by the operation of the program as written. 2defconst* always sets the variable to the specified value so that if, while developing or debugging the program, you change your mind about what the constant value should be, and then you evaluate the 2defconst* form again, the variable gets the new value. It is 1not* the intent of 2defconst* to declare that the value of 1variable* will never change; for example, 2defconst* is 1not* a license to the compiler to build assumptions about the value of 1variable* into programs being compiled. As with 2defvar*, you should include a documentation string in every 2defconst*. 3defconstant* 1symbol* 1value* 1[documentation]* 1Macro* Defines a true constant. The compiler is permitted to assume it will never change. Therefore, if a function that refers to 1symbol*'s value is compiled, the compiled function may contain 1value* merged into it and may not actually refer to 1symbol* at run time. You should not change the value of 1symbol* except by reexecuting the 2defconstant* with a new 1value*. If you do this, it is necessary to recompile any compiled functions that refer to 1symbol*'s value. =Node: The Global Binding =Text: 3THE GLOBAL BINDING* This section describes functions which examine or set the global binding of a variable even when it is shadowed and cannot be accessed simply by evaluating the variable or setting it. The primary use of these functions is for init files to set variables which are bound by the 2load* function, such as 2package* or 2base*. 2(setq package (find-package 'foo))* executed from a file being loaded has no effect beyond the end of loading that file, since it sets the binding of 2package* made by 2load*. However, if you use 2setq-globally* instead, the current binding in effect during loading is actually not changed, but when the 2load* exits and the global binding is in effect again, 2foo* will become the current package. 3setq-globally* 1{symbol* 1value}...* 1Macro* Sets each 1symbol*'s global binding to the 1value* that follows. The 1value*'s are evaluated but the 1symbol*'s are not. 3set-globally* 1symbol* 1value* Sets the global binding of 1symbol* to 1value*. 3makunbound-globally* 1symbol* Makes the global binding of 1symbol* be void. 3boundp-globally* 1symbol* Returns 2t* if the global binding of 1symbol* is not void. 3symeval-globally* 1symbol* 3symbol-value-globally* 1symbol* Return the value of the global binding of 1symbol*. An error is signaled if the global binding is void. See also 2pkg-goto-globally* (4(PACKAGES-1)The Current Package*), a ``globally'' version of 2pkg-goto*. Note that 2let-globally* is 1not* analogous to these functions, as it modifies the current bindings of symbols rather than their global bindings. This is an unfortunate collision of naming conventions.