World: r3wp

Depending on how you are presented with something, the "unlearning" 
can be either a joy or a suffering.  Put a kid on a bicycle with 
no training wheels and they fall and get hurt and they might not 
appreciate bicycles very much.  Give them some training wheels and 
let them get comfortable and be happy the day it comes off.

yes, but its still a bicycle. start them of on a tricycle and none 
of what they learned there it is usefull.  on a tricycle, if you 
lean you fall. on a bike, if you don't lean you fall.

(to an extent, obviously)

Maybe this should move to advocacy.

yeah, I just realized we wheren't there... but this tangent is somewhat 
exhausted ;-)

we need 'FUNCTOR   ;-)

Since I was unable to get an answer to my question:


I want to ask you a question related to your refinement-arguments 

initialization" (actually, it is not initialization, but "unused 
refinement arguments", like the /local arguments are usually preferences 
(see the wording of my answers at http://stackoverflow.com/questions/3168226/how-value-function-really-works
)"


from RebolTutorial messing the thing up with a purported incompatibility 
between FUNCT and FUNC, I guess, that this is the place where the 
question would be at least understood. So, is there anybody actually 
preferring the "unused refinement arguments" to be unset, than to 
be set to #[none] at every function call?

oh, sorry for the above mess, it is totally unreadable, as it looks

THEY HAVE TO BE NONE!

so many coding patterns depend on it.

that is for 'FUNC.  


not shure what the difference is with FUNCT, but I'd prefer them 
to be none there too, though I'm not currently "schooled" as to the 
intricacies of 'FUNCT and what effects any change would have.

No difference with FUNCT, stop that

OK, I understand, that your preferences are to set these arguments 
to #[none]

so many coding patterns depend on it
 - is that a general sentiment here?

I have a counter question.  why would be set them to unset!  ?

Because they are, in fact, "undefined", which, by convention, is 
commonly expressed by having such variables unset in other cases

Even in functions, undefined arguments are in other cases unset, 
not set to #[none]

(I guess, that you know examples for that)

in R2 everything is set to none, not sure about R3.

though I (and many others) often use none, to indicate the use of 
a default or fallback value.

R2 example (you surprised me not knowing it):

>> f: func [x [any-type!]] [value? 'x]
>> f
== false

ah, but here you actually supplied unset to the function.

in a way, its not the same as not specifying the /refinement.

but yes, the line is thin.

>> g: func [/local x [any-type!]] [value? 'x]
>> g
== true
>> g/local
== false

(R2 example too)

but the use of  any-type! is what specifically allows this "trick".

R3 removed the ability to not supply arguments...

>> a: func [x [any-type!]][value? 'x]
>> a
** Script error: a is missing its x argument

IIRC this was the great "equalizer" when make was overhauled... it 
now always accepts exactly one argument, because it is forced to.

R2's behavior has always worked well for me. Unset is the special 
case I avoid unless I really, REALLY think there's a need to leverage 
it. I very rarely use any-type! for that reason. I like declared 
locals being NONE. I can't think of a time I tripped over using a 
refinement without passing its arg, but there unset would have to 
be intentionally expected as well.

>> b: func ['x [any-type!]][value? 'x]
>> b
== false

(R3)

Well, anyway, because of this, RebolTutorial completely ignoring 
any explanation makes a bad publicity to Rebol stating that "FUNCT 
and FUNC are incompatible", which is just nonsense.

ok, but that is a fringe case which probably got put there specifically 
to allow that specific pattern so that some command-line functions 
can be simplied... 
its not the intended use of Rebol.


argument passing by reference is rarely used (a few mezzanines and 
highly specialized situations)

Agreed. And things like the R3 behavior for a missing arg when using 
a lit-word! param versus a word! param would be good to note in the 
FUNC docs.

in the above cases, they should be unset, because in fact they are 
passed unset!

the 'x refers to no value

I think Ladislav dislikes lit-word params anyway, as they are a pain 
when generating code, but they make for good examples and thought 
experiments.

they are mainly used for command-lines and code analysis funcs (?? 
for example)

Explanation: the "partially evaluated arguments" as used in R3 are 
OK with me, I disliked their R2 counterparts.

OK. :-)

yes, I agree completely.  this is now an intended setup, not an interpreter 
loophole leveraged as a feature.

Lad, can you explain simply, what is the difference between func 
and funct which RebolTutorial claims?

I cannot, because there is none

ok

Example:

>> f: funct [] [[x:] value? 'x]
>> f
== true

but I meant what does HE claim is the difference?

RebolTutorial claims, that the behaviour of the above F differes 
from FUNC, which is just nonsense, since the SOURCE function tells 
us:

>> source f
f: make function! [[
    /local x
][[x:] value? 'x]]

I do not think it deserves any more comments

yeah, he doesn't seem to grasp that there is just one function! type 
 ;-)

and there is that nice little line in funct :   collect-words/deep/set/ignore

which pretty much explains it all  :-)

Nevertheless, the whole issue is related to his misunderstanding 
how the values of "unused refinement arguments" are set in functions