AltME groups: search

You'd miss the /into option for incremental collecting and preallocation, 
but at least you wouldn't need to BIND/copy your rules.

What i am curious about, how does scheme handle binding? can i bind 
symbols in data to contexts, and how? I like that for dialects.

the way I understand it is:

reduce bind block context

yes, but if the structure is nested, you have to reduce things so 
they become flat.


also, not all situations allow you bind values directly to objects,

anyhow... object use is central to this, since its the most approachable 
way to group & bind things in context .

For example, in the case of two modules with same function names, 
you can use a direct reference to clarify which one you're referring 
to, or bind your code to a specific module. Easy to do.

This module loader for the odbc.dll extension handles the bug in 
its open handler that prevented it from using block specs with a 
target:

REBOL [
	title: "ODBC Extension Patch"
	type: module options: [private]
	needs: [%odbc.dll]
]

odbc: import 'odbc


system/schemes/odbc/actor/open: func [port [port!] /local result] 
bind [
	port/state: context [access: 'write commit: 'auto] 

 result: open-connection port/locals: make database-prototype [] case 
 [
		string? select port/spec 'host [ajoin ["dsn=" port/spec/host]]
		string? select port/spec 'target [port/spec/target]
		'else [cause-error 'access 'invalid-spec port/spec]
	]

 all [block? result lit-word? first result apply :cause-error result] 
	port
] odbc

My main idea (Already tried in the past ) is to build enough small 
primitives to allow to constuct all the standard styles without the 
need to add bloated hand written code.

The primitives are context sensitives, meaning that blocks of primitives 
can be shared between several face without the need to bind/copy 
them for each face.

I guess my bias is that the burden of what input goes where is on 
the data/application model. To give the UI that responsibility would 
seem unnecessarily complex (that's not to say it wouldn't be favourable 
to some applications, but this is core design, right?). I'd find 
it more useful to have the UI have an independent data model where 
I could extract some data to send one (or more) place, extract other 
data to save another, and so on.


I find that's what I miss when working with R2 VID, not so much that 
it doesn't bind to data sources...

it's logical to bind the name of the field to the record name, yes.

I changed it to:

	unless pan [

  pan: make-panel make-face 'vpanel (pick test-blocks index) 'group 
		poke test-panels index pan
	]

But something is "not bound" ... I get following error:

** Script error: when has no value

** Where: make make make-face unless view-sub-panel do switch -apply- 
apply if f

oreach if do-face switch do do-bind-actor actor all foreach do-style 
set-face sw

itch do do-bind-actor actor all foreach do-style case do-event do-event 
do-event

 either -apply- wake-up loop -apply- wait do-events if view catch 
 either either
-apply- do

** Near: make styl/facets opts options: make object! any [opts []] 
ta...

** Script error: cannot access faces in path panel/faces

** Where: exclude-faces -apply- apply if foreach if do-face if do 
do-bind-actor

actor all foreach do-style until if do-event do-event do-event either 
-apply- wa

ke-up loop -apply- wait do-events if view catch either either -apply- 
do
** Near: exclude-faces face name

In JQuery, it's called bind() and unbiind()

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

 - Rebolek - what function is that? I found that e.g. for panel, it 
 seems to be an init-panel function, which maps options block to facets. 
 And no, it is not about simple binding, it does more than that.

I am trying to fix the drawing style, which is not complicated, but 
does not display anything. There might be problem in following init 
code:

	actors: [
		on-make: [
			if block? drw: face/facets/drawing [
				bind face/gob/draw: copy drw face/facets
			]
		]
	]

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

So, for the case of BIND [...] function the main difference is, that 
it cannot be done regardless of whether the function is running or 
not, which can be considered a security measure, then.

A test of SIZE-TEXT shows a bug in R2. This should hopefully not 
be present in R3.

The test to run:

f: make system/standard/font [name: "Verdana" size: 12]
g: make gob! []
t: import 'text
g/text: bind [font f bold true text "Boo"] t
probe size-text g				; I get 26x14 here
g/text: bind [font f bold false text "Boo"] t
probe size-text g				; I get 25x14 here


