World: r4wp

That's why I said that incompatibility with R3 was part of the point 
to World. He went out of his way to talk about the deliberately incompatible 
features. The only thing left to distinguish it semantically from 
being something in the same category as R2, R3 and Boron was the 
256-bit value slots. Otherwise it was pretty much the same language 
model.

Red is a different language model, of course.

OK, I understand your point

The iOS theory is reversed, though. World is aimed at science, and 
then the iOS apps came just to make money for World development

That makes sense.

Kaj: LGPL? Sorry, I'm not expert at licensing.

Yes, very different

Unfortunately, we are forced to be experts at licensing

Boron is basically like R2, but with a Lua/R3-like library model 
with a different FFI from either, at least in terms of its major 
semantic model. Syntactically Boron has gone out of its way to adopt 
more C-like features here and there. The LGPL argument is more a 
personal and social thing as far as I am concerned, it's not the 
reason for the language design choices. You can tell the reason for 
the language design choices just be seeing which choices were made 
(assuming a reasonably intelligent person).

Still, there must be some factor at play that makes Boron unatractive 
to people. I just don't know what it is.

(people - most of current Rebol users)

Copyleft, even the minimal copyleft of LGPL, is a bit off-putting 
for a development tool of a Rebol-like semantic model. For reasons 
that only became apparent later, so I'm not knocking the choice in 
hindsight because of the results.

It's mostly a mystery to me too, but my best guess is the divide 
between free software culture and the old REBOL/Amiga culture of 
mostly American business

I liked the library idea though, it was cool. The C-like stuff was 
also off-putting for me, but I can see why you'd want it to appeal 
as a scripting language to a crowd of Posix users.

So you're also put off by REBOL?

One more personal experience - I never had the same fun playing with 
Boron that I have with R3 or Red/System (practically haven't use 
Red yet).

In general I'm not put off by Rebol-like languages, but the mix of 
Rebol-like and C-like stuff usually doesn't work. Even supporting 
C-like comments conflicts with Rebol syntax in ugly ways. C is better 
in C-like languages.

You have to develop R3 in C now

The only "C-like stuff" I can think of in Boron are 'c' for character 
syntax and comment delimiters. Not exactly earth shattering

Like I said, keep the C stuff in C-like languages. C isn't bad itself, 
necessarily, it has its place. But C syntax and Rebol syntax don't 
mix well. Putting C-like syntax, particularly their comments, in 
a Rebol-like language leads to ugly syntax conflicts.

Sure, but it's hardly used in Boron

It was enough for me to reevaluate using the language. It's implementation 
stuff was cool though.

You can easily define your own COMMENT function and not use /* */

It doesn't matter now. I'll use Boron when I have to though, it's 
still part of the family :)

I just never got very far with Boron.  I donated to it when I thought 
it could be a viable open source alternative to R2, but it's feature 
set never evolved enough to be useful for work, like R2.  That's 
been the problem with ALL REBOL related language tools for the past 
6 years or so.  That's what made/makes R2 attractive.  A full stack 
of usable tools for creating applications.  If the Saphirion guys 
and Doc build usable tool sets with mature GUI, sound, database, 
3D, etc. APIs, then people will begin to use those languages.  Boron 
never had any of those features implemented in a user friendly way.

Without those features, there's no reason for anyone to take a look 
at REBOLish stuff.  It's just weird syntax, as far as they're concerned. 
 Take a look at http://www.runrev.com/products/livecode/LiveCode/
.  18 pages of feature description.  That's an attractive list, and 
I think should be read by everyone here.  It provides some perspective 
as to how much work is required for Red to become a viable competitor.

Features like that need to be provided, not created by the user base. 
 There's no motivation for anyone to get involved if the feature 
set isn't complete.

That's why, even as a REBOL user, I never messed with Boron.  It 
takes less work to learn other languages and tool sets, than to implement 
a complex fundamental feature set required to complete basic work.

R2 provides enough of a basic feature set to make the language viable, 
but without those features I would never have had any interest in 
the language itself.

Livecode cross-compiles to any platform.  I can build Windows, Mac, 
Linux, Android, and Web apps, and X-code projects, with the click 
of a button *all on my Windows machine (or on a Mac or Linux box, 
if I want).

I still think as a full package, REBOL is better, but R2 is getting 
old an losing support for new, cool features and platforms.  If Cyphre 
is succesful porting R3 GUI to Android, it's got a chance.  If Doc 
gets Red evolved enough to support basic features, it's got a helluva 
chance.

