4 ms·
There's certainly a few ways you could do that in Kernel, but I think doing this is less interesting than having to explicitly specify the environments to enter
by sparkie 11y ago
There's certainly a few ways you could do that in Kernel, but I think doing this is less interesting than having to explicitly specify the environments to enter to find loudly to begin with. I see other potential problems with just specifying loudly alone which we'd look to avoid up-front, or explicitly handle as part of the tree.
So for example if the cat were to become able to meow loudly, there would no longer be just one path into loudly, but we'd have two. Typically, we'd either make loudly a generic and specify (or infer) the type were referring to, or we'd have a dynamically-dispatched loudly which looks at say, the first argument and decides which one to execute. Both the these are trivial to implement as environments. However, the more interesting gain Kernel gives is that there is no way built into the language to enumerate the bindings in an environment (a deliberate omission).
We can walk through the tree as given in this example (using car and cdr), but if there were some binding "(mouse the-mouse)" added to the tree, where the-mouse is already an environment, and not a list of instructions to build a new environment, then we cannot walk through its sub-tree, which may contain bindings such as "loudly".
We can explicitly call ($binds? the-mouse loudly) to test this, iff "the-mouse" is an environment. This works by basically attempting to retreive the binding loudly and capturing the error thrown if it doesn't exist in the binding. In practice, we'd have a more interesting type for mouse, which contains an environment, but encapsulated (via make-encapsulation-type), with only predefined ways of accessing the bindings of the environment.
With this setup, a binding in an environment behaves much like a capability. By knowing the name of a binding, you have the capability to use it. Proper use of the environment and encapsulation types gives us the flexibility to tightly constrain who can see "loudly".
- javajosh 11y ago>However, the more interesting gain Kernel gives is that there is no way built into the language to enumerate the bindings in an environment (a deliberate omission). Why not throw an error, or perhaps return a curry that takes an integer picking between multiple 'loudly' options? Its true that such 'do-special' would need global read access to the entire program, which is perhaps what you want to avoid?
- sparkie 11y agoGlobal access to the entire problem is definitely what we want to avoid. Encapsulation is a useful tool for maintaning invariants, controlling access to data and so forth. We don't want to give it up, and we may not even be able to give it up to begin with. One way to consider an environment is that it may be a physical machine with a set of bindings, variables and processes on it, where some of the bindings point to other environments - ie, other machines. Then if you're a user of the tree, and you want to invoke loudly, there exists at least one other machine, dog, between yourself and bark. You obviously don't know what is on the bark machine because the dog mediates your access to it. You don't really have any access to it other than by sending a message to dog which asks it to send a message to bark. So the number of "loudly" options in such a network (ie, the internet) is potentially unbounded. The dog machine might know, by virtue of asking the machines it is directly connected to, whether the binding loudly exists, and it can chose to expose either the binding, or another message named loudly which discriminates between multiple loudly options if the other machines connected to it (aka, dynamic dispatch). In the example above, replace "$branch" with "$spawn" and "$walk" with "$send", and you effectively have the actor model, which is more like the OOP imagined by Kay and others. The fun part here would be to implement $spawn and $send though.
- javajosh 11y agoAh, you inspire the thought that we don't necessarily know what the valid inputs are to a distributed program! But realize that this problem will bite you even higher up the food chain (so to speak) because what if there is more than one dog node? What does your program do in that case?
- sparkie 11y agoAn environment can only bind a symbol to one expression, so the symbol "dog" in the tree environment is bound to an opaque reference to an environment (or machine), containing the dog's bindings. There can be many of these machines containing dog's bindings, but if you were to bind them all to dog, you would only have access to the most recently bound one, since binding a name in an environment overwrites any existing binding with a new one. The solution is therefore, that we must either use bindings such as "dog1", "dog2" and whatnot, or we have a binding "dogs" which binds a list of environment objects, which we can index to refer to a specific dog. Actually, "dogs" could itself just be an environment which binds specific dog's names, like spike to their respective environments ($define! dogs ($bindings->environment (spike ($spawn ...)) (charlie ($spawn ...)))) This might be less useful than a list though as there's no way to map over the dogs in an environment.