It's possible that the result may vary, but the bold version should 
produce a wider size than the normal one. if you can test this similarly 
to what you did for R2, that would be great. Thanks.

this looks more likely:

defined?: either rebol/version >= 2.100.0 [
	func [
		{find all defined words in the given context}
		context [any-object!]
		/local words
	][
		words: words-of context
		remove-each word words [not value? word]
		words		
	]
][
	func [
		{find all defined words in the given context}
		context [object!]
		/local words	
	][
		words: bind first context context
		remove-each word words [not value? word]
		words
	]
]

I thought Android API is in JAVA? How do you want to link/bind?

fine... I've found that the text must be bound to the text extension 
context.. this works:
ext-text: import 'text
g_text: make gob! [size: 100x20 ]
g_text/text: bind [
	;bold true
	text "AB"
] ext-text


The question is, what is changed in RM's version that it works without 
such a hack.... I have no problem to hack just the official A110 
version so far as I'm trying to understand how the internals work, 
but I really think that we need synced source repository ASAP.

Ah, but then you need to bind BODY.

since it would redefine the 'SANDBOX function... unless I'm totally 
missing how modules bind stuff.

Rebol []

make-obj: func [
	"Créé un objet en sauvant son nom dedans."
	'name "Nom de l'objet à créer."
	obj "Objet de base à instancier."
	spec "extension de l'objet de base."
] [

 set name make obj append reduce [to-set-word 'obj-name to-string 
 name] spec
]


save-obj: func [
	"Sauvegarde un objet selon son propre nom."
	'obj "Objet à sauvegarder."
	/local name
] [

 name: any [all [word? obj  object? get obj  get in get obj 'obj-name] 
 join "objet" random 10000]
	save/all to-file join name ".r" get obj
]

load-obj: func [

 "Recharge un objet et l'intancie selon son propre nom s'il en a un."
	file "Nom du fichier à charger."
	/local obj
] [
	if exists? file [
		obj: load file
		probe bind next first obj obj
		probe get in obj 'list
		all [in obj 'obj-name  set to-word get in obj 'obj-name obj]
	]
	obj
]

task: make object! [
  list: copy []
  add: funct [t [block!]] [
    append list t
  ]
  save: does [
    save-obj self
  ]
  run: does [
    do list
  ]  
]

make-obj task1 task []
task1/add [a: 0 a: a + 1]
task1/add [print a]
task1/run
task1/save

task1: none

load-obj %task1.r
task1/run

Last question, why can't the binding of the save/all form be restored 
by the manual 'bind ?

do load

 does not work with the serialized form (I tried it)?" I'm not sure 
 to understand what you mean there. SAVE/ALL uses MOLD/ALL to serialize 
 values, so binding information is not preserved. If you want to restore 
 correct binding in a object! serialized using /ALL format, you need 
 to write some code to walk through object's functions body blocks 
 and bind object's words explicitely using BIND.

Here's a working version:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

I am making a simple (I hope) worfkflow prototype and want to use 
REBOL objects which I can SAVE and LOAD.  A workflow object!  to 
have a node-map collection in it of simple nodes of the workflow 
graph.   Source ->A -> B -> SINK where the workflow knows about the 
next node and status. Externally there is UI to support the work 
part ... which is URL data on a given node.   Looks like it fits 
into Cheyenne RSP well - maybe zmq when I get a bit further along. 
  Save a flow in process as a .txt file using SAVE/ALL filename.txt 
work-flow-instance.   But no success with work-flow-instance: LOAD 
filename.txt        Do I have to BIND on LOAD to re-instantiate the 
object?

Onetom, that error has been reported already and fixed in R2/Forward, 
but it hasn't made it into R2 yet. Here is the revised MAP-EACH:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

If I in a function have a local variable, v, but I want the value 
of a variable v in the context outside the function, I can write:

get bind 'v bound? 'f


, where f is the name of the function. Is that the way to do it, 
or is there a better way? Full example:

>> v: 1
== 1
>> f: func [/local v] [v: 2 get bind 'v bound? 'f]      
>> f
== 1

If you know the context you want to use and it is always the same, 
then it is a bit inefficient to call the BIND function, not to mention, 
that

    bind 'v 'f

is more efficient than
 
    bind 'v bound? 'f

Tonight's Moment of REBOL Zen:

Check this Fibonacci function:

fib: func [
	n [integer!]
	(
		if not local [
			a: 0
			b: 1
		]
		prin [a b ""]
		loop n [
			prin [c: a + b ""]
			a: b
			b: c
		]
		print ""
	)
	/local a [integer!] b [integer!] c
][
	do bind third :fib 'a
]

>> fib 10
0 1 1 2 3 5 8 13 21 34 55 89 
== 89
>> fib/local 10 55 89 none
55 89 144 233 377 610 987 1597 2584 4181 6765 10946 
== 10946


If you only want to execute the paren in the function spec, put this 
in the body instead:

	do bind to block! third second load mold :fib 'a

Cyphre, in your example, when you insert the first x in the block, 
it's the x holding the value 10. To me, the x in the block is bound 
to the outher x at the time, you insert it into the block. The next 
x, you insert in the block, is the x from the context o. So at the 
time, you insert it into the block, that x in the block is bound 
to the x in o.


So the block holds two different x, and they're bound at the time 
of insertion. That's what I meant, when I said "the binding of words 
in a block is done, when the words are put into the block".


(Words can be rebound at a later time using e.g. BIND, but I'm not 
looking at that in these examples.) I don't have time and energy 
to argue with Ladislav right now. :)

