World: r3wp
[!REBOL3 Proposals] For discussion of feature proposals
older newer | first last |
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 |
older newer | first last |