World: r3wp

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.

The compiler could be made smart enough to do that without altering 
the original REBOL syntax (or maybe just marginally). The question 
is, can it be done without making the compiler code too complex to 
maintain. :-) There's also the JIT speed constraint, the compile 
would need to be fast enough for that case too.

An overly complex compiler is probably not a good idea.

Doc, do you intent on creating a payload+accessor model for the types 
in Red?

As I don't plan to have different semantics for the Red code statically 
compiled and the code JIT-compiled, the supported Red semantics would 
need to compilable fast enough. That will be one of the main constraints 
that will finally decide what REBOL features can or cannot be supported.

Max: I'm not sure what you mean by that? Could you elaborate?

for the more obscure types and also for user-creatable types.... 
basically they are classes which have a specific and non-extensible 
set of methods with an arbitrary content which is used by the interpreter 
directly.

they could be a third broad datatype.   slower, but more flexible.

when the compiler uses them, it uses the code in the 'methods' instead 
of its own to assign and retrieve data.

which is used by the interpreter directly
 There is no interpreter in Red...you mean compiler?

I do not plan to support such feature directly. But the code is open, 
and I will add a plugin API to the Red compiler to allow it to be 
extended by third-party libraries. You'll be able to implement classes 
with accessors if you need them.

maybe it is intended but your changes to doc in git is not reflected 
in red-lang.org docs

It is intended, I'm updating the HTML docs only then a revision is 
completed, which is not yet the case with "draft 3". It should be 
finished in a few hours and the HTML docs updated by tonight.

I suppose that means you should fork the repository, develop the 
documentation in the branch, and then merge it back :-)

After re-reading the new specs draft, I noticed a few errors in the 
pointer! examples. Also, I think that having struct! passed as value 
by default was a bad move, it makes the "passed by reference" case 
too verbose (requires to declare a pointer! [struct! ...] and a get-word! 
syntax). I think that I'll revert default struct to be passed "by 
reference" and find a special syntax for the extremely rare cases 
when a struct needs to be passed by value. I can't remember any OS 
API nor mainstream C lib that require passing struct by value (anyone?).

I agree to all.

I've made some drastical changes on pointer! datatype, to clean up 
the mess it brought (syntax ambiguity and verbosity, semantic clashes 
with other implicit pointers like c-string! and struct!). The new 
specs draft simplifies all that. I'll push it online in a hour.

Sounds very good. Look forward to reading the new specs.

Draft 4 published.

Links are nice with announcements like that.

http://sidl.fr/red/red-system-specs.html