World: r3wp

that should be corrected, before another release with non desired 
behaviour comes out ...

That was the most important feature of AND.

Damned altme, another lost post ...

I am not sure I understand the purpose of THEN. I would like to ask, 
what is the difference between following two cases?:

rule1 rule2 |  rule3
rule1 then rule2 | rule3


- in both cases, rule1 has to be matched in order to proceed to rule2
- in both cases, if rule1 fails, then rule3 is applied, no?

Just edited the parse proposals, based on recent discussions. Added 
a STAY proposal, renamed EITHER 2 to THEN, added the controversy 
to the priorities section.

by naming => to 'then, we also probably lost the advantage to combine 
it with numerical value allowing us to choose a "branch"?

Pekr, the advantage is that if rule1 succeeds and rule2 fails, rule3 
is skipped instead of backtracked to.

It will look silly with the numeric branch, but the functionality 
will still be there. Plus, it will look better with a rule1 that 
includes IF.

rule 1 including if? You mean IF proposal?

THEN ... like "When Rebol finally wakes up to their lame license 
THEN it may succeed"

Terry - your first post after XY months, and insulting?

I say - f*ck the licecne - that is for lamers to complain about :-)

How do you know what R3's license is, Terry? Have you read something 
we haven't?

http://www.youtube.com/watch?v=yp7r0j4XrO8

Don't see how that is on-topic in this group, though it's funny.

BrianH: we can hear it once and once again - open-source mantra. 
Well, your question is absolutly correct - noone knows the licence, 
yet ppl are complaining. We now have much more important stuff to 
solve. I expect RT keeping to its initial promise = host code = open-source, 
interpreter = closed source. But even with closed source Core, we 
have daily ability to influence its design. Parse project (and not 
only that) is clear example. If the community would not define it, 
it would not happen. Now why do I need Core to be open-sourced too? 
Maybe because of resources. But then - I can imagine 10 incompatible 
versions of R3 flying around ....

Terry - good night and be happy with all the open JS, html, and other 
very nice technologies :-)

BrianH: do you think we will get USE and INTO implemented for the 
first round of parse redo?

It's simple: Either the license will be acceptible to me, or I'll 
switch languages or make a clone. No problem :)

Because of that, I can be sure that the license will be acceptable 
to me.

BrianH: the worst thing is, that even if R3 would be open-sourced 
NOW, there would not be any new activity around. There was an ORCA 
- how is that there was very little community involvement? Open-source 
proponents would win their arguments, but they also very often expect, 
that millions of hours of new forces will magically appear and shift 
the projet to the new level.

... whereas the opposite is true. Carl asks for feedback. How many 
ppl gave Carl feedback towards VID? Me, you, Henrik? How many ppl 
do comment Parse? 5 - 8? So - let's concentrate upon finishing the 
plan with what we have, and save our complaints for later.

The simulation I've been running of Carl isn't good enough to replace 
him, so forking isn't that effective :)

Only blind can't see the advancement R3 took in last 1/2 a year. 
Hundred of tickets addressed per month ....

BrianH: re tasking - any new idea of what we are going to get, with 
what Carl said yesterday?

And I am quite satisfied with the parse feedback, especially when 
you include the original enhancements and the initial proposals during 
November through January.

Re: tasking, yes, I think I got it. Now I have an idea about how 
to review/nudge the proposals/tickets.

What is the outcome of Steeve's proposals? Carl said something about 
inlining of REMOVE. Will it change from the index based aproach, 
which is now implemented?

It won't be a pure erlang-style shared-nothing approach, but the 
message-passing will be there. We can optimize accordingly.

message passing? I like that :-) Amiga anyone? :-)

In alpha 83 we had a (broken) implementation of the REMOVE 2 proposal. 
In alpha 84 we will have REMOVE 1 instead (Steeve recreated this 
proposal). Let the best proposal win - I'm hoping for REMOVE 1, since 
it's nicer (if less powerful).

REMOVE 1 was my original REMOVE proposal, back in November.

It definitely seems, we are getting Device Extensions, right? (anticipating 
it according to yesterday's discussion)

It's a really high priority.

What will it allow us to do? Any real-life example?

Asynchronous calls, callbacks, synchronizing with external code. 
Database access.

SSL

OpenGL, etc.

Why you need it for DB access for e.g.? Is it because you simply 
want async behaviour, and that is only possible via stand-alone device? 
So we will e.g. implement SQLite.device?

re REMOVE 1 vs 2 - couldn't we have both? Simply either rule is following, 
or index? :-) Both seem to be usefull ....

Yup. It will be required for synchronizing with multi-tasking R3.

We really can't have REMOVE 1 and 2 both - the rules don't match, 
there would be ambiguity.

What is the Device model though? We have not seen any examples yet. 
So you take extension API, create some SQLite.dll (extension), and 
integrate it via Devices API?

Then let's have REMOVE 1, to make Steeve happy :-) He is right that 
index aproach still can work in terms of storing a position into 
variable and doing REBOL level remove in parens ...

Look in the port model docs - they talk a lot about devices. The 
only thing added will be the ability to write your own.

Two new blog articles. Release notes updated too ...

Regarding the R3 web console: I'm bowing out as the back end seems 
much more complicated to do than I thought. There are also still 
security issues. I'll gladly hand the source to someone else, if 
they want to continue.

BrianH and I work together well, but the two of us alone are not 
enough!

.... It's about 10  years the rebol ommunity tells you can't do all 
alone and you need to open the source code... this doesn't means 
the final integration word is not yours... This doesn"t mean that 
you will have 100% ready to go additions. This doesn't  mean that 
rebol VM  will be stabilised to less than 1Mo ... More you have embeded 
feature hard written in the VM bigger it is that's why the "extension" 
approache is good.

Then the VM can be seen a minimal execution environement able to 
run any ind of things ... that the way most of the "regular" script 
languages works.

i like tht way to resume parse action car "Match then Action"  then 
the problem is when you match somthing then you when your action 
not to impact on the match thing but on the following  or preciding 
thing. The index system is the main problem in my opinion:  where 
i am ? what does i store  and until what point ?  i'm before or after 
my match ? and if my match is not  given in the right way how can 
i be sure my match tags are not taken inverted and that my action 
system will not freak out ?


Programming in parse gives you so many "asks" to care about that 
you are fast lost. But i'm agree the  result of parse rules in general 
once understoud (if it's any time the case ) is easy and beauty full.

and i think parse is already a big enhancement compared to regular 
expression ( i give a try to it past week writing a software in ruby 
... that's horrible ... I mean i'm complaining about parse but regular 
expression is so much a bore and stupid to write + they don't allow 
any action they are just made for match  only way to have regular 
expresion doing something is in ruby using them with an action mathod 
of the string class..... And that the kind of stupid things most 
of  coders in the world today found fantastic ??? HOOOO  really ???)


So when we come from mystring.match( "/\d\w***.*" ) kind of things 
of course going to the match action parse way is complicated... but 
complicated maybe not the way it's supposed to be.

Parse works better on "tags" words matching more than cabalistic 
formulas like regular exapressions. This doeasnt means it can't be 
doing that too..