Yes @moliad but first/second/third or obj/1 ../2 /3 is a method you could apply to object content. In fact in rebol you could use it on the third element of an object. (i.e.: probe first third obj)
The key distinction here is intended use. Maps and objects are based on unorderd key-value slots, blocks are based on ordered slots. This is an important distinction. While this is not laid out in a design spec, it tells you that it is safe to use blocks based on their order, but that it's not safe to do so with maps and objects. That is, a block will always return values in the same order, but a different implementation of map/object might change the internal order of things, and return them in a different order in response to words-of/values-of.
foreach, as @nedzadarek showed, it is special, along with
repeat, If you use
function rather than
_function/collect-deep are responsible for that special handling.
This is a workaround for now, but a fairly effective one in most cases. Not perfect, but better than nothing.
_functionis the context name in the
set-word!local (adds it to the
f: function [a: 1] ; == func [/local a][a: 1])
foo: 42) won't make a word local (
f: function  [set 'a 1] ; == func [set 'a 1]<-
functioncollect that word (wrong - to be more precise) ->
f: function  [foreach w [1 2 3][ print w]] ;== func [/local w][foreach w [1 2 3] [print w]]
_function/collect-deepfrom within Red (console? compiled?)
setworks the way it does by design. It allows you to externalize a word without having to use
/extern, so it will not change. And you really don't want to mod things in the bowels of the langauge, even if you can, because that will create all sorts of problems when sharing code and staying compatible with language changes.
It allows you to externalize a word without having to use /extern
set (or other "functions") in the
f: function  [parse [a] [set z word!] z] z; a)? It wasn't my intention to externalize a word by using
Could you change that kind of functions (or introduce others) in the
parse to be "local"?
No idea what "create some words" means. Parse doesn't create them in any way,
but have I specifically chosen that function so it behaves this way? Yes.
Fixed it for you. There's plenty of functionality to make it work the way you want, but you seem to ignore all of it so as to strengthen your argument.
>> f: func [/local z][parse [a][set z skip]] :. >> f: does [parse [a] bind [set z skip] context [z: none]] :.
You can even intercept
copy within callback function and aggregate their arguments for further post-processing.
callback: func [event match? rule input stack][ also yes if all [match? find [set copy] rule/1][ append words rule/2 ] ] probe unique also words:  parse/trace [a b c][ ahead [copy a [3 word!]] ahead [set b skip] copy c [2 skip] set d to end ] :callback unset words
copy can support paths the way Rebol does, but that will cause a slight decline in perfomance. red/red#3528
What was it with your "no choice" once again..?
(...)for arguments. It works in your case, because your function has just one argument and parenthesis evaluate all values and return last. So
(3)in your case becomes
3. But if you'll have function with more than one arg, it won't work.
>> a: context [b: 1 print b context [b: 3 print b] print b] 1 3 1
collectand get rid of local block:
>> range: func [ ]]] == func [ ][ ]]] >> range 5 == [1 2 3 4 5]
create some words
When you use
parse you can set words to some value, for example in
parse [a] [set w word!],
parse creates word
Fixed it for you.
No. You are wrong.
There's plenty of functionality to make it work the way you want, but you seem to ignore all of it so as to strengthen your argument.
Why do you think I'm using
function by default? It's the closest to a "I don't care, just don't mess global space - make everything local" attitude. I'm not ignoring anything - it's just they are less suited to more complex code. Let's dissect your examples.
f: func [/local z][parse [a][set z skip]]
You have only one local word
z. What if you have 10 or 20 words that have more than 4 characters in it? For example:
f: func [ /local abakus abrakadabra ... ][..]
You are making code longer (harder to understand, even it's by "a little).
f: does [parse [a] bind [set z skip] context [z: none]]
You find this in someone's code. What's the purpose of the
bind here? You have to go to the
context to see whenever or not someone are changing some core functionality of the
parse. It makes code less readable.
You can even intercept set and copy within callback function and aggregate their arguments for further post-processing.
>> f: function  [ [ probe unique also words:  parse/trace [a b c][ [ ahead [copy a [3 word!]] [ ahead [set b skip] [ copy c [2 skip] [ set d to end [ ] :callback [ unset words [ ] == func [/local words][ probe unique also words:  parse/trace [a b c] [ahead [co... >> a *** Script Error: a has no value *** Where: catch *** Stack: >> a: 42 == 42 >> f  >> a == [a b c]
Yes, it's that easy.
What was it with your "no choice" once again..?
If you are going to say I have choice because the language is (is it?) turing complete then you should check what is the Turring tarpit. Is it the turring tarpit? I guess no... but It starts to depart from the Rebol's motto "Rebol against complexity". Especially your binding code.