Sorry for the semi-bogus origin address. I forgot my password to my mail account and I won't post it from work for various reasons.
>In the past I have thought about creating a context or 'environment'.
>The problem is it does not follow the model of ColdC very well.
It definitely falls outside ColdC's traditional idea of scope, and dynamically-scoped variables appear mutable in this respect, though they're not really so. Were you to pass a dynamically scoped var as an arg, it would pass a new reference which would overshadow the original, which you might do if you wanted to revert its value in recursive routines. Unlike my previous example, I don't see any practical applications of that, so I don't have examples.
>leave it up to Bruce to wrestle with this issue, however :) Also, in
>your example you are essentially wanting global variables--but globals
>which are defined by limited scope methods.
No, I'm talking about dynamic scope. Vars that are dynamically scoped are inherited by any enclosed scopes, but not their enclosing scopes, so the term environment variable is something of a misnomer unless you think in terms of running every method in a subshell. Dynamically scoped vars can be overshadowed by locals if one doesn't care about inheriting the value.
> The problem here is the
>execution state becomes very contextual. How is the method
>.mygrin_cmd (using your example) supposed to know that 'loc' is
>defined in .grin_cmd?
It's not. mygrin_cmd doesn't care. It's basically an alias for the social feature, and with an FO/command-package system, you don't even need .mygrin_cmd at all. Since neither .mygrin_cmd nor its enclosing scope doesn't export loc, social.grin_cmd uses the default value. Cold lacks the "default value" operator of moo's scattering assign, so "(| loc |) == ~varnf && (loc = blah)" would have probably have been more appropriate (personally I like "defined loc or loc = blah" but I don't think we'll ever see perl idioms :)
> Should the interpreter just scan forward to the
>next method, load it up and check to see if it defines any globals?
>As you can see, this could get to be quite scary :)
No, because they're not globals nor does any language I have ever encountered attempt this bizaare behavior. No, they're inherited from enclosing scopes, and they're even declared as dynamic, so you go back through the stack and find the var slot for that var that is marked dynamic. Alternately you can do what MOO does and push the dynamically scoped vars to each new frame (in MOO those are argstr, dobj, iobj, prepstr, and player, the last requiring wizperms to acquire dynamic behavior). Or the table can be factored out of the stack into a separate data structure associated with the task. Several choices, really, none of which involve looking ahead.
>
>Actually, it is just an issue of design. I see what you are trying to
>do, but I dont find it to be a good argument for environmental
>settings :) Since in your example you are already wrapping the
>command, why not just add an extra option syntax that can be used
>to specify alternate behaviour (i.e. the location/channel). Infact,
>just do it with optional arguments (oob_arg, as in out-of-bounds...
>something that wouldn't normally come from the interpreter):
If cold supported named optional args, this might be feasable but still onerous since once I handed it off once, everything has to pass it off, use it or not. As it doesn't, it requires modifying every single method that might use assumptions about the environment that may need to be modified, having every single inbetween method pass it on, making pretty much every single method connected to VR behavior require extra args and modifying every single caller to explicitly pass them. This is no exaggeration. The grin social was a simple example. E_MOO's feature system supports features with features with features ad infinitum, each one changing the context of location, player, and object in nested fashion. I won't even get into the future project of matching by memory ("look foo" => "whoops, munchkin picked up foo", "look munchkin" => "munchkin left a couple minutes ago and went to the living room"). Suffice to say that it places your being elsewhere temporarily.
Extra args are simply not an acceptable solution, E_MOO's feature system and incompatibilities with the rest of the command system are proof of this.
-- scrytch
|