>> a: context [b: 1 print b context [b: 3 print b] print b]
1
3
1
collect
and get rid of local block:>> range: func [num][collect [repeat i num [keep i]]]
== func [num][collect [repeat i num [keep i]]]
>> range 5
== [1 2 3 4 5]
@9214 @greggirwin
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 w
.
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.
@nedzadarek
Why do you think I'm using function by default?
Because you're naive enough to think that it can cover all cases properly, and take care of set
and copy
in Parse.
it's just they are less suited to more complex code.
Maybe the problem is in your code then? As you yourself so boldy affirmed: but It starts to depart from the Rebol's motto "Rebol against complexity"
Let's dissect your examples.
Straw man fallacy. Do you understand how ridiculous it is to "dissect" one-liners written for demonstrative purpose? They show an idea, not an implementation.
What if you have 10 or 20 words that have more than 4 characters in it?
Then you probably should reconsider your design approach.
whenever or not someone are changing some core functionality of the parse. It makes code less readable.
I have a hard time trying to follow this argument. Purpose of bind
is evident here, and you can change "core functionality of Parse" from Red, because it's a parsing engine written in R/S.
Yes, it's that easy.
If you try to discredit me, at least do so properly:
>> f: function [][
[ callback: func [event match? rule input stack][
[ also yes if all [match? find [set copy] first rule][
[ 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
[ ]
== func [/local callback words][
callback: func [event match? rule input stack] [also yes if all [match? find [set copy] first rule] [append words...
>> reduce [:a :b :c]
== [unset unset unset]
>> set [a b c][1 2 3]
== [1 2 3]
>> f
[a b c]
>> reduce [:a :b :c]
== [unset unset unset]
Above works as expected, contrary to your claim.
If you are going to say
Oh, no, I'm not going to say anything. Seeing how you don't have anything constructive (or original) to add to this discussion, I'm rather disinterested in continuing it. Arguing for the sake of arguing is solely your prerogative.
@9214
Because you're naive enough to think that it can cover all cases properly, and take care of set and copy in Parse.
No, read the next sentence...
Straw man fallacy. Do you understand how ridiculous it is to "dissect" one-liners written for demonstrative purpose?
I'm sorry. I should have used different word. I guess "examine" should be better.
Then you probably should reconsider your design approach.
https://github.com/red/red/blob/master/runtime/allocator.reds#L466
Purpose of bind is evident here,
Yes, it's easy to understand. You know why? Because it's just one line. When you write more line you will start to understand this.
and you can change "core functionality of Parse" from Red, because it's a parsing engine written in R/S.
Not sure why mentioned R/S but I agree, I can change (at least some part) parse
.
If you try to discredit me, at least do so properly:
Above works as expected, contrary to your claim.
So, do you expect to destroy some words from some other context? Well, I'm not sure why you corrected it. I'm really confused about this code. We were talking about "local words in the function" (how to make it local) and your function changes/delete those words (and it shouldn't do this)
Oh, no, I'm not going to say anything. Seeing how you don't have anything constructive (or original) to add to this discussion, I'm rather disinterested in continuing it. Arguing for the sake of arguing is solely your prerogative.
I'm sorry. I believe in my arguments but I cannot explain it clearly to you. It might be my knowledge (language and/or programming).
I respect you for your knowledge and willing to help others so I, as you said, I don't want to waste your and mine time.
I'm fine If you don't want to answer to this post.
@rebolek I ask again, because I had no answer to this gitter question:
In RED Blog I have read :
Still some features are not yet implemented:
It's not implemented, yes.
Do you mean "yes, you can't build a function at runtime, this affirmation is valid " ?
Jeez... you link a 7 year old blog post about Red compiler and ask if it's possible to create function's at runtime in compiled code - the answer is no, because that would require just-in-time compilation, and current compiler is ahead-of-time one. In general, current compiler cannot support dynamic code.
You can build functions at runtime in interpreter though, that's what func
, function
and other function constructors do all the time.