World: r3wp

I also have rules which are self-modifying based on content.  the 
last item in the some [... | ....| .... | ]  can be added on the 
fly.

Maxim, but is the rule empty at parse time?

AND, NOT, STAY, IF and REMOVE don't advance either, and OPT might 
not advance.

the only specific instance which is a valid "trappable" nop is 
parse data [some []]

the moment the rule after some has some content, its possible it 
will modify rules on the fly... so AFAICT by sunanda's examplel above, 
is that Carl already addressed the purely empty rule in R3, but a 
rule with content which has an empty "ending" rule, that must be 
allowed, its part of the features of Parse.

if the end result is a hang per definition, is the empty rule then 
of any practical use?

how often do I use forever [] ? I guess that exactly as often as 
some [].

Given that the actually emmpty rule case is also the most likely 
to be caught by a simple visual scan, is it worth special-casing?

My POV is, that such rules have to be handled "regularly", for teaching 
purposes. It does not make any sense to me to special-case these.

BrianH, how do you visually inspect:

parse [a b c] [some my-rule]
... 100000 lines later...
my-rule: []

It would be the same with a rule containing none, not if, and stay, 
opt, remove, insert, change, parens. Why special-case the easiest?

Awww, it will never append.
1/ there's not such monstruous script with Rebol.
2/ Bad coding practice, you don't respect locality

I think the point is being missed. I'm not looking for an error, 
when an empty block is scanned, when the parse expression is being 
built. I would of course want to modify my parse rules as I see fit. 
It is *right during parse time*, that I think there should be some 
kind of indicator that, we've hit a road block:

1. We're not moving
2. We're not processing any rules

3. I'll just do this 50 billion times, until my user gets tired of 
it.

Parsing, moreso than regular programming, is something you need at 
least a basic understanding of to do properly. That means learning 
stuff :(

That indicator needs to be resolved at programming/testing/debgging 
time. And you can use SECURE 'eval at runtime if all that fails.

(once that works)

The SECURE bit is only acceptable, if it throws an error rather than 
quits.

SECURE throw

That works already. It's only secure ask that doesn't.

doesn't seem to work for forever []

I meant the throw action of the evals (or is it eval ?) constraint.

I'm not as familiar with SECURE in R3 :(

The syntax, I mean. I'm familiar with its limits.

it seems that you can't escape a forever [] either. oh, so useful. 
:-)

You can't escape while [true] [...] either. What's your point?

works perfectly fine in R2.

well, it could be a console problem.

And in R3 the same, except you need to engage the keyboard handler 
before it reads. You can escape forever [prin ""].

It's a leftover DOS thing :(

I see. Ignore the "oh, so useful" bit, then. :-)

but: Why then can a hanging parse not be escaped in R2?

It's a bug. R2 has a lot of those.

If that is fixed in the final R3 console, then all is forgiven. I 
assumed that it would be unescapable in R3 as well.

No, that bg was fixed in R3. Every once in a while PARSE polls keyboard 
input looking for ^C.

Is it likely that we'll ever be able to parse a map!

parse a map!? You mean map! instead of block!?

BrianH R3 is open source but not open access.... hihihihihihi

My point is if you want dianamic particiapation on enhancements in 
rebol3 anyone should be able to access the  whole code as "reader" 
at least. I mean for example i want to bring a sql-protocol like 
enhancement but able to be used in the inner most layer of  rebol 
VM ...  if i can read the source code of the whole WM that allows 
me to get a better understanding on how the layers are made and how 
to do my intgration then I can come with my proposal and "offer it" 
to RT rt keeps the final word on new things integration based on 
community work . RT so remains the controler and the single diffusion 
source of retail R3 VM ...

shadwolf - nonsense and excuse.

You can implement SQL protocol with the knowledge of REBOL level 
stuff, plus e.g. extensions. For mySQL (socket based), you don't 
even need extensions. The only thing I can see is missing, is good 
enough docs ...

Have you EVER looked into mySQL, postgress or SQLite protocol sources? 
Becuase I did, I even helped to fix them. There is no single bit 
of REBOL VM, which would help me to understand or fix the protocol. 
Hence - I can see your post as typical pro-open-source rant :-)

But, in the end, I just don't know - if it really would make you 
happier, maybe RT should consider at least SDK level read-only licence 
of REBOL :-)

pekr i was one of the first in seeing them :P

and they are made that way because at that time rebol VM  was closed 
and obdc:// layer wasn't a default "open" solution...

Just answer to yourself - if you would get those sources right now 
- would it somehow magically make you more active in rebol scene?

pekr why using net sockets when you have even faster better ways 
to access the data in you base

with mySQL? ok, here we go - tell me :-)

Pekr the difference is that doing a script passing commands through 
net sockets and dialect translation isn't the fastest way ... but 
it's the easier to implement and even so when you don't have access 
to the direct content of the "black box"

What's missing is a REBOL storage mechanism like RIF which would 
enable developers to layer an access API (such as SQL) on top.

I took SQL things as an example because Carl was rubbing his head 
on a the wall trying to figure out what "SQL  like language" was 
the most suited to integer in the VM . But yes my be i understoud 
it the wrong way...  thing is SQL server are out of the box things 
and it would be better imho to keep them as external script doing 
the way we done them until now. I'm not sure we would benefit integrated 
them into the "black box" (R3 VM) if we then don't have the means 
to follow the product update...  If that's to produce a VM able to 
talk to a precise SQL server version under spécific circontancies 
I don't see that as a gain ...  AT least the scripted way is easy 
to maintain and run the same way under most circonstancies.

Shadwolf - I think that parsing SQL commands and results over sockets 
is not the most intensive and time consuming thing in DB area. The 
most of the work is done by the SQL engine itself ;-)

Ashley - I wonder what will happen to RIF ... no words on it, so 
imo it will not be done for 3.0, maybe 3.1