In REBOL, literal blocks are just literal blocks. If you modify them... 
they are modified. Binding a block modifies the words inside the 
block, ie. it modifies the block. It can't get any simpler than this.


Now, you may argue that MAKE OBJECT! should bind/copy the block instead; 
the reason it does not is purely performance (as 99.99% of the time 
the copy is not necessary). In that 0.01% of cases where you need 
it... you just write MAKE OBJECT! COPY/DEEP [...] instead.

BIND modifying the block is a useful feature at times. For example, 
the copy that has been added "for security reasons" in many places 
makes a number of "tricks" harder to do.

John, it sounds like where you get confused, or think of things as 
bugs or design flaws, is when having your REBOL "That's funny!" moments, 
borne of deep tinkering. Aside from the "copy series in funcs" behavior, 
which I think bites many people at some point, your issues don't 
come from writing application code in REBOL and bumping up against 
REBOL's behavior. Rather, it seems that REBOL's implementation and 
design don't match your expecations in these cases, and you really 
want it to. :-)


The reason I asked about consequences is because you may want a change 
that affects other users negatively. Imagine REBOLers as being in 
one of two groups. Group A is the gurus. They have internalized REBOLs 
design, understand it deeply, and use BIND and recursive PARSE rules 
without fear. That group is very small. Group C contains everybody 
else, which includes people that don't know about using /local with 
funcs, and suggest REBOL should use  = for "assignment". They have 
never used USE, BIND, or many other functions, because they aren't 
sure how they work. Some of them know a little about series references, 
so they always use COPY to be safe. (Yes, group B exists too, but 
they are much more like C than A).


If REBOL were meant only for A users, it would be very different. 
As a designer, it seems pragmatic to make it so things work well 
for the B and C users who, when they hit a problem that requires 
advanced understanding, will work around issues with the bits they 
understand (and adding many COPY calls), no matter how inelegant. 
Group A users may suffer at their expense, but I'm OK with that, 
because I'm not one of them.

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

I guess it is as efficient as it can be and still support objects, 
maps, blocks and parens. There are more efficient methods if you 
only need to support objects, maps, or blocks and parens.
Objects:  set bind/new :word obj :val
Maps:  obj/word: :val
Blocks and parens:  reduce/into tail obj [to-set-word word :val]

BTW, I am a bit annoyed by needing to bind a user-supplied block, 
and having to always recreate a function because of that. I would 
prefer to just BIND, as in R2, which is technically possible, just 
unsupported.

the BLK is user-supplied, and I have to always recreate the function 
instead of being able to just bind it

Do you mean so that the 'a and 'b are bound in the block? You can 
bind to a function context by using one of its argument words as 
a referent. Or do you mean as in cases like the KEEP function in 
COLLECT ?

