World: r3wp

Wouldn't it be great if it was just a matter of opinion?

one thing I don't clearly understand in the above....


* Code that is not nested in the main loop block would not be able 
to break from that loop

Definitional (whatever) depends on a BIND to do its work, deep, usually 
BIND/copy. And that only works on words that are physically in the 
blocks that you bind, or in blocks that are nested in those blocks, 
etc. Another block that is outside the block you are binding and 
referred to by name won't be bound. That is the limit of the definitional 
approach.

Note that the definitional BIND that functions do when created is 
*not* a BIND/copy, it modifies. Same thing with closures when they 
are created, though they also do something like a BIND/copy every 
time they are called.

oh yes, definitional * is complicated with references... hadn't realized 
that.

Ladislav, your definitional throw in the "Definitional CATCH/THROW 
mezzanine pair" section of your page isn't recursion-safe, because 
MAKE function! does a modifying BIND rahter than a non-modifying 
BIND/copy. Otherwise, nice work :)

It's not task-safe either, but recursion-safety is more of an issue 
for now.

That's the one under "The state of R2 (dynamic return with optional 
transparency)".

btw, for throw/catch, I agree 100%, even after I now, fully understanding 
the topic. 
   

If we lost dynamic throws, trying to make it work *as* a dynamic 
system is not pragmatic and AFAIK prone to many strange problems, 
especially if we try to create our own code patterns and would need 
to decipher cryptic mezzanine code which does some magic.


the way I see it, definitional throw/catch really doesn't scale well 
and doesn't work especially well in collaborative programming if 
there are multiple trap points with different catch setups.


I can see ways this can be a problem, especiallly when code IS NOT 
bound on purpose like in liquid which uses a class-based model, *specifically* 
because it allows me to scale a system by at least three orders of 
magnitude. 


liquid builds nodes on the fly and generally re-organizes processing 
on the fly.  one system might be building the setup, while another, 
later will execute it.  with definitional throw, this is impossible 
to make work.

Definitional * has one advantage over dynamic: You can see it in 
the source. When the program runs the scope is actually dynamic, 
but you have to use your imagination or a debugger to see it.

Not only one advantage, but that is the most significant advantage 
for most programmers.

Brian wrote: "BREAK also applies to PARSE, which relies on dynamic 
scope (and yes, I can point you to mathematical proofs of this, though 
there's no point)" - I *must* correct this! Parse break is:

- neither dynamic
- nor definitional

it is a third kind:

parse break is lexical

Here is why:


1) It is stated in the documentation, that "parse break is a keyword", 
i.e. it it lexically defined to be a keyword of the dialect

2) it is stated in the documentation, that it "breaks out from the 
nearest loop", which is true, but it the lexical sense again

So very novice question - parse [break] is not the same as parse 
[(break)] internally? :-)

Sorry, I meant PARSE [(break)]. BREAK in parens is completely different 
than BREAK in the rules :)

So the correction was not to the statement that I made, it was to 
which BREAK I was referring.

Nonetheless, for PARSE's BREAK operation, "breaks out from the nearest 
loop" means in dynamic scope, not lexical.

Any case you find?

(you cannot)

parse is keyword-based

Yes, but lexical scope has nothing to do with lexical keywords.

AFAICT its not lexical since it will properly return to any rule 
which uses a referenced sub rule via a world as well as a sub-block

Not to mention, that (break) is not a parse construct, it is actually 
foreign to parse

No example what so ever are you able to find

Any non-lexical behaviour?

Except (break) and (break/return) were explicitly added to what PARSE 
supports. It was one of the better Parse Proposals, and it was accepted 
and implemented.

Lexical scope means nested blocks. The blocks don't have to be nested, 
as Maxim said.

The argument, that for parse (break) has to be dynamic does not hold 
any water. Why?

As already mentioned, it is foreign to parse

Blocks don't have to be nested

 - does it make any sense to you? It surely does not make any sense 
 to me.

Maybe you missed it, but there are better arguments against dynamic 
break. PARSE [(break)] is minor in comparison to the other problems.

Blocks don't have to be nested
  a: [] b: [a]
Not nested, dynamic scope.

I do understand that "blocks don't have to be nested", but that does 
not relate to the fact, that break in parse behaves lexically

(and make no mistake, I mean the parse keyword, not the foreign (break) 
construct)

The BREAK keyword does not break out of the nearest loop lexically, 
it breaks out of the nearest in the (PARSE equivalent of the) call 
chain. It is dynamic in scope, which can easily be demonstrated with 
ANY, SOME or WHILE with a named rule with a BREAK in it, instead 
of an inline block.

{very novice question - parse [break] is not the same as parse [(break)] 
internally?} - correct, they are two completely unrelated constructs, 
the latter being "foreing" to parse, related to the do dialect, in 
fact

If you call a rule through a name, you are using dynamic scope. If 
the rule is inline then it is lexical scope.

Are you suggesting, that you cannot name things in lexically scoped 
constructs?

I simply don't understand, how it relates to the subject

You can not refer to structures by name in lexically scoped constructs, 
when those names are resolved at runtime. Well, you can, but then 
that becomes a dynamically scoped flow construct.
For instance:
a: [break]
b: [while a]


The word 'a is in the lexical scope of b, but the contents of a are 
in its dynamic scope only if b is used as a parse rule at runtime 
and a is still assigned that value. So even though the break is a 
keyword, the scope to which it breaks is the while, which is in b.

... I know that Ladislav's DO-ALL is a loop, and so not wanting BREAK 
to apply to it is more of an opinion than something inherent in its 
nature.

 - I was afraid, that the DO-ALL was not a fortunate choice! My original 
 problem with the property illustrated by DO-ALL occurred when I Implemented 
 my PIF (now called CASE for the newcomers), which was not meant to 
 catch any breaks, as is immediately obvious.

Yup. Hence the "we need this" comment (paraphrased).

It was just a caveat, not a criticism.

I wanted to invent as a simple example as possible, but I oversimplified, 
obtaining something, that may not be easily justifiable

It's cool. Your point was made, and the disadvantages of definitional 
break that you hadn't gotten around to adding to the page yet are 
stated above in that big message.

Btw, have you seen the source that would be used to implement definitional 
return? It would help to know whether they were catchable for debug/test 
purposes.

Debug/test needs a standard way to catch everything, but afaict there 
is no way to do so with definitional return. The same would go for 
the others if they were definitional, but that is less likely for 
the reasons given above. We might just have to live with not being 
able to catch definitional return - it should be easy to control 
the test environment so its return functions don't propagate into 
the test code, so that probably won't be a problem, at least for 
returns.

Loops are also defined lexically,

 - yes, as far as loops with variables are considered, the loop variables 
 are definitional, not dynamic

For variable-less loops the situation is different: not using "private 
variables" they are neither definitional nor dynamic

Yup. But I was mostly referring to the standard way the loop functions 
are used. Most loops are mostly made up of nested blocks and such, 
with very little direct DO calls to other blocks by name.

DO (or IF, or ALL, ...) of a block by name tends to only show up 
in advanced code. That code tends to be critical, and we usually 
can't afford to make it non-working, but not many people do that 
level of hand-optimization of their code, mostly because their code 
isn't that speed or size critical, or they don't know how (or they 
don't like that technique). On the other hand, PARSE rules called 
from loops are often referred to by name and are moved physically 
outside of the loops that call them for really good reasons, some 
of which I mentioned above.