One theme from the last chapter is that most everything in Yazoo conforms to a single syntax. For example, all objects use the same define operators. We can access the members of any composite object -- function, classes, whatever -- using the same index and member operators. Et cetera. We need to take these apparent similarities at face value. As a general rule: two things in Yazoo that look the same, smell the same and should be different, are probably really the same. By the end of this section, the reader should be persuaded that all Yazoo objects that are not primitive variables --- this includes composite variables, sets, and classes --- these animals are all of the same species. They are all (for lack of a better word) functions.
To begin with, let's dispel any notion that Yazoo has things called `data types' or `classes'; these are both really just composite variables. (We have already done all of this in various places in the last chapter, but it is worth repeating.) A data type is just a class with no member functions -- Yazoo makes no distinction whatsoever between these two objects. It is a little bit less obvious why a class should be the same as a variable, but consider the following two equivalent ways of creating a variable:
my_class :: { ... }
var1 :: my_class
versus simply
var1 :: { ... }
The second method creates the variable var1 directly, using precisely the same syntax that generated my_class in the first method. Therefore my_class must also be a variable. Indeed all supposed data types and classes are really just composite variables. The reason that Yazoo is able to get away without explicit type-objects is that any variable can be used as a template for defining other variables; the code that defined the first is simply copied into the new variable. For example, after either definition of var1 we could then spawn off another variable by writing:
var2 :: var1
Now let's wade into slightly deeper waters: a composite variable is the same as a function constructor. This implies that a variable can be thought of as a function without code. Let's create some function:
frac :: {
num :: denom :: double
code
return num / denom
}
and strip away the coding section:
frac :: {
num :: denom :: double
}
This is nothing more than a composite variable (or class -- call it what you like). Indeed, when we created the frac() function it was this first chunk of code that generated the original function object. And in all respects this object works the same as any variable: we can read and write, add and delete members, etc. The only difference is that this function object has a coding section, which we can run by calling the function.
For that matter, it is also legal to `run' composite variables and classes. It's just that nothing happens since their definitions lack a coding section.
In a similar vein, we can find two other kinds of Yazoo thing that maybe don't show much resemblance with functions or variables, but do look quite a bit like one another. These are sets and function arguments. Compare the contents within the braces of a set:
ToBuy :: { groceries, "bird", supplies("school") }
to what's inside the parentheses of a function call:
buy( groceries, "bird", supplies("school") )
They are identical. Not only that, but the syntax for accessing a function argument (`args[1]') is the same as the summons for an element of a set (`ToBuy[1]'). So it should be no surprise that these two things are one and the same: a function's arguments are really a set.
We now only have to merge our two piles: sets and function arguments are really just functions and variables in disguise. In a sense this shouldn't be surprising: we know from the last chapter that args may contain a code marker or semicolon and be run as a function in its own right. But it is not completely obvious how this can work, because we need to apply two syntactic rules to transform a set into something that looks like a variable (or function).
The first rule is that a comma breaks a Yazoo sentence just as well as the standard end-of-line does. Thus our demo set could have been written:
ToBuy :: {
groceries
"bird"
supplies("school")
}
To understand the second rule, which is new, it is helpful to compare the set with an equivalent composite variable:
TB_var :: {
mb1 := @groceries
mb2 := "bird"
mb3 := @supplies("school")
}
The three members of this variable contain or alias the same three objects that are in the set, and in the same order. Therefore `ToBuy[1]' is the same as `TB_var[1]'. There is a difference between the variable and the set: the aliases of the variable have names, while the members (`tokens') of the set do not. But this is a difference between aliases and tokens, not a fundamental difference between sets and variables. We can have objects that contain both tokens and aliases:
ToBuy :: {
groceries
"bird"
for_Johnny := @supplies("school")
}
Recalling an earlier discussion on sets with named members, we could also have used the `:=' operator for either of the first two elements. Of course, since a set is really a composite variable we may construct it using any code we care to write, and since it is really a function we have the option of appending a coding section. (Whether or not that is good programming practice is entirely a separate question.)
The mystery of tokens has not yet been entirely resolved. We cannot see them in our scripts. We know that they are similar to aliases -- but, as it turns out, they are usually not quite the same. They are inventions of the Yazoo compiler, so we will get our first good look at them when we start examining compiled code in the next section.
Last update: July 28, 2013