Comments on: BIND expands contexts

Carl Sassenrath, CTO
REBOL Technologies
16-May-2006 23:28 GMT

Article #0026
Main page || Index || Prior Article [0025] || Next Article [0027] || 9 Comments || Send feedback

Here is something for you to think about in REBOL 3.0:

obj: make object! [a: 1]
word: bind 'b obj
set word 10
print obj
a: 1
b: 10

The bind function not only bound the word to the context, it actually added it to the context.

This result comes as a side effect from this: REBOL 3.0 does not use a global context environment; it uses modular contexts.

This means that the expression:

word: make word! "xyz"

creates a word (symbol) 'xyz, but not a variable. That is reasonable because a symbol can stand alone (a useful thing), but a variable requires a context. The make word! function specifies no context, so no context is assumed. If you try to use it:

set word 10
**Script Error: xyz word has no context (not bound)

In REBOL 3.0 the default behavior for bind is to bind the word to the context regardless of what it takes to make that happen (a behavior that is required for modules to work as new word definitions are created via additional scripts, etc.)

A few of you will ask: why does this matter? The main reason is memory (something we are optimizing on R3.0). Why force allocation for "free" variables (module variables) that are never used?

Some of you may have feedback to this, so post it. This is not set in concrete... yet.



Brian Hawley
16-May-2006 22:48
So, expandable contexts. Cool. As long as the IN native doesn't cause a similar expansion this could be quite useful.

This will require changing code that uses the old applicative order binding method. Right now, we expect words in a block of code that are not in the given context to be unaffected by bind. With the new behavior, those words will just be added to the given context and unbound from their old one. This would make functions not work, for instance.

I hope the old behavior is available when needed. Another use for the /only refinement?

Brian Hawley
16-May-2006 22:56
I just realized, the example given only specifies a single word passed to bind, not a block. Would the expando behavior apply to blocks of words too?
Brian Hawley
16-May-2006 23:07
For that matter, would it apply to function contexts?

When I was using the rebcode rewriting assembler, I frequently had problems that could only be solved by adding new temporary variables to the rebcode function's context, which was impossible to do in the rewrite phase of the assembler because the context of the rebcode function was already fixed. I ended up having to rewrite the source code block ahead of time, before it was passed to the rebcode maker.

Now I am not suggesting that function contexts be expandible, as that may cause problems that I haven't forseen, and likely be a debugging nightmare. Still, possibilities...

Ladislav Mecir
17-May-2006 3:18
The first thing I wholehertedly support is a terminology change, when instead of saying "...word has no context" we can use "...word is not a variable".
Ladislav Mecir
17-May-2006 3:29
On the other hand, I recall, that in Rebol2 some people requested MAKE WORD! to keep the context of a word in cases like: make word! first [a:]
Pier Johnson
17-May-2006 3:29
:) The error should read more like any of these:

ver# 1 xyz word not usable -- not bound to a context

ver# 2 cannot set xyz word -- word not bound to a context

Instead of the confusing anthromorphic personification of the word 'word', which reflects socialist indoctrination.

Words can never possess things. Words aren't alive! Only individuals can possess things.

**Script Error: xyz word has no context (not bound)

17-May-2006 10:21
Just a question. In rebol 2.x , is there a way to add a word inside a context ?

In fact, I was just thinking about that some days ago. I had an object and I wanted to dynamicaly add a "property" after the object has been build.

Carl, I'm not sure to understand what you mean with "REBOL 3.0 does not use a global context environment; it uses modular contexts". Is it linked with the idea of removind system object ?

Carl Sassenrath
17-May-2006 14:03
Batched replies:

1. IN: will not append to context

2. BIND native could do append as an option, and ignore the word otherwise (to be compat - a good idea)

2. Yes, works on blocks.

3. Does not work on functions, but probably works on closures.

4. We can change the wording on the error. The best wording should help the user figure out what the problem is. Still not sure of precise message to use.

5. In R2.x, you must expand with:

obj: make obj [newword: value]

which normally does what you need, but creates a new object in the process.

17-May-2006 15:56
isn't the intent of binding words to affect things out of the context, not within? so shouldn't we try to protect the context by default?

I can only say that expanding objects by default can be can of worms. python does it to the extreme and it comes to a point where a mis-spelled word in your code creates a new attribute instead of raising an error.

I'd rather have bind/add or bind/always to make this explicit.

Although very usefull when needed, I fear side-effects which can result in code which does first on a context and reacts based on content.

if adding word to the context is by default, then in the least, there should be an /only word like brian described.

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 15-Jun-2024 - Edit - Copyright REBOL Technologies -