Property lists
Every symbol in muSE has an associated property list that you can query and edit using the get and put functions. For example -> (put 'kumar 'sister 'hamsa)
(sister . hamsa)
> (get 'kumar 'brother)
()
> (get 'kumar 'sister)
(sister . hamsa)
A symbol's property list is globally available and is not changed by local contexts such as let.
7 comments:
What is this useful for?
For a variety of things - basically properties that you need to be associated to symbols. For example, muSE's "define" function supports an experimental (and optional) documentation sexpr as its second argument which attaches various descriptions to the function symbol. (see fn_define for some info). You can then generate doxygen style documentation of all described functions in the symbol table using the "generate-documentation" function.
This feature is experimental and needs more refinement, so I haven't put it up front. But this is just one use for the property list.
The other (quite major) use is with anonymous symbols. Anonymous symbols with property lists are used to implement a simple object dynamic system for OOP in muSE. Though I implemented that for fun in something like 3 simple C functions, I've never needed it so far. Its not very efficient for extensive use and therefore is still considered "experimental".
There's some doxygen documentation on the muSE's object system.
Though the object system is not suitable for large system development, it is nevertheless usable and rather complete - member functions, member data, classes, multiple inheritance, dynamic editing of the inheritance tree, delegation are all available.
If I understand correctly, symbols are global whereas functions are scoped. This would mean that you would have conflicts if you tried to reuse the same symbol name in different scopes. Maybe a better idea would be to try and associate the property lists with the actual objects rather than with just their names.
Anonymous symbols are local and if there are no references to one, it is garbage collected as I mentioned, so an anonymous symbol would be what you'd call an "object" in most other OOP languages - one to which you can attach properties.
muSE is intended for use an embedded language and the notion of "global" in muSE is really rather local in the app's context .. often.
... so to clarify, if you need local property lists, you can attach them to an anonymous symbol and pass that around. Note that you can set an anonymous symbol as the value of a regular named symbol and that can be changed in local contexts because it follows value semantics.
Post a Comment