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

World: r3wp

[Core] Discuss core issues

Fork
1-Apr-2008
[9827x4]
So it was getting a CGI variable in an HTTP post
Then it did switch/default nextstep [ (various cases, pages long) 
] [ the default case ]
A bug in the cgi system left a trailing newline on the nextstep variable
SO instead of being "apache1" it was "apache1^"
Anton
1-Apr-2008
[9831x3]
Ok, so you saw the enum object as an extra level of protection against 
this kind of bug.
To more strictly validate input.
Or was it just to catch where the bug was ?
Fork
1-Apr-2008
[9834x2]
It validates on all sides, it protects against programmer error in 
the usage as well as things like this where the data source or function 
has a problem.
I do like REBOL from what I've seen so far!  But I saw somewhere 
that it was being compared to modeling clay... it's a paradigm shift 
for people who are used to systems that do a lot of global analysis 
of your program before it runs the first line of code to catch basic 
errors.
Anton
1-Apr-2008
[9836x2]
Yes, definitely.
make-enum-type should define 'ret local.
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