r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Proposals] For discussion of feature proposals

Ladislav
11-Nov-2010
[190x2]
catch doesn't handle throw/name

 - you could always use catch/name [...] 'none versus throw/name 'none, 
 if you did not want to catch other throw/name calls, so this is still 
 just "cosmetic", and surely not serious in any sense I can imagine.
For an even more interesting thing - a definitional catch/throw pair 
(which can be ported to R2) see the Exception_proposals article. 
Advantage: you do not have to use any name, yet, only the right throw 
is caught.
Maxim
11-Nov-2010
[192]
yes that is interesting, but /name is usefull for some code patterns 
like named exceptions.


thing is that currently, catch  withouth /name does make that impossible 
afaik.  if we built a mezz which re-threw them, afaik, that would 
change the context and thus make context sensing impossible... though 
your skill in this type of low-level manipulations might (will? ;) 
prove me wrong.
Ladislav
11-Nov-2010
[193x2]
:-'
Named exceptions are child's play for definitional catch/throw
Maxim
11-Nov-2010
[195]
ok, what would be the advantage of using a dynamic catch/throw, if 
any?
Ladislav
11-Nov-2010
[196x2]
it is already available, that is about all
but, sure, you may get a different answer if you ask some fans of 
dynamic constructs
Maxim
11-Nov-2010
[198]
ok, so its just less complicated to build mezz code with dynamic 
returns, but that means dropping a few possibilities with definitional 
ones?
Ladislav
11-Nov-2010
[199x2]
its just less complicated to build mezz code with dynamic returns 
- who told you that?
the opposite is true
Maxim
11-Nov-2010
[201x3]
its just my bumbling appraisal so far, because it seems to me that 
you don't need to redefine and contextualize everything within your 
mezz code... but I do say I'm novice at this subject.  (I'm trying 
hard to completely "get" it/
ok, so its easier cause its managed by the core, but that means you 
can't play around with it within the mezz... is that a better appraisal?
hence, "harder" to adapt, but "easier" out-of-the-box?
Ladislav
11-Nov-2010
[204x6]
Compare this:


dynamic: func [block i] [append block 'i if i > 0 [dynamic block 
i - 1] block]


definitional: closure [block i] [append block 'i if i > 0 [definitional 
block i - 1] block]

probe dynamic [] 3

probe definitional [] 3
Which one is harder?
At the first sight, none is, I bet, but at the second one:

probe reduce dynamic [] 3

probe reduce definitional [] 3
The answer is different
So, which one is harder?
Btw, for DYNAMIC you will get different answers depending on whether 
you are running it in R2 or in R3
Maxim
11-Nov-2010
[210]
R3 
>> probe reduce dynamic [] 3
** Script error: i word is not bound to a context
** Where: reduce
** Near: reduce dynamic [i i i i] 3

>> probe reduce definitional [] 3
[3 2 1 0]
== [3 2 1 0]
Ladislav
11-Nov-2010
[211]
So, any favourite?
Maxim
11-Nov-2010
[212x2]
I'm trying to understand what's going on in R3...
(in the dynamic version)
Ladislav
11-Nov-2010
[214x4]
I could show you a similar example with CATCH/THROW, but it would 
require more code
Dynamic variables in R3: they are "not bound to a context" when the 
function is not running.
(that formulation is a bit unfortunate, meaning, that I would not 
have used it, but, in essence, it means: "don't ask what the value 
of dynamic variable is, when the function is not running")
Nevertheless, you can insert something like


if i = 0 [print mold block] to see the result, and compare that to 
the result in R2
Maxim
11-Nov-2010
[218x2]
wow, I think you've just illustrated a big part of the issue and 
you should add the above to your exceptions page.
it does a better job at explaining the underlying issue than the 
R3 error page IMHO.
Ladislav
11-Nov-2010
[220]
The thing just illustrated were "dynamic variables versus definitional 
variables"
Maxim
11-Nov-2010
[221]
yes, but the error document tries to illustrate it too, and I didn''t 
see it as plainly as I do now.
Ladislav
11-Nov-2010
[222]
need to check that
Maxim
11-Nov-2010
[223]
I find that the above is a good intruction which makes the  "Exception 
Marker Scoping"  more understandable in detail.


its not exactly the same, since the error document talks about unwinds, 
but I feel that the above helps me understand *why* the unwind does 
what it does.
BrianH
11-Nov-2010
[224x2]
I really need to fill in the Exceptions page with the real differences 
and advantages of dynamic and definitional scoping. There are advantages 
that either has that the other does not. It would be a real loss 
to not have both in different circumstances. The different circumstances 
being definitional for returns and dynamic for breaks and throws.
And anyone who thinks definitional is always better needs to look 
at #1521.
Maxim
11-Nov-2010
[226]
with the above example, I'm thinking about the past discussions and 
they are starting to make sense in a new light  :-)
BrianH
11-Nov-2010
[227]
I have discussed a new page organization strategy for the Exceptions 
page with Ladislav. As time permits, I will try to reorganize. It 
will make these issues much more clear.
Ladislav
11-Nov-2010
[228]
Max, the errors page you mentioned tried to illustrate the difference 
between dynamic and definitional return, which looks more subtle, 
than the difference between dynamic and definitional variables...
BrianH
11-Nov-2010
[229x2]
its just less complicated to build mezz code with dynamic returns

 - Depends on the code. Some obscure but important things are impossible 
 if you have dynamic returns. Some less-obscure things aren't even 
 defined as a concept if your returns are definitional..
The reason we can get rid of dynamic returns in R3 is because the 
critical stuff that we used to do with dynamic returns in R2 is *necessarily* 
handled by dynamic breaks in R3, so dynamic returns are no big loss.
Ladislav
11-Nov-2010
[231]
A description of the difference between the definitional and dynamic 
return:


*the dynamic return returns to the dynamically closest function (i.e. 
to the function that was called as the last one)

*the definitional return returns to the definitionally closest function 
(i.e. to the function that was defined as the last one and contained 
the return in question)
BrianH
11-Nov-2010
[232]
That's not all. Definitional also requires the affected functions 
to have (and in some cases fake) lexical scope. For R3 this means 
nested blocks.
Maxim
11-Nov-2010
[233]
lad,  what I mean is that the illustration of the variable issues 
above helps us realize that there even *is* a dynamic vs definitional 
distinction. 
it then allows us to more fully understand the return issues. 


you might be surprised that I never even realized there where dynamic 
variables, in the way you present it above.  Even if I've grown to 
understand binding pretty deeply.
Ladislav
11-Nov-2010
[234]
aha, OK
Maxim
11-Nov-2010
[235]
in a sense... you can say that I might even begin to understand your 
guru code now  ;-)
Ladislav
11-Nov-2010
[236]
that is you who should say that ;-)
Maxim
11-Nov-2010
[237]
hehe
BrianH
11-Nov-2010
[238]
Fortunately, functions are built with nested blocks, though that 
is partly enhanced in R3 by tasking issues. And while loops are also 
build with nested blocks, 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), so we still need dynamic BREAK. 
Dynamic THROW is just a good idea because of all the capabilities 
that would give us.
Ladislav
11-Nov-2010
[239]
but, nevertheless, there isn't any reasonable defnition of dynamic 
versus definitional concepts in the article, so I take that as a 
hint