You can bind to a function context by using one of its argument words 
as a referent.

 - well, actually, I can do that only when the function is actually 
 running

You are missing the point, I guess. The MAKE function binds the function 
body when the function is not running. The restriction to BIND is 
just artificial, and circumventable. I do not use the circumvention 
not because it is not possible, but because it looks "ugly".

I wouldn't mind BIND accepting function! for its context argument, 
as long you still have the error on referring to any of the bound 
words when the function isn't running. But not closure! though, since 
that context is different every time.

Of course, at this point you don't need to use an inner function 
at all, you just use bind + do.

You grabbed that phrase that I was answering from the section where 
binding with definitional return was the only way to bind. There 
is no option in that section (and that fact is listed in the advantages). 
In that section, definitional is the only way to bind.

Sure there is. BIND + DO.

The only reason definitional-only might be chosen is because it is 
easier to understand than the other models. That alone might trump 
the places where it still doesn't work. I hope not, because the "option 
to not rebind RETURN and EXIT" is really simple to specify and much 
easier to do than the workarounds that you have to do if you don't 
have that option, workarounds like your BIND + DO, especially when 
you consider 'self issues that prevent you from using objects for 
this kind of thing (hence the FOREACH).

PARSE doesn't bind the code in its parens - that's regular REBOL. 
Parse also can't know ahead of time which blocks it will be treating 
as rules, because it uses dynamic scope for the whole dialect.

Well it comes down to this: Functions are defined lexically. Though 
they are called dynamically, they aren't called until after they 
have already been bound, definitionally. But as a side effect of 
tasking, those bindings are stack-relative, and those stacks are 
task-local. But random blocks of code outside of functions are bound 
to object contexts, and those are *not* task-local. So that means 
that the old R2 practice of calling shared blocks of code is a really 
bad idea in R3 if any words are modified, unless there is some kind 
of locking or synchronization. This means that those blocks need 
to be moved into functions if their code is meant to be sharable, 
which means that at least as far as RETURN and EXIT are concerned, 
they can be considered lexically scoped. The advantage that we would 
get from being able to call a shared block of code and explicitly 
return in that block is moot, because we can't really do that much 
anymore. This means that we don't lose anything by switching to definitional 
code that we haven't already lost for other reasons. At least as 
far as functions are concerned, all task-safe code is definitional.


Loops are also defined lexically, more or less, and the rebinding 
ones are also task-safe because they are BIND/copy'd to a selfless 
object context that is only used for that one call and thrown away 
afterwards. And most calls to loops are task-safe anyways because 
they are contained in functions. However, the LOOP, FORALL, FORSKIP 
and WHILE loops do not rebind at the moment. We actually prefer to 
use those particular loops sometimes in R3 code because they can 
be more efficient than *EACH and REPEAT, because they don't have 
that BIND/copy overhead. Other times we prefer to use *EACH or REPEAT, 
in case particular loop fits better, or has high-enough repetitions 
and enough word references that the 27% overhead for stack-local 
word reference is enough to be more than the once-per-loop BIND/copy 
overhead. Since you don't have to move blocks into *loops* to make 
them task-safe, you can use blocks referred to by word to hold code 
that would be shared between different bits of code in the same function. 
This is called manual common subexpression elimination (CSE), and 
is a common optimization trick in advanced REBOL code, because we 
have to hand-optimize REBOL using tricks that the compiler would 
do for us if we were using a compiled language. Also, PARSE rules 
are often called from loops, and they are frequently (and in specific 
cases necessarily) referred to by word instead of lexically nested; 
most of the time these rules can be quite large, maximizing BIND/copy 
overhead, so you definitely don't want to put the extensive ones 
in a FOREACH or a closure.

Switching to definitional break would have three real downsides:

* Every loop would need to BIND/copy, every time the loop is called, 
including the loops that we were explicitly using because they *don't* 
BIND/copy.

* Code that is not nested in the main loop block would not be able 
to break from that loop. And code that is nested in the main loop 
would BIND/copy.

