6.1 Metafunction Mu The reader might have noticed that in our language as it has been defined up to this point, there were no means to apply a function whose name is not given explicitly but is the value of some variable or a result of computation. According to the syntax of Refal, after an opening activation bracket a symbolic function name (identifier) must necessarily follow. This requirement, which of course, is introduced for the purpose of efficient implementation, prevents us from using expressions such as: <sF eX> <Mu sF eX>
Mu { sF eX = <sF eX> } Using Mu we can define various kinds of interpreterswhich use expressions as programs specifying which of the lower-level functions (functions-executors) must be called. Here is a simple example of an interpreter which sequentially applies a given list of operations to a given argument: Use-seq The modular structure of programs in Refal-5 brings a slight complication to the simple idea of Mu . Suppose you have used the function Mu to define some function Callmu in one module and then use Callmuas en external function in another module. It may happen that some function name is used in both modules to define different local functions. Which of the functions must be called then by Mu ? Specifically, consider the following two modules -- Mod1 : * This module is the main module Mod1. * This auxiliary module is Mod2. It defines We can define two versions of the metafunction Mu : Mu-Static MuS , and Mu-Dynamic MuD . With the static definition, the functional meaning of a symbolic name is defined by the module where the function using MuSis written; in our case this is Mod2 . The general rule is: wherever a call of MuS appears, it can activate only a function visible from this point (i.e., either locally defined or entering an $EXTERN list), and the function called will be the one defined at that point. With the dynamic definition, the functional meaning of a symbolic name is as defined at the execution time, i.e., in the main module: Mod1 in our case. Let us execute: refgo Mod1+Mod2 Mu: Mod1 Mu: Mod1 There is something to be said both for and against each of the ways to define Mu . The dynamic definition seems more natural and it sticks to the general principle: if a function is not visible from the main module, it cannot be activated. On the other hand, from the systems viewpoint it is good to be able to call any function of the program, if necessary. MuD does not allow this while MuS does. Indeed, let the names of the modules we are using be Mod1 , Mod2 , Mod3 , etc. In Mod1 we define: $ENTRY Mu-Mod1 { e1 = <Mu e1> } $ENTRY Mu-Mod2 { e1 = <Mu e1> } $ENTRY MuD { e1 = <Mu e1> } Having this in mind, the built-in function Mu has been defined statically in our Refal system. <Fun-n 12 'ABC'> becomes <Fun12 'ABC'> |