World: r3wp

if a rule constitutes the part in the block and the block is empty, 
I don't see how that is useful.

I think the 'some loop highlights the important need to extend 'secure 
to cover parse.

That's an effective way to rein in loops on dynamic / user contributed 
parses -- such as Henrik's / Kaj's "Try REBOL 3" web sites.

as steeve says... forever [] isn't usefull either.  at some point 
you have to understand a bit of what you are doing.


the only thing that really happens to me is hitting the end, and 
not realizing that something in my some or any is preventing the 
rule to go "past" the end.

if the empty block is constructed later, it can be useful to not 
prevent their existing

Sunanda, yes, that's one reason I halted the project.

Steeve, would it be empty right at parse time?

Henrik, the problem is not that the rule is empty, it is that the 
rule doesn't advance the position. Complex rules can not advance 
too.

yes, but not with some [ ] or any [ ]

BrianH, but empty rules do per definition not advance. Why not per 
definition then cause an error?

I can see that all situations can't possibly be avoided, but these 
stupid little ones, I'm sure they can.

It's irrelevant. Empty rules are easy to debug, so that won't be 
a problem for beginners. It's when complex rules don't advance that 
is the problem.

I disagree that it's irrelevant. It's hellishly annoying to have 
to wait for the parser to finish on an empty rule, when you are working 
with PARSE in the console.

Don't be that short-sighted, Henrik. Since the Parse dialect is intended 
to be Turing complete, there is no way how to "automagically" detect 
all such cases!

Removing support for PARSE [some []] means removing support for PARSE 
[] - inner blocks work through recursion.

Ladislav, how hard is it to detect an empty rule and cause an error?

you really mean it, that forever [] should be automatically implemented 
to cause an error?

Sunanda, SECURE 'eval already covvers PARSE.

Ladislav: I don't know? It seems like a good idea and it's a bad 
way to pause a script. Rather use WAIT. But it's unrelated to empty 
rules as they are a side effect of PARSE.

not for PARSE currently IIRC

Secure doc say: <For example, PARSE cycles are not yet counted.>
http://www.rebol.com/r3/docs/functions/secure.html

Ah, well that should be fixed then :(

i hope they will be never counted, because it will slow down the 
process...

Henrik, forever [] and some [] are unrelated just for you; not for 
me.

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.