* We can in theory catch unwinds, run some recovery code, and send 
them on their way (hopefully only in native code, see #1521). Definitional 
escapes might be hard or impossible to catch in this way, depending 
on how they are implemented, and that would mean that you couldn't 
recover from breaks anymore.


The upside to definitional break would be that you could skip past 
a loop or two if you wanted to, something you currently can't do. 
Another way to accomplish that would be to add /name options to all 
the loop functions, and that wouldn't have the BIND/copy overhead. 
Or to use THROW or THROW/name.


The situation with THROW is similar to that of the non-binding loops, 
but more so, still task-safe because of functions. But CATCH and 
THROW are typically the most useful in two scenarios:

* Escaping through a lot of levels that would catch dynamic breaks 
or returns.

* Premade custom escape functions that might need to enforce specific 
semantics.


Both of these uses can cause a great deal of difficulty if we switched 
to definitional throw. In the first case, the code is often either 
broken into different functions (and thus not nested), or all dumped 
into a very large set of nested code that we wouldn't want to BIND/copy. 
Remember, the more levels we want to throw past, the more code that 
goes into implementing those levels. In the second case definitional 
throw would usually not work at all because the CATCH and the THROW 
would contained in different functions, and the code that calls the 
function wrapping the THROW would not be nested inside the CATCH. 
So you would either need to rebind every bit of code that called 
the THROW, or the definitional THROW would need to be passed to the 
code that wants to call it like a continuation (similar concept). 
Either way would be really awkward.


On the plus side of dynamic (whatever), at least it's easy to catch 
an unwind for debugging, testing or recovery purposes. For that matter, 
the main advantage of using THROW/name as the basic operation that 
developers can use to make custom dynamic escape functions is that 
we can build in a standard way to catch it and that will work for 
every custom escape that is built with it. The end to the arms race 
of break-through and catch.

Definitional (whatever) depends on a BIND to do its work, deep, usually 
BIND/copy. And that only works on words that are physically in the 
blocks that you bind, or in blocks that are nested in those blocks, 
etc. Another block that is outside the block you are binding and 
referred to by name won't be bound. That is the limit of the definitional 
approach.

Note that the definitional BIND that functions do when created is 
*not* a BIND/copy, it modifies. Same thing with closures when they 
are created, though they also do something like a BIND/copy every 
time they are called.

Ladislav, your definitional throw in the "Definitional CATCH/THROW 
mezzanine pair" section of your page isn't recursion-safe, because 
MAKE function! does a modifying BIND rahter than a non-modifying 
BIND/copy. Otherwise, nice work :)

{Ladislav, your definitional throw in the "Definitional CATCH/THROW 
mezzanine pair" section of your page isn't recursion-safe, because 
MAKE function! does a modifying BIND rahter than a non-modifying 
BIND/copy. } - I know that, but, since it is just an example, and,since 
it can be asily updated to copy, I wrote it this way. I can add copying, 
though

Right. COPY/deep is expensive for large code blocks, worse than BIND/copy 
(depending on the code). Copy overhead is a big deal.

(my note was realted to the bind/copy refinement)

The BIND/copy overhead is inherent in definitional scoping, except 
for function and closure creation where it is only a BIND, which 
was happening anyway. That is why definitional return is cost effective

Bind/copy may be inherent, but my not was a reaction to: "COPY/deep 
is expensive for large code blocks, worse than BIND/copy" - which 
may not be desired

In the case of BREAK (I mean the one used in the DO dialect now), 
the situation is 50:50, since loops would be bound once, done many 
times anyway, making any slow-down % much smaller, and due to the 
fact, that some loops (as you mentioned earlier too), need to bind 
their bodies anyway

I don't know how much R3 code you've had to optimize, but I've had 
to optimize it a lot. That BIND/copy overhead is significant. It 
takes a *lot* of loop reps to balance it out, more than most code 
needs to do by something like an order of magnitude. It's not 50:50.

Carl has mused that there might be a faster way to do BIND/copy in 
loops. It would be welcomed.

I did my best to argue for it by doing a thorough ticket and writing 
best-possible-without-it example code for LET and BIND-TO-NEW, to 
show how much it is needed.

did not understand your question probably; did you mean something 
like this?

>> same? 'self first bind [self] make object! [a: 1]
== false

Or, maybe more in the line with what you wrote:

