World: r4wp

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.

All the old bindings still work with the namespaces branch, except 
I'm getting an internal compiler error on my OpenGL binding, but 
I'm not sure it's my latest code

Having the compilation in the working directory would still be nice 
for the release

CONTEXT as local variable: that shall be allowed, I'll fix it.

Compilation in working directory: I'm adding it in the todo list 
for the release.

Other keywords such as IF are also prohibited as local variables. 
I don't know if it's practical to change that

Are #enum's local to a CONTEXT?

IF and others keywords: you surely don't want to mess up your code 
(and the compiler) by redefining them. For CONTEXT, you can't use 
it inside a function body to create a namespace (would need to test 
if this case is correctly caught and raise an error), so it's ok 
to allow it as local name, no possible ambiguity.

#enum: nope, as #define, they are global. I wonder if it is worth 
(and possible) making them namespace-sensitive. 

Oldes (who implemented them), what do you think?

I think they should be local. That's what makes them fundamentally 
better than #define's

I have a lot of #define's in the bindings that I'm now migrating 
to #enum's, and that would be left behind looking out of place once 
I move the bindings into contexts

That also goes for dialects such as GTK. In a WITH context they look 
much better, but they would still not be abstracted if constants 
in them would still need to be prefixed

Added support for enums in namespaces.

You can also access locally defined enums from outside using path 
notation.

That was fast :-)

Just a note: the 0.2.3 milestone is still open on GitHub

I've updated all my bindings to use enumerations now, and found some 
bugs in the process

I'm actually behind on using the newer Red/System features...

What happens with alias detection in contexts?

For example, I have a check type = system/alias/gtk-window!

Should that become system/alias/gtk/window! in a GTK CONTEXT?

Alias: let me check that...

Aliases should work as before, they do not interact with namespaces.

So it should be: system/alias/gtk-window! unless there are bugs (I 
think we haven't tested mixing aliases with namespaces).

But system/alias/window! will lead to clashes with window!'s in different 
contexts

Milestone 0.2.3: can't find how to close it...github's UI keeps changing 
all the time, always feel lost when I have to do rare actions...

Aliases are not context-aware, they are globals.

Ok, I've just deleted the milestone instead of closing it.

I think aliases should also be context-local, then. I'm using them 
heavily as types

That would have some complications in using them as parameter types, 
though. Maybe I should try how it works out keeping them global first

Yes, that would require to add a lot of new code to existing features 
and would take probably several days to code and debug regressions. 
If we could avoid it, that would be nice.

Are aliases used (semantically) in Red the same as they are in Rebol?

I'll have to keep alias names prefixed. We'll see if I can keep that 
from leaking through in dialects

Aliases in Red/System are names for C-like structs. It's quite a 
different concept as anything that would be called an alias in REBOL

Aliases in REBOL are for words only.

In Red, I'm not sure that I will implement ALIAS support (as in REBOL), 
it seems that's a feature that has been very rarely used since the 
beginning of REBOL.

I think it needed to be in there because Amiga DOS has it :-)

Good old AmigaDOS. :-)

From the R3 documentation:

Aliases are special because they work at the symbol table level, 
allowing them to be used for refinements and dialect words as well.

So it would be the only way to translate refinements and such

I think Jerry will want that :-)

It will answer Chinese people's question of "Why not Python"

I'm not sure ALIAS could be implemented in Red, we'll see, if it's 
not costly, I'll add it.

I'm interested in making a Red dictionary that will allow people 
to program in Frisian :-)

Now that non-English languages are up-and-coming in programming, 
it could solve the fragmentation of the available code pool, if you 
would implement an extra feature that would allow code to be saved 
and loaded with an ordered list of preferred alias languages

Just write a parser that calls Google Translate and does in place 
substitution.

The results could be hillarious.