World: r3wp

Clearly there has been some internal change in the handling of empty 
rules:
   parse [] [some []]
R3: ends immediately
R2: takes 90+ seconds

Sunanda, so that's why I thought it was fixed...

and there is a more common error which cause endless loop in parse
some [... | ....| .... | ]   <- nothing after the last |

Ladislav, ok how often do you use forever [], then?

Steeve, precisely!

but you might want the parse to loop forever.

Well, that's new, Sunanda. Steeve, an empty alternate is the same 
as none.

precisely what ?
you can't establish a list of all the bad coding practices

since some of the rules in steeves example aren't empty.

Steeve, there is an empty rule. (it seems that we can't agree what 
a rule actually is)

That is why we have ?? and TRACE.

I have ending rules which switch on/off on the fly.

(become none or are suddenly filled with a condition which enables 
an exit)

An empty rule is a legitimate shortcut for none, and is not necessarily 
an error either as an empty rule or as none..

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!?