bind from a C perspective
Thanks for helping with bind and VID.
I am trying to comprehend the deeper mechanics of how this code works:
do bind [
font/color: red
show self
] pick parent/pane 7
as well as the canonical example:
words: [a b c]
fun: func [a b c][print bind words 'a]
fun 1 2 3
>> 1 2 3
From an implementation perspective are blocks linked lists and bind turning the know-word 'a into a pointer to the block or single word?
Is this accomplished through a Rebol internal function or does bind simply update 'a to link to the known-word?
Displaying the actual block underlying structure might help me in figuring out how some functions work.
On a more general note, what can I read to shed some light on Rebol internal structure on the level of "Rebol for C programmers"?
posted by: VIDpuzzle 9-Feb-2019/19:01:10-8:00
At a low-level, a BLOCK! is just a C array with elements the size of 4-platform-pointers (referred to as "cells", though REBVAL is what you will see them called in the source).
The blocks are allocated at a fixed size, and can act as something of a double-ended queue--by being willing to have excess capacity at either their heads or their tails.
Roughly speaking, a WORD! cell uses its four platform pointers to hold:
* A header (this is where its identity as a REB_WORD is stored, for instance, distinguishing it from a REB_BLOCK or a REB_INTEGER, etc.)
* A pointer to the symbolic name for the word--word instances with the same spelling share the same pointer.
* A pointer to the context where the word is bound. This will be null if it is unbound.
* An integer index into the context for the slot in that context the binding is for
You will find that binding is very mechanically simple in historical Rebol. Its simplicity is a weakness...as it carries implications like "if you make an object with 10 fields and 10 methods--then create a derived object from that one--it must deep copy and rebind the blocks of all the methods in order to make sure those methods now have words whose context pointers are to the new object instance". Similarly, when a word points to a function parameter, there's no distinction of *which* function call instance a word in the body for the function points to unless you copy the body when you call it.
These problems are tackled and have interesting solutions in the Ren-C branch of Rebol:
https://github.com/metaeducation/ren-c/wiki/Relative-Binding-and-FRAME!-Internals
If you are a C programmer interested in Rebol, then may I encourage you to look at the Ren-C sources...where I try to be as descriptive as possible:
https://github.com/metaeducation/ren-c/blob/master/src/include/sys-rebval.h
There are many very cool things afoot in Ren-C, and I invite you to come talk about them.
https://forum.rebol.info/
https://chat.stackoverflow.com/rooms/291/rebol
More reading on binding:
https://stackoverflow.com/a/33469555/211160
posted by: Fork 9-Feb-2019/20:59:04-8:00
I've been eying Ren-C, considering embedding within my app. Ren-C ANSI-C 89 quasi full compatibility provides the foundation I need to piggy back any library I choose.
"index caching the numbered context slot that symbol's value was in" suggests one object can support several bindings?
I need time to process the provided links.
For now I develop my POC in R2, considering writing primitive graphic bindings for Ren-C at a later stage.
posted by: VIDpuzzle 13-Feb-2019/0:17:10-8:00
> "index caching the numbered context slot that symbol's value was in" suggests one object can support several bindings?
Objects are collections of named fields. The list of fields is shared among objects (though adding a field to an object--legal in R3-Alpha--will point that object to a new, not shared list). The list of values is unique to each object...and that array is the object's identity (it points to the list of keys).
The index is just to which slot in the object.
o: make object! [x: y: ] ; x is slot 1, y is slot 2
An `x` WORD! that is bound into this object would have:
1. header
2. pointer to UTF-8 text "x"
3. pointer to an array containing [* ]
4. the index 1
There's nuances in that the `*` slot in the array (C index 0) holds an instance of the OBJECT! itself. And Ren-C has several other nuances, which pertain to addressing the limits that such a simplistic model faces in practice. The links explain some, the source comments try to document the rest.
For instance, derived binding:
https://github.com/metaeducation/ren-c/pull/727
posted by: Fork 13-Feb-2019/6:08:19-8:00
Apparently this forum didn't like the tags in my examples. :-/ Substitute with:
o: make object! [x: "a" y: "b"] ; x is slot 1, y is slot 2
An `x` WORD! that is bound into this object would have:
1. header
2. pointer to UTF-8 text "x"
3. pointer to an array containing [* "a" "b"]
4. the index 1
posted by: Fork 13-Feb-2019/6:10:46-8:00
I apparently need to close the bold tag? Maybe. :-P
posted by: Fork 13-Feb-2019/6:11:58-8:00
|