World: r4wp

Nice, WITH would have been my other choice :-)

I suppose the first context has the highest priority?

I would expect that the nearest nested WITH would have priority.

So WITH would be like DO IN a [...] in R3.

first context has the highest priority

: the nearest nested WITH has the higher priority (implemented but 
not tested yet).


Also, when specifying a block of namespaces, the first one in the 
list has priority other the next one, and so on.

The latter is what I meant

Nice. I remember that being proposed for R3, but we went with DO 
IN instead. IN block block is still proposed though.

I was disappointed when that was rejected. I have a VM where I need 
to bind to dynamic stacks of contexts

DO IN was supposed to be the same as WITH, with only one extra space. 
However, IN block block wasn't implemented; IIRC it wasn't rejected, 
it was deferred, same thing at the moment I suppose.

I vaguely remember the blog at the time was about RESOLVE, not sure 
how that ties into IN

Deferred until it can be put in Red :)

Hear hear :-)

the IN block! block! is a must have at least. It's a pain in the 
ass to have to rebind the same block several times.
Kaj, I also worked on VMs and it was a shame.

Exactly

IN block word is used in the R3 GUI. It does the same context walk 
that Doc says WITH does, but only to retrieve a word.

The bug with RESOLVE is unrelated. Not sure if that is what you're 
talking about though.

What we need is to be able to rebind a block of code into several 
context in one time

*at one

I used several BIND in sequences. Not neat

Yes, I wondered how a language for constructing languages could make 
this omission

I show you some code. Follow the rebounds :-)

is: func [
		[catch]
		{Current face inherits from a block!}
		spec [block!]
		/local locals old when init
	][
		either all [
			find spec set-word!	; locals founds
			not empty? exclude  ; new ones (not found in the current face)

    first locals: construct copy spec ; copy: because [construct] modifies 
    the block (R2 bug ?)
				first face
		][

   ; Would be simpler, faster and safer using R3 (objects can be expanded)
			; rebuild face with new locals 

   ; (make face spec : can't be used here because of the special bounding 
   rules)

   when: face/when					; prevent copy/deep of when and init blocks
			init: face/init
			face/when: face/init: none
			set locals none

   resolve* locals face			; initialize locals with current face (if 
   intersect)

   face: make old: face locals		; rebuild current face with new locals
			face/when: when
			face/init: init
			do-safe bind bind spec face self; run style constructor 

   bind bind init face self		; rebound current face constructor (which 
   is currently running)

   error? set old :bound-err		; prevent old object from being used anymore
			old: none
		][
			; no new locals

   do-safe bind bind spec face self		; just run style's constructor 
		]
		if error throw-exit
	]

Brian, there was a blog about having RESOLVE, I think, walking a 
list of contexts, but Carl eventually decided that it wasn't needed 
"due to R3's new binding capablities"

Maybe it was about BIND directly

Probably. I'm having trouble imagining a use for RESOLVE doing that.

Maybe it could be used for some kind of multiple-prototyping of objects. 
Something like this:

>> resolve/extend context [] reduce [context [a: 1] context [a: 2 
b: 3]]
== make object! [
    a: 1
    b: 3
]

I haven't followed R3 contexts and binding evolutions, but as Red 
will use a slightly different model (more statical), I guess we'll 
come up with different solutions than with R2/R3.

Oh yeah, sorry to taint your thread Dock

WITH makes more sense for Red. DO IN is inherently more dynamic and 
runtime, while WITH can be more static.

Steeve: no problem ;)

Object expansion is another one of those things. When you say objects 
can't be expanded, it sounds fair enough, but when you say contexts 
can't be expanded in a language meant to create languages, that's 
a serious limitation

`system/words` virtual path support was added in today's commits, 
to be able to get/set a global variable or call a function from within 
namespaces with conflicting local names.

Example:

    e: 123
    a: context [
        e: -1
        print-line e
        print-line system/words/e
        system/words/e: 0
    ]
    print-line e

will output:
    -1
    123
    0

is there aliasing possible? e.g.

sys*: :system/words
sys*/print

No, you can't do that. You can use macros for full paths if it's 
really required. Anyway, the use of system/words should be rare.

It has been added just to make it possible to resolve conflicting 
cases.

I just need to upgrade Red/System specifications, improve the Red/System 
runtime with this new feature, and I'll be ready to merge this branch 
into master. I might also make a new global release (v0.2.6).

That would be good. I'm now only updating the bindings for releases

If some external library requires 64bit integer, but Red/System supports 
only 32 bit integers, how can I supply that number? Can I "cover" 
it with a struct?

If you need to pass a 64-bit integer as argument, currently you would 
need to split it in two integers and pass them instead. A struct 
is passed by reference, not by value (yet).

Couldn't you pack them in a float64!?

Yes, that should work too.

Nenad, can you give me an example, please? When the function requires 
for example (pseudo-code):
     pointer! [byte!] integer64! struct! ; data, index, metadata
how should I pass the integer64! value?

Where do you get that integer64 value from?

In your example, do you also need metadata to be passed by value?

Ok, no metadata, I was wrong. See http://www.mega-nerd.com/libsndfile/api.html#read
sf_count_t is 64 bit integer.

If you need to make some 64-bit calculations as suggested by the 
description, it is more difficult to achieve, but not impossible. 
I think that Peter has coded some 64-bit addition and subtraction 
functions that operate on two 32-bit integers.

I'm testing the namespaces branch. I can't use CONTEXT as a local 
variable anymore. Is it necessary to reserve it that strongly?

I found the issue with handling 64-bit integers in Red is the lack 
of support for unsigned integers. I only needed to  64-bit integers 
support on Windows so I used Lib calls in the end.

Actually, I wrote a small lib to perform the 64-bit arithmetic ... 
but I only needed subtract and divide.

it's at:

https://github.com/PeterWAWood/Red-System-Libs/tree/master/Int64

It wouldn't take long to add addition and multiplication if that 
would help.