World: r4wp

@Gerard: 


Red will allow to extend itself in several ways. New types could 
be added easily by defining a set of new action! functions associated 
with a new datatype!. Also, the language syntax and semantics themselves 
could be changed by using the internal compiler API (not sure I will 
implement that in the bootstrapped version to avoid compatibility 
issues with the final compiler version).

As you can see, these features are not related to the object model 
from the user POV, because Red (like REBOL) are not OOL to me (I 
mean by OOL, languages that force you to use the object model). Anyway, 
the article looks interesting, so I'm saving the complete reading 
for the time when I'll work on the Red object! datatype (not implemented 
yet).

I am also look forward to the first version of Red. And I am willing 
to rewrite my REBOL book into a Red Book.

That would be great Jerry! Another incentive for me to work even 
more on it. ;-)

With all the talk of Red ... are you aready working on it? I thought 
you are working on Red/System still?

I am too dumb to use Red/System .. so I'm waiting for Red too :P

Janko, that's just prejudice. If I can work with Red/System, anybody 
can!

Janko: yes, I am currently working on Red compiler implementation. 
I will push it in the v0.3.0 branch as soon as it is stable enough.

wowo!!

Thanks Doc for the explanations - I asked myself if the kind of extension 
you described were already possible with your current plans - without 
knowing or having to bother with the way the objects are implemented 
- your answer is good news to  me.

Keep up the good work Doc - we're ALL behind and with you  !

Doc, have a look at http://box.lebeda.ws/~rebolek/sintezar.zip

Compile file %sintezar.reds and see function ADSR in %env.reds. Even 
when I pass TRUE, EITHER always executes FALSE block. I tried to 
simplify it, but I wasn't succesfull, so it's bit bigger project 
than just few lines, sorry :)

Looks interesting. I can see how you're finding those expression 
bugs. :-) This is a really nice example of how Red/System can replace 
C

Have you tried swapping the order of the arguments for adsr to see 
if it makes any diffrence? especially putting the  adsr! argument 
in the last position..

Rebolek: thanks, I've reproduced the issue and I'm searching for 
the cause.

I've just pushed a fix for your issue. I know correctly get the TRUE 
block being executed when it should.

Doc, Not to rush you, just curious about the progress of Red and 
its Unicode support. Unicode is very important here in China. :-)

Red: I'm still working on both the compiler and the minimal runtime 
required to run simple Red programs. I have only the very basic datatypes 
working for now, no objects (so no ports) yet. I not yet at the point 
where I can give an accurate ETA for the first alpha, but I hope 
to be able to provide that ETA in a week.


Red string! datatype will support Unicode (UTF-8 and UTF-16 encoding 
internally). I haven't implemented Unicode yet, so if some of you 
are willing to provide efficient code for supporting Unicode, that 
would greatly speedup Red progress. 

The following functions would be needed (coded in Red/System):

- UTF-8 <=> UTF-16 LE conversion routines

- (by order of importance) length?, compare (two strings), compare-case, 
pick, poke, at, find, find-case
- optinally: uppercase, lowercase, sort


All the above functions should be coded both for UTF-8 and UTF-16 
LE.

Porting existing C code to Red/System is fine as long as:
- the C source code license allows it.
- the used C algorithms are fast and light on memory usage.

Please take some time to give good thought about this kind of things 
and specifying in more detail what is needed, so other people get 
a chance to help out with doing a little programming for Red (/system). 
While not everybody is a topgun like yourself, there is a lot of 
legwork that could be taken out of your hands.

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.