Muq path notation is deliberately modelled on the very successful unix filesystem path notation, which also appears to be well on its way to becoming a major Internet notation courtesy of WorldWideWeb/Mosaic's Uniform Resource Locators (URLs).
However, Muq path notation uses '.' as the path separator (following the lead of C, Java, Perl and Tcl) rather than '/' as in Uhix.
A valid muq path may begin with any of the following character sequences, with the indicated meaning:
. The "root object", that serving as global origin. @. The currently running job. me. The "acting user" for the currently running job. abc. The value of the symbol "abc" in the current package.
Given any valid path designating an object 'o' with a public key 'k' having value 'v', 'o.k' is a name for 'v'. For example:
.x Public property 'x' on the root object. @.x Public property 'x' on the currently running job. me.x Public property 'x' on the "acting user" for current job. abc.x Public property 'x' on the value of symbol "abc" in current pkg.
The above path-building process may be continued indefinitely:
.q.Cynbe The object stored as 'Cynbe' in the root directory 'q'. .q.Cynbe.tmp The object stored as 'tmp' on the above object. .q.Cynbe.tmp.x The object stored as 'x' on the above object.
Muq's key-access security mechanism is more closely related to traditional tinymuck than to that of unix, partly because the full unix system seemed too expensive in space. Muq actually provides four separate keyVal namepaces on each object:
A public namespace which is owner-writeable and world-readable. A hidden namespace which is only owner-readable and writeable. A system namespace which is root-writable and owner-readable. A admins namespace which is only admins-readable and writable.
Muq provides special path notation syntax for accessing key-value pairs in each of these namespaces:
me.x Access public property "x" on the acting user. me$hidden.x Access hidden property "x" on the acting user. me$system.x Access system property "x" on the acting user. me$admins.x Access admins property "x" on the acting user. me$method.x Access method property "x" on the acting user.
The $hidden, $system, $admins,
and $method suffixes may be applied to any valid
nonleaf object designator in a path:
myObj$hidden.key .$admins.key @$hidden.key .etc$hidden.key myObj$hidden.someKey$method.myMethod
Each suffix may be abbreviated to its three-letter or one-letter any prefix, and is case sensitive. Thus, the following are all equivalent:
obj$system.key obj$sys.key obj$s.key
You may not use such a suffix on a leaf object designator, because Muq has no way of actually returning a pointer to part of an object as the result of an expression. Thus, the following are all incorrect:
myObj$hidden .$admins @$hidden .etc$hidden myObj$hidden.someKey$method
Public properties are intended to be the most commonplace, hence are given the shortest path notation.
Hidden properties are intended to provide private storage for information an individual user does not wish to make publicly available, such as perhaps loveletter collections or email addresses.
System properties are intended to provide storage for properties controlled by the system but of interest to the owner of the object: Db space quotas, for example.
Admins properties are intended to provide storage for properties associated with the user or object but private to the system administrators, such as perhaps confidential gripes registered against the user. (It is desirable to store such on the user in order to ensure that they get recycled when the user does.)
Muq has also supports the syntax
x[y]
which returns the value on object 'x' of the property found in variable 'y': Think of the syntax as doing array indexing. (Both local variables and symbols may be used in this way.) Contrast the above example with
x.y
in which 'y' is the literal property name, rather than the name of a variable holding the property:
tmp: makeIndex --> o tmp: "x" --> key tmp: 12 --> o[key] tmp: 13 --> o.y tmp: o[key] tmp: 12 pop o.y tmp: 13
The bracket notation is also useful with various kinds of constants:
x[1] NOT the same as x.1 ! x[1.0] NOT the same as x.1.0 ! x["a"] NOT the same as x."a" !
The differences above lie in the fact that the x.yyy syntax
always treats yyy as the name of a keyword, even if it looks like
an integer or float or whatever, whereas x[1] will use as key the
integer 1, x[1.0] will use as key the floating pointer
value 1.0, and x["a"] will use as key the string (not
keyword) "a".
You may actually use any valid path inside the brokets:
x[y[z]] x[pkg:sym] x[pkg:sym.k]
As a final wrinkle, CommonLisp package notation is
supported: pkg:sym may be used to refer to the value
of exported symbol sym in package pkg, and
pkg::sym may be used to refer to the value of
internal symbol sym in package pkg.
The above syntactic operators may be fairly freely mixed, nested and cascaded to produce monstrosities such as
mud:world$s.creator[tmp::name[i]] --> tickle:list[tmp::name[i]]
Experiment.
Note: Constant components of pathnames are keywords.
Thus, obj.key is equivalent to obj :key get,
not to (say) obj "key" get.
Go to the first, previous, next, last section, table of contents.