World: r3wp

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.

Also, I have an item in the todo list for "Hex values syntax checking". 
I guess I'll add some rules to avoid ambiguities as much as possible. 
For example, having to use uppercases only for hex letters would 
help. Allowing only 8 or 6 or 4 characters with prefix zeros when 
required should also help.

add it the variable
 => add it to the variable

Is Red proper going to have this hex notation, as well?

I fear it is going to lead to problems if not all words are available 
to use in a context. Suppose there is an external source of data 
with named values that map naturally to a context. The ability to 
import that data easily will be broken if certain words are interpreted 
as hex values

Is the longterm goal to make an open source rebol-like language?

Definitely

:)

If you want a REBOL like language earlier, use Boron

Who started boron and red?

dockimbel. Sorry, I've got to stop asking stupid questions.

Boron is Karl Robillard, Red is Nenad Rakocevic

Kaj: I agree with your arguments, I don't plan to use that syntax 
at Red level, I would rather rely on either issue! or binary!.

padding with zeros and uppercase only sounds good.

(prefixing)

Peter was asking a question about c-string! syntax. There is no need 
to have separate syntax for c-string! and string!. Red/System should 
only have c-string! literals; the string! type is likely to be *implemented* 
in Red/System, so the type name would only be needed to refer to 
values that Red/System is constructing or converting to or from. 
Red itself shouldn't have a c-string! type because it's unsafe, same 
as the pointer! type. So you can use the same syntax for both string 
types: In Red, they would be string! literals, in Red/System, c-string! 
literals.

It's a bootstrapping thing. The advantage of a compiler is that the 
source can refer to any datatypes you want it to. Even if the compiler 
is written in Red or REBOL, string literals that may be of the string! 
type in the compiler can be used to represent a different datatype 
in the resulting compiled code.

Nicolas: "Why is it more popular than boron? Did the boron guy start 
red?"

A few apparent reasons:
- Red is new (shiny!).

- Red is compiled, which is a new challenge for us. Boron is interpreted, 
like REBOL.

- Red is BSD licensed; Boron is LGPL licensed. Most of the REBOL 
community is not very (L)GPL-friendly for various reasons, such as 
license incompatibility with REBOL.

- Red being compiled and BSD means that it doesn't directly compete 
with REBOL, and is considered to be complementary. We might even 
be able to get them to work together directly without causing license 
problems. This means that more people who contribute to REBOL itself 
can contribute to Red as well, which means that there are more qualified 
contributors available early on.

- Doc made Red, and we like Doc, and he is here. Karl Robillard is 
not here, afaik (I'm sure we'd like him if given the chance).