World: r3wp

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

thanks

Geomol: I thought people were already used to go to http://www.red-lang.org/p/documentation.html

Some of us are new in looking at Red, so we need a bit of help.

http://red-lang.orgis the hub centralizing the links for all Red-related 
stuff.

I'm getting back to code now, implementing all the items from this 
list: https://github.com/dockimbel/Red/wiki

Added link to Checklists/Links

I forgot that such feature existed in AltME (as for Calendar and 
File Sharing).

Regarding hex form of integer. What if someone write:

ah: 42
foo: ah

Should foo be 42 or 10 (= ah hex)?
Maybe hex integers should require prefix zero in this case?

It will be 10 because the preprocessor would have converted it early.

So variable names starting with a-f, consisting of a-f and 0-9 and 
ending on -h isn't possible.

No, and I should add it the variable syntax section in the draft.