World: r3wp

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).

I think that BSD vs GPL does matter really much in this context.

It does to me. That is one of the reasons I can help out the Red 
project, but not Boron.

Yeah, it does to me too. That's why I started with OSX emitter.

Even id it's still not finished... ;)

That's why (after tax season) I'm going to try my hand at a Dalvik 
emitter :)

its also a very big issue for me.  GPL is the license for star trek, 
when there will be no economics.

startrek sounds nice but I think it's license for Mafia.

a lot of the people who do GPL don't work in the real world... they 
live in academia.

one thing I've always wondered... does MIT actually use the MIT license 
in their projects?

Yes.

Acade Mia...

and are they discouraged to use GPL?

I don't know. MIT is public funded, so their products need to be 
usable to the public. That includes businesses.

I think they also make money off patents though.

yeah... any invention eventually needs to be leveraged... that's 
ok.    and most high-profile research is funded by companies nowadays... 
I'm pretty sure its like that in all universities in the US.

The big ones, yes. The others don't do a lot of research. There are 
exceptions though; my old professor contributed to Pizza, which led 
to generics in Java 6, and indirectly in C# 2.

Max, you sound like Japan anime with "most high-profile research 
is funded by companies nowadays".

To be fair, research has more of a chance to become high-profile 
with marketing. Companies can afford more marketing.

a lot of companies go to universities for some specific problems. 
 they fund a specific project form a team and a professor and team 
has work for 2-3 years.  sometimes it goes through the school, sometimes 
it almost like "renting" the professor for cheap.

Doc is there any reason the shift functions (<< >>) are not implemented?

Yes, multiplication or division by a power of 2 are generating shifts, 
so the feature is available, the << >> operators are now just syntactic 
sugar, that's why their implementation has been delayed.

They are also missing from the specification doc because I am not 
sure it is worth adding them anymore. What do you think?

Humm, looking at it a bit closer, it is not totally equivalent: the 
* and / operators will generate shifts only if the right argument 
is a literal integer. So: 
    a: 4
    123 * b
won't generate a shift.

So, I guess the conclusion would be: it is worth adding them. :-)

I'll consider adding these operators to the specifications after 
finishing my current debugging on ANY & ALL.

a: 4
    123 * b
should be:
    a: 4
    123 * a

Will  << and >> be needed in order to build the first version of 
Red?

shift funcs are useful f.e. for checksums, securtity funcs etc. I 
thought the shift funcs will be produced using shift machine codes 
(i e single operation). Is there some kind of optimalization for 
multiply/delete by pow of 2? Also consider not to implement overflow 
for << (true shifting)

Peter: strictly speaking, they are not needed because they can be 
emulated by math operations. However, on CPUs, the speed difference 
with true shifts is huge (one order of magnitude at least). I can't 
say yet how much shifts will be used in Red's runtime (mainly in 
memory manager) because in some cases, bitfield operators could be 
used instead.

I was wodering if you could perhaps live without them until the version 
of Red/System that will be built with Red.

wodering -> wondering

Speedwise, certainly. But as the Red/System code that will be written 
for Red's runtime will stay, syntactic improvements are worth considering 
now.

It is a matter of writing, e.g.:
    123 >> 16
instead of:
    123 / 65536

It is certainly more readable.

I'll  guess that  the next request will be for an unsigned integer.

BTW, Pavel is right about the overflow error checking (which is still 
pending for math ops in the current implementation), it is not required 
for shifts.

Doc it would be very helpful to publish (maybe as picture) workflow 
thru respective modules (files) because for non expert it is quite 
difficult to see what is going on each module.