World: r4wp

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

Arnold: sure, if someone is willing to take some of these coding 
tasking, I'll be happy to provide more detailed requirements.

This is exactly the point! If you look in the archives you will notice 
some remarks by Carl where he was disappointed in that others didnot 
pick up some tasks. Okay first of all REBOL being not open source 
it makes no sense helping documenting stuff but there is no chance 
to do this kind of thing if there is no info of what exactly is to 
be done, as an outsider you are always one step behind and if you 
invest precious time into some work only to discoved they already 
did this. This is not an invite to do anything.

Do you think that my above description of the needs is not enough 
for you to decide if you want to do it or not?

Keep in mind that even UTF-16 is not a fixed-size encoding. Each 
codepoint either takes 2 or 4 bytes.

UTF-32 (aka UCS4) is a fixed-size encoding. It's rarely used though.

Brian: right!

New branch pushed for namespaces/contexts support:

https://github.com/dockimbel/Red/commit/3f02688d00bfb69ba67342c3ebf661ebd17505f2

(see example code in the commit logs)

Exciting :-)

I was pretty sure you'd like that. ;-)

Please do not post tickets for this branch, the implementation is 
still incomplete.

It's really nice, and puts Red/System definitively above C

What exactly does it mean that cross-referencing is not yet supported?

For example: 
    a: context [c: 123 d: b/e]
    b: context [e: 456  f: a/c]

cannot be compiled currently.

I could live without that feature for Red compiler, but it will help 
it be cleaner and easier to debug. Currently, I'm using prefixes 
to mark contexts for variables and function calls in Red compiler 
output code, I hope to be able to remove them and use contexts instead 
once I merge this new branch.

I was hoping the demands for Red would push more REBOL features into 
Red/System :-)

We'll get two great languages for the price of one, and one is already 
here

That's fantastic.

Will it be possible to put #import's in a context?

Will there be something like USE or BIND to compile code referencing 
a particular context?

use gtk [view [label "dialect"]]

use [gtk zmq] [
	view label "dialect"
	send "message"
]

Yes, it will be possible to declare imported functions in contexts.

For your USE propoposition, that would be nice indeed. I'll look 
into it once contexts will be fully implemented.

Cool, thanks

Kaj: since latest commits in `namespaces` branch, you can now do:

ctx: context [
    #import [
        LIBM-file cdecl [
            sin: "sin" [
	    x           [float!]
	    return: [float!]
	]
        ]
    ]
]

print ctx/sin 1.0

;-)

Cool!

Great!

Is it/would it be possible to pass context as an argument to a function?

No, contexts in Red are not values, they don't exist at run-time.

ok, thanks

sorry, I meant Red/System, in Red, contexts (wherever functions, 
objects or modules) are first class values.

So, how scripting support wiil work?

oops, sorry I meant your previous comment: "they don't exist at run-time."

<from !Cheyenne group>


I'll have a look emitting the executable in the working directory 
this afternoon.

In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories

FEAT: added new WITH keyword for locally specifying implicit namespaces.

Usage: with <ns> [<body>]

    <ns>    : one or several block-enclosed namespace(s)

    <body> : code to execute within one or several implicit namespace

Example: 

    a: context [b: 123]
    with a [print b]

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.