an losing -> and losing

I don't understand the push to make both R3 and Red compatible. Sure, 
if it fits, why not. But if Doc decides, that he wants Red to be 
different in some aspects, then I am not sure it is wise to go on 
compromises. The question is, if we really need to merge those two 
projects.

Pekr: merge is not the point, that is not what we've discussed with 
BrianH, Andreas and Fork. The point is just not driving users crazy 
when loading code in R3/Red because of obscure and arbitrary incompatibilities 
in the syntax. Also often the same logic rules apply to syntactic 
choices in both R3 and Red. The best example are the rules for defining 
a word! (it's not that obvious when you consider Unicode).


Also the same remark applies to some basic semantics like indexing. 
Although the level of compatibility is at our discretion, we can 
diverge when we need to. I want Red to retain the best of R2, but 
fix some of its core design issues. Some solutions found for R3 are 
improvements over R2, there's no reason for Red to ignore them. Hence 
the common work between R3 and Red projects on some parts.

That is understandable, but it almost feels like a push - either 
do it R3 way, or it is your bug :-)

and btw - R2 and R3 are incompatible already, so why to bother so 
much? I would not like for any of the languages to take on some grey 
middle consensus - just do what you think is best ...

NickA: I fully agree with you. A bare Red core has low value and 
not much potential to attract a large crowd. Actually building all 
those user-level features will be the fun part of Red project, I'm 
looking forward with great appetit to the moment I'll be able to 
work on them. Also with a solid Red core, we could provide an even 
better user experience than Livecode, which, e.g. still struggles 
to handle Unicode fully:

http://www.runrev.com/products/livecode/text-and-data-processing/


We should mention that currently it’s perfectly possible to build 
applications that use Unicode in LiveCode, but there are some limitations. 
[...] We’re hard at work adding beautiful, seamless and complete 
Unicode support for a future version so please check back if you’re 
interested in that.

http://lessons.runrev.com/spaces/lessons/buckets/809/lessons/12304-How-do-I-use-Unicode-in-Rev-

In "Using character chunk expressions with unicodeText" section:

    set the unicodeText of field 2 to the unicodeText of field 1


Wow...doesn't look like Livecode scales up very well. In Rebol/View:

    set-face field1 get-face field2

(Sorry should have posted that in Languages group)

Pekr: for the part of the R3 and Red languages that are identical 
or almost identical, it would be counter-productive to introduce 
arbitrary differences (the whole point is in this "arbitrary" word). 
I still of course keep my full autonomy for deciding on Red. Anyway, 
I know I can count on you to shout on me if I take some user-unfriendly 
decision. ;-)

NickA: there are definitely some interesting ideas in the Livecode 
environment to have in Red too. We'll "steal" the best ones. "Good 
Artists Borrow, Great Artists Steal" ;-)

AdrianS: thank you for the Trello link, after a few minutes playing 
with it, I think I like it as it matches pretty well how I manage 
my own tasks on paper. I will test it further to see if I could use 
it for moving my personal tasks from paper to an online public place.

some problems where having an array  would come in very handy. (So 
I have the allocate sought out but I am not sure of the free, and 
my progress is really slow now). I am generally considered a good 
programmer by colleagues but there are specialities and different 
leagues, I am not playing in. :D 

R3 and Red both need each other to make the best case for both of 
them and attract a real momentum. Both need very much the same best 
solutions, yet there are differences to live with.

First line got dropped somehow: Agreed with NickA here. As much as 
I like to contribute time and random to Red/system, I face

(@Kaj, I know you added bindings for random :) I am doing it as a 
project for me to learn from).

Kaj: you'll have refinement and paths support tonight for the runtime 
lexer. I will add some more interpreter tests tomorrow and prepare 
for a new release (0.3.2) this weekend focused on the addition of 
the interpreter.

Arnold: you'll get your new blog article in a couple of days. ;-)

Also we need additional tests on Linux-ARM platform for regressions 
before the release, anyone?

Ok, got refinements and paths supported now in the runtime lexer, 
but I found some regressions in the interpreter wrt to set-paths 
evaluation.

Kaj, got your tickets fixed, if you have more of the same kind, just 
report them here, not need for a ticket. Like this one:

red>> a: 1 + 1

*** Runtime Error 1: access violation

weird bug indeed :-)