World: r3wp
[Core] Discuss core issues
older newer | first last |
Fork 1-Apr-2008 [9838] | I do remember that, though I don't exactly remember what happens if you don't do it |
Anton 1-Apr-2008 [9839] | It sets 'ret global. Check this by running the script then probe ret in the console. |
Fork 1-Apr-2008 [9840x4] | Ah, ok |
So same for test-block | |
(start/end) | |
And pretty much everything else... I'll go over it. I should probably use "function" as I don't care so much for /local | |
Anton 1-Apr-2008 [9844] | Yes, but that's just your test code. Usually I don't bother being so strict with test code because I know I'm going to throw away the console afterwards. The reusable library part is the important part to be watertight. |
Fork 1-Apr-2008 [9845] | I get the feeling that I'm going to want to have an analysis tool which will read through the functions, find any variable: assignments, and ensure they're in the local list unless there's some sort of indication they should be global. Because it seems relatively uncommon that I would, inside a function, set things in the global space. I'd be happy to use something wordier (set?) for that |
Anton 1-Apr-2008 [9846] | I recommend FUNC over FUNCTION because having "/local" written makes it clearer and explicit what the locals are, and is shorter when there are no locals. Compare: When there are no locals, func wins, because less characters to type. func [] function [][] When there are locals, same number of characters written, but func more clearly specifies the locals. func [/local] function [][] Additionally, when you are modifying your func spec back and forth so that there is a need, or no longer a need, for locals, then func wins by less typing needed. |
Fork 1-Apr-2008 [9847x4] | Hm, well, it's not a tremendous deal but I feel like always being forced to remember typing in that second group would remind me that I need to think about what goes in it |
Is there a way to set things locally in a do block? | |
Or do you have to do a nameless function to get a local context? | |
e.g. do func[/local v] [v: 1+2] | |
Anton 1-Apr-2008 [9851x2] | I go without such a tool for analysing function local variable consistency, which, I think, turns out to be a difficult problem to solve. Some people have written alternative function creators which somehow make set-words into locals by default (Ladislav ? with his lfunc ?) or something like that. I just maintain a strict habit of checking for accidental globals. It's good to review your use of variables regularly anyway, and be aware of what context they're bound to. |
use [v][v: 1 + 2] | |
Fork 1-Apr-2008 [9853] | Ah, an lfunc, that sounds nice |
Anton 1-Apr-2008 [9854x3] | do [ use [v][v: 1 + 2] ] |
context [ v: 1 + 2 print v ] | |
same as make object! [ v: 1 + 2 print v ] | |
Fork 1-Apr-2008 [9857] | I see... context looks like a good thing, great! |
Anton 1-Apr-2008 [9858x2] | Yes, very useful. |
?? context | |
Fork 1-Apr-2008 [9860] | When I do something like a for loop and I specify a name for the loop variable, is that defined globally by default or locally? |
Anton 1-Apr-2008 [9861x4] | which reminds me; make-enum-type can be optimized like so: make-enum-type: func [ possibilities [block!] ] [ make enum! [ p: to-hash possibilities l: length? possibilities ] ] |
so no need for a local at all. | |
Loop functions set words local, in a temporary context. You can test whether loop functions set words global or not quite easily: | |
>> for i 1 10 1 [] >> i ** Script Error: i has no value ** Near: iĀ | |
Fork 1-Apr-2008 [9865] | Yes, thanks for reminding me of the at-hand-interpret-as-you-type thing :) |
Anton 1-Apr-2008 [9866] | All I can say is, enjoy... |
Fork 1-Apr-2008 [9867] | Is there a way to get the native-switch that is better than how I've done it? |
Anton 1-Apr-2008 [9868x3] | (But I was thinking, the above doesn't prove that i is not set global during the loop, then unset at the end, but you wouldn't expect that sort of sneaky behaviour...:) |
Yes, you've set 'native-switch global. It appears to be used only in the enum/switch function. | |
You could simply refer to system/words/switch instead. No extra variable necessary here. | |
Fork 1-Apr-2008 [9871x2] | A-ha... nice. Now here's something... can I make it so that my test-block runs the code in its body in a local context? |
I guess, use [][do :block] ? | |
Anton 1-Apr-2008 [9873x4] | No, that use would be no different than just do :block |
Because, by not specifying any use locals, you are making a context without any local words in it. | |
(ah... except 'self, but that's not important here) | |
Better than loop times [do :block] is loop times block | |
Fork 1-Apr-2008 [9877x2] | Now that one I got from a sample on the web. :) http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=timeblk.r |
Which also didn't declare start: locally... | |
Anton 1-Apr-2008 [9879] | The words in block maintain their bindings. This is what you want; the words retain the meanings from the context the user wrote them in. (ie. your locals do not affect those words because nowhere do you bind the words to any of your own contexts.) |
Fork 1-Apr-2008 [9880] | do context[do :block] ... that would give it a new context and run it there. What kind of thing would that break? |
Anton 1-Apr-2008 [9881] | So if I write test-block "section" [ print reps ] then REPS means what *I* (the user of the test-block function) thinks it means, not what test-block thinks in its little context. |
Fork 1-Apr-2008 [9882] | Hmmm. Ok, so if I want to have local variables in a test-block the context declaration would need to live there? That is different? |
Anton 1-Apr-2008 [9883] | (First DO does nothing extra, just returns the object) Again, context [do :block] is no more (except 'self) than: do :block |
Fork 1-Apr-2008 [9884] | I did try that but it didn't seem to evaluate the block |
Anton 1-Apr-2008 [9885] | You could do something like this: use [var1 var2] block or context join [var1: 100 var2: 200] block |
Fork 1-Apr-2008 [9886] | Now it's evaluating, hm. Wonder what I did before. |
Anton 1-Apr-2008 [9887] | There're lots of confusions here when starting out :) beware ! |
older newer | first last |