Is there value in providing a method to lookup variables over multiple contexts?
This question has recently bubbled to the top from an addition made to the delect function. (Delect mainly provides a high-speed parse method for command mapping, argument order marshalling, and value lookup. It is used for dialects like DRAW.)
There are times when using delect on a block where you want the variable values to be obtained from a specific context or better yet, a collection of contexts.
Delect was expanded to allow:
delect/in dialect input output contexts
Where contexts is a block of contexts to use for resolving the values of variables. An example of this would be in a drawing, where a pen color may be found in one of many style sheets, but also in the primary face object.
This extension of delect raises the question as to whether the technique is generally useful for variable lookup?
color: get in [
face/options frame/options style/options
] edge-color
We might be tempted to think that the equivalent of this is:
color: any [
face/options/edge-color
frame/options/edge-color
style/options/edge-color
]
But, in fact that's not true because if the variable is not in a context, an error will be thrown. Therefore, we would have to write it like this to be safe:
color: any [
get in face/options 'edge-color
get in frame/options 'edge-color
get in style/options 'edge-color
]
Now, if you consider that pattern within a reduced block, it could add up to a significant amount of code, something we don't like a lot of in REBOL.
Where this really seems to be of values is in the implementation of things like property sheets (like CSS in HTML). The pattern is to look for a property in one context, and if not found, look in a parent context, etc.
The overhead of adding this feature to REBOL is small, because it's already implemented for delect.
I like this feature. It allows to dynamically build "lookup-chains" that can alter the behaviour of an application.
With such a feature, special options or exceptions can be implemented very smart that otherwise would need IFs and additional functions.
Norm 30-May-2008 11:14:51
Apart of graphics, other applications could use something like that. Example, web arxiv dot org is classifying some same words in multiple disciplines, same subjects in contexts. So, one could maintain such site in few lines of codes with reb services using such multi-context lookup.
Personally, I would relish to lookup maps to be retreived from various contexts, as that task is springing frequently. In lexicography, I classify words from many contexts. As a writer, I classify documents on the same topics in their numerous contexts, and write on some topics in many fields. In programming, I have to map the adhoc semantics of some texts into various forms of html and LaTeX.
In that last task, to be efficient I would need a form of uninterpreted verbatim block, a form of assignable comment, that the interpreter would read as existing verbatim uninterpreted code. The ideal would be to do like C#, so a string keep untouched (you replace them instead of modifying them). So such code could contain caracters like '"{}[]##/ and whatever else, as is. A form of verbatim block. In Lua, one writes -- for a comment, and --[[ ]]-- for a block comment; so we may transform a block comment into a line comment by simply adding a third dash in front of the block comment. For my part, I would prefer ----[[ ----]] and a way to transform it into line comment, as a long form ----[[ does not confuse with the endash and emdash in TeX or plain texts. What I look for is a simple way to put scripts made from many other languages into maps (name, value pairs), and compose texts from them programmatically by getting those values without having to escape all caracters in those various languages that the Rebol interpreter would otherwise do. If provided, Rebol could become the meta language, the language to manage other languages; swiss knife of programming languages. Litterate computing, it would enable to write print-on-demand textbooks from the comments on Rebol code too. So, there is added value to multicontext lookup, more with assignable verbatim blocks.
Kaj 30-May-2008 16:33:17
This feature sounds great. I use the pattern of hierarchical lookup paths all the time.
Brian Hawley 2-Jun-2008 10:55:37
That sounds really useful. Why not?
Brian Hawley 2-Jun-2008 13:08:39
Norm, in REBOL blocks aren't interpreted unless you interpret them, no extra syntax necessary. Other languages could be stored in strings. Literate programming can be done already in REBOL, with some tools from Gabriele.
Brian Tiffin 4-Jun-2008 19:33:56
Sorry, this is sliding from the blog topic at hand ... but
Brian; I think (and I'll apologize to Norm if I'm wrong) what Norm is looking for is something I've been questing for in REBOL for a long time. That is, some form of FOREIGN datatype so that a loaded block could hold [10,000.00] or [$1$1$3] or other non-REBOL data. And not worry about stringing such data without triggering a syntax error. Why? Because parsing is hard enough :) and more seriously, not having such a capability (imho) keeps REBOL just out of reach of most people and more to the medium to highly computer literate; those able to understand the lexical considerations for loadable REBOL datatypes.
Regarding the blog topic at hand; Yes I think multi-context referencing will be great. I'd also add, that for sandboxing being able to exclude the REBOL (or other) context would be handy as well.
maxim olivier-adlhoch 4-Jun-2008 23:20:52
Very usefull.
I've have to implement this in MANY apps, where you allow preferences to the user and build up from default values reducing to a final setup of "current" prefs.
sometimes the defaults come from libs, then app, then command-line, then session, for example. A lengthy process to manage in R2, when you have a few dozen preferences.
you end-up having to code something similar to what you propose, so having it built-in would be nice.
