World: r3wp

You still ranting (on your own personal predictions), but not proposing 
anything, only wasting bandwidth...

what did the others here proposed ?

You should be reading this channel history instead of asking.

and I propose manything  but you are too limited apparently to understand 
them first is if you do things do them the right way not the rebol's 
way. You should sever ties from rebol community since they are not 
able to drive their own projects  how could they drive Red.

Those are main basic themes of conserns that will have a deep impact 
on Red you refuse to see it fine

and if I asked is because I rode the bunch of lame craps here and 
it's exactly the same amount of crap comming from the same people 
on any other topic here ...

dockImble how many of the people in the rebol community submited 
you lines of  codes for red/system ?

Look into Red's page on github and count them.

Red has a lot of submitters for this stage of its development, a 
lot more than I've seen from similar open source projects when they 
were this new. It's commendable.

if you do things do them the right way not the rebol's way

 That is a very presumptuous statement, so you hold the real "Truth 
 of the Right Way" :-)

i'm looking at the github i see dockimbel along every files and only 
Peterwoods for doc dir

you should look better, try the commits history.

Brian: I agree, there's more contributions that I expected for a 
project that is public since a month only.

I saw the commit history so there is a SteeveGit a Peterwood a earl 
this is what you call alot of people are you joking ?

and those people are the people from here ...

A month old.

you are on rebol's track you already did a dead born clone of rebol 
and red is going the same path but with R-sharp at least there were 
4 people working for it no 1 with 2 bug trackers

Are you saying that you want to contribute enhancements to Red? Very 
commendable of you.

BrianH sever ties with rebol do the things to aim commercial success 
then you can say for you interview to computers or time's magazin 
that yeah rebol was your source of inspiration for red ...

BrianH hum ? nope I don't want to contribute to anything  handled 
the rebol community way ;)

and  red is looking that way ....

R-sharp at least there were 4 people working for it

 You must be talking about a R# in a parallel universe, in our reality, 
 I was the only one working on it.

I saw more than your name on the R# source code I can list them for 
you to remain you who are they

I've listed 4 peoples in the README file, but Brahim's and Arnaud's 
source code never made it in the repository (project stopped before), 
Volker's contribution is a 10-lines C function. That's hardly a "4 
people working for it". I have written 99,99% of the released source 
code.

Anyway, aside from wasting time, bandwidth and trying to spill your 
negative emotions to all peoples here, do you have something useful 
to say? If not, I'll just go resume my work.

Please do, Doc

And what good work you've been doing! :)

DockImbel appart this is yet another joke and you prove it today 
? nope ...

To waste bandwidth you don't need me ... you are doing it cause like 
amibs you are only able to post here to exists

for more information about red referes there http://www.red-lang.org/
Instead of coliding with me dockimbel you could had just said that 
and nothing else it was plenty enough...

so red is compiled but then it's systeme dependant and we can't test 
small chunks of code like in R2 consol in my opinion one of the strong 
point of rebol was this ability to open it's consol test an epurated 
bunch of code and then once working enhance it on our script file. 
I would like red somehow to get that  ability maybe it will be possible 
in the IDE or as a side stuff. For me the 2 best points of rebol 
were reflexivity code <--> data code = data data = code and parse. 
Even if I didn't fully understand parse I made a great use in my 
productions in rebol script VID oriented of the reflexivity code 
<---> data. All the other arguments of rebol are not really interresting 
since they are double sided and so not objective and so just a matter 
of mood and point of view.

I.E: the rebol's VM size is small, that's an adventage if I work 
on a computer with 1.44Mo flopydisk as main support, it's just stupid 
if I have 1Tera e sata hard drive. Or rebol vm runs everywhere your 
script the same, you take area-tc and surprise it doesn't work on 
windows seven on linux and macOS X.  Or it's easy to do networking 
with rebol. If you do TCP or UDP yes if you do something else you 
are unable to proceed ... see that's always double side half truth 
in rebol and that's really what I don't want to see in Red this is 
not a big contribution but it's important enough for me to be said.

this seems fun p:   &[integer! 4000000h]   but then how do you know 
this adress is free and that it will hold the data you have in mind 
? will you be able then to make this countainer changing from integer! 
to c-string! ?

Those & things have all the advantages and disadvantages of pointers. 
You don't know whether there is anything there unless you put something 
there, same as C.

Interactive development in Red will require a JIT compiler. That 
is a bit later in the roadmap. Remember, the project is in really 
early stages.

There will be limits to code <--> data, because Red is compiled. 
Basically the same limitations as a modern compiled Lisp. Source 
code will be data, but not as much after it is compiled. However, 
when we get a JIT then that data --> code thing will be available 
at runtime. If it's done right, reflection APIs might be able to 
recreate or save source too.

A compiled PARSE would have limitations as well, certain patterns 
that would be impossible to recognize without dynamic rules. JIT 
might help here too.

Shad, I don't have a 2TB hard drive on my phone. Size still matters 
in some important cases.

In Red, variables inside functions are declared with a datatype, 
so I guess, it's not possible to change the datatype of such a variable. 
But what about global variables, is it possible to change the type 
of such a variable?

A related question: What if I create a function, the multiply a local 
variable of type integer with some global variable, and I run that 
function in a context, where the global variable is a string? Are 
the datatypes being checked at runtime?

the multiply -> that multiply

I'm thinking, maybe it isn't possible to change the context for a 
function!? I may assume things, because I'm "REBOL spoiled". :-)

Currently only the Red/System dialect is specified and implemented, 
so I'm not sure if the context of your questions is Red or Red/System.

In Red, variables inside functions are declared with a datatype, 
so I guess, it's not possible to change the datatype of such a variable. 
But what about global variables, is it possible to change the type 
of such a variable?


It is currently not possible to change a variable type once declared 
in a function. But such feature could be added, by introducing hidden 
additional variables for each new datatype a given local variable 
would be assigned to.

What if I create a function, the multiply a local variable of type 
integer with some global variable, and I run that function in a context, 
where the global variable is a string?
  The compiler will catch the type mistmatch at compile-time.

Are the datatypes being checked at runtime?

 Not in Red/System. Partial runtime type checking could be added at 
 Red level.

Change the context for a function

: that's not possible in Red, no dynamic scoping in Red, at least 
no in the v1. I confirm, you're "REBOL spoiled" :-))

One very strong feature in REBOL is that functions can take an argument 
of more than one datatype. You can e.g. READ a file, a url or a port. 
Do you see a solution for this in Red?

I think that such polymorphism can be achieved in Red to some extent. 
This could be done by inspecting the type of the value at runtime. 
A lot of REBOL flexibility can be supported by Red, but with sometimes 
a high performance penalty.

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.

Maybe invent a syntax, where part of the function can be split up 
depending of the type(s) of the argument(s)? Right, the type has 
to be checked at runtime, but maybe only once then. REBOL has to 
check types all the time, for everything from simple arithmetic to 
function calls, etc.