World: r4wp

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

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


Not always. R3 isn't done yet either. Remember, we're still catching 
up with a 2-year backlog of pending design changes. Some of its design 
experiments have turned out to be bad ideas for reasons that weren't 
known at first, or in some cases discovered by Red. So sometimes 
R3 is the one that needs fixing, and much sooner because R3 is going 
to get to 3.0 long before Red's design is set.


There are real advantages for Red and R3 to declare that incompatibility 
in comparable situations should be considered a bug, especially then 
it comes to syntax, and sometimes when it comes to semantics (ie 
indexing). But I don't assume that either R3 or Red in in the right. 
More often these incompatibilities are a sign of things that haven't 
been fully thought through, and once they are it could be R3 or Red 
that needs fixing, or in some cases both.


But, in the scale of history, Red is much earlier on in its design 
process than R3 is. R3 is more towards the end, closer to release. 
So that means that any changes that might break the *core* semantics 
or syntax of user code need to be made very soon, before 3.0 comes 
out and sets the standard. Red can afford to make those changes later 
because it isn't anywhere near the point of standardization. So if 
there are design flaws in R3 that might be comparable to something 
that would affect Red, they need to be fixed earlier in R3 (not by 
the Red people unless they're into that). And it would be useful 
for Red if people would participate in the R3 design discussions 
for stuff that would affect Red too because Red would benefit from 
the discussions regardless of compatibility, and also benefit from 
being compatible with the results.

and btw - R2 and R3 are incompatible already, so why to bother so 
much?
 - see my post in !REBOL2.

Pekr: we don't have much regression tests for the interpreter yet, 
so regressions might have happened during the last set of interpreter 
changes. Also, some edge cases have not been tested yet, we'll probably 
find more of this kind of bugs soon.

I wish I could switch to a more TDD approach asap.

I've been trying TDD out for R3 and it works pretty well. I usually 
have to expand or change the tests afterwards based on stuff learned 
while fixing the problem, but as long as you're OK with that it works 
great.

If you are a TDD purist and insist the the tests not be changed after 
you do the fixes, then the process fails horribly.

I am sure everybody here is really looking forward to that next blogentry!! 
:)

The tests reflect the specification, if the specification changes, 
the tests must follow.

Ah, so you are doing spec-driven development. For TDD the tests are 
the spec.

I'm not a TDD purist. ;-)

Neither am I :)  I tend to put stuff in CureCode first, resolve the 
design issues there (especially if they need community feedback), 
then add or fix tests in rebol-tests, then do the fix. If I learn 
more while doing the fix, sometimes the tests need more work, and 
sometimes the ticket needs changing. Or rejecting, because sometimes 
while doing the fix we find out why it's a bad idea.

BrianH:I don't believe a single second for R3 becoming even beta. 
Three or so years ago I wrote, what makes a good beta for me. So 
here it comes - give me a console, not a crap. Give me smtp, ftp 
etc schemes, without an excuse. Give us odbc, mysql, postgress, give 
us CALL. So - no matter how much advanced R3 is to R2, in a sence 
of a complete package, it is still pre-alpha ...

R3 is not TDD, it is a long time - TBD :-)

Wrong group, switching to !REBOL3.

Nenad, what kind of timeframe do you see for implementing parse? 
I didn't see anyhting on the roadmap.

State of Red's PARSE: 


It's not on the roadmap because it's too low-level for the bird view 
(maybe I need to add it anyway?). Moreover, PARSE is not (for now) 
useful for the internal construction of Red/System and Red, so from 
that perspective, it's quite low-priority.


OTOH, it is quite simple to implement in Red/System, and users could 
see that as a sign of good progress, so I probably need to schedule 
it for a weekend to implement a R2-level PARSE (with a couple of 
features from R3's PARSE) and a few more days to test and debug it.


Also, Gabriele is interested in implementing a "compiled" PARSE version 
for Red, but unfortunately, Red has not yet all the features that 
Gab needs for it (mainly object! support). So, he's waiting on me 
to get Red ready first.


As currently, object! support is much more important to implement 
(for completing the context/binding model of Red and enabling ports) 
than PARSE, you might get Gab's version first. Also if it's fast 
enough, I wouldn't need to make a Red/System version then.


Last but not least, I don't agree with 100% of the changes/addition 
in PARSE for R3, so I would need to review R3 parse and make a "cleaned-up" 
version for Red. Also, Topaz has some interesting improvements on 
PARSE what I might want to include in Red's version too, so that 
needs a bit of preliminary review work.


So, as you can see, it's hard to give you a precise timeframe, I 
guess we would have a first version of it during Q2 2013.

If your review of R3's PARSE generates some criticisms, be sure to 
let us know. I am already looking at Topaz for ideas, your ideas 
would likely be useful too.

Some of the design choices for R3's PARSE were the result of inevitable 
side effects of its implementation model. Some of those choices would 
have been different with a different implementation model, particluarly 
with a compiled dialect. If you had a compiled dialect with rule 
functions, for instance, most of the operations would be converted 
to those functions and the dialect would be very lean indeed.

For instance, there is at least one bug report for R3 related to 
increasing the number of delimiters that should be rejected because 
implementing it would drastically reduce the readability of code 
written in any Rebol family language. If Red implemented that proposal 
it would be a bad thing for Red as well for the same reasons.

 -- my proposal is to write a special AI filter that checks for each 
 word user writes and resists to evaluate it if it reduces the readibility 
 of code. IMHO we surely can't say that ony specific delimiter reduces 
 readibilty and anything else a stupid programmer might cobble together 
 with the ones left doesn't  <-ironic .. I hoped the comma wars won't 
 have to continue in Red also :(

Some of the new operations were added to reduce bugs by having clean 
implementations of things that PARSE users frequently need to do 
but usually get wrong, such as CHANGE, INSERT, REMOVE, IF, THEN, 
AND, NOT, QUOTE and DO. The modification ops are the ones that lead 
to the most frequent R2 parse errors.

(I say this because your proposal is that red and r3 should have 
the same syntax rules for the same datatypes, like words)

Well, word syntax in R3 needs some work. There are tickets about 
some of the problems already.

I am not 100% if I understood your text correctly. Did you say that 
the bug report was about "increasing the number of delimiters which 
should be rejected" or that the bug that was "about increasing the 
number of delimiters" (well I don't know what this means, the only 
delimiter now is space and even nospace at brackets etc) and the 
bug report should be rejected?

The latter, the ticket needs to be rejected, I was wrong. There is 
another ticket about adding support for Unicode whitespace as delimiters, 
and we should probably try to figure out how to implement that one 
(though the zero-width spaces are a bit iffy).