make object! [method: func [block] [bind block self]]

>> a: context [a: 1]  same? a first bind [self] a
== true

Ladislav, you are right.
>> a: context [a: 1]  same? a first do bind [self] a
== true

Dammit.
>> a: context [a: 1]  same? a do bind [self] a
== true

No, it wouldn't rebind the values. For that matter it doesn't bind 
the original words.

and since we have full control over the self word, because we are 
supplying/setting it then our class builder could properly bind the 
class methods to our instance selfless context.

Maxim, the self word in object contexts doesn't actually exist. The 
word self that you see is a keyword of the BIND function. A selfless 
context has a flag in it (that you can't set with MAKE object!) that 
tells BIND to not set that keyword.

Added an alternative BIND/CREATE to the #1758

(the BIND-TO-NEW function was removed, which enhances source readability 
in my opinion)

I just realized something: You don't need word references to have 
the full power of PARSE, you can use circular direct references instead. 
Of course you can't specify those structures in loadable source, 
you have to construct them dynamically, and you can't BIND them so 
you stiff can't use definitional scope for its operations. But it 
is at least in theory possible to match the patterns that finite 
nested rules can't match by using circular structures.

Yes, I can understand, where the first one becomes handy, but it 
can be done easily in selfless contexts as follows:

[
    self: bind 'self
    ...
    self.x: x
]


The second one is actually more annoying having implicit self, than 
it would be otherwise:

[
   class- name: 'my-name
    context [
        parent: bind? class-name
    ]
]

sorry, I meant BIND? not BIND above

yeah, but using bind is an inherently advanced use.  though like 
you, I understand that its just comparison.  


I'm in favor of 'SELF simply because I woudn't want REBOL code to 
become riddled with binds for such simple things. 


AFAIK bind doesn't scale well, in the sense that when you are playing 
around a lot with your code, bind will often become a point of failure, 
since the littlest change will quickly change what BIND does.

This is not BIND, just BIND?

There's some stuff left to straighten out, but it's painful to develop 
on WINE, so I'll continue when we can bind libc on Linux

The exact frontier between REBOL features that will be supported 
in Red, and the ones left aside is not yet accurately defined. In 
fact, it is possible to support almost every feature of REBOL, but 
the performance (and maybe memory footprint) to pay might be too 
high. For example, supporting dynamic scoping and BIND-ing at runtime 
is possible in Red, but the speed impact would be so high, that the 
compiled version wouldn't run much faster than the interpreted one.

When an extra script is JIT-compiled, will it bind to the already 
running environment?

By default, it would "bind" the script to the global context.

We could optionaly "bind" to a given module (namespace) or to a sandboxed 
execution context.

I say environment, because I would like it to bind to a stack of 
contexts. If it can do that, it would be enough for me

LibBitcoin has bindings, so you could bind to the C interface. But 
they're using 64 bits numbers everywhere, so that would be uncomfortable 
until Red/System has them

The reason I chose GTK is that it's written in C, which makes it 
natural to bind to Red/System. Almost all other open source GUI toolkits, 
including Qt, are written in C++, which is much more problematic 
to bind

Basically, to bind a C++ library, you have to write two bindings: 
one from C++ to C, and then one from C to your target language. This 
is because only C++ knows what C++ objects mean, and C++ claims that 
its object classes are a program's interface

Intrepid readers will note that one of the libraries I bind, 0MQ, 
is written in C++. However, the 0MQ designers wisely decided to define 
the interface in C, so that all languages can bind to it

Red/System's way to write bindings is the best I've seen. Barring 
C features it doesn't have yet, it should be able to bind any C function. 
Mostly only 64 bits integers and importing data values are still 
missing by now

You should bind the GetProcAddress function (I think there are already 
Red/System Windows examples floating around that use it), find out 
how to get the value of the g_hLedCtrlInst library handle, and use 
them to load the functions like the C code does

Besides GetProcAddress, there's a set of a few function for loading 
libraries and symbols. You'd need to bind them and use them to load 
the library, which yields the library handle, and then load the functions. 
They're what load/library and make routine! in REBOL use

What would be World's equivalent of this:    with: func[obj body][do 
bind body obj]