World: r3wp

>> 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

And, in my opinion, this actually *is* a gotcha for beginners

Since HELP tells us what the VALUE? function is supposed to do, which 
just does not look like being the case above

Reading the HELP string of the VALUE? function, I do not know, how 
I can reasonably expect F to yield #[true]

(which does not mean I don't respect Max's feelings on this)

The funny thing is, that the COLLECT-WORDS/IGNORE looks like being 
Tutorial's strategy when communicating with me ;-)

/local x  sets the value of x to none in the F above.
if F was defined like so instead (R2)

>> f: make function! [/local x [any-type!]][[x:] value? 'x]


then you can call it with with unspecified /local arguments and it 
will yield #[false]

>> f/local
== false

things is funct doesn't add that [any-type!] in its param block.

(for locals)

so yes... the value?  help string makes sense... its defined as a 
local within the function, as 'FUNCT is supposed to do automatically.

defined as a local

 - yes, that is true, but in my example below, 'x is clearly defined 
 as "nonlocal", yet the function yields #[false], in accordance with 
 its help string:

>> g: func [] [[x:] value? 'x]
>> g
== false

A little note about FUNCT vs. FUNCTOR: The word "functor" has a specific 
meaning in computer science, and that meaning is *not* what FUNCT 
does. There is no standard CS term for what FUNCT does, nor is there 
a standard English term. Any word we use would therefore have to 
be made up. FUNCT is not a bad made-up word: it's short, which is 
good for a function that will be used often in user code, and it 
starts with the same letters as FUNC and FUNCTION without being either 
one of those words.

I'd rather we use PROC then.

I strongly agree with Brian regarding the unsuitability of FUNCTOR.

Yes, I do agree too

actually Lad, if a word is defined but stores a value of unset!  
(like what happens above with the [x:]  value? returns false.

Some counterexamples where we messed this up:

- "functions" have side effects so they aren't really functions, 
they are procedures with return values.

- "closures" aren't really closures, though they are closer to that 
than REBOL "functions" are.
- "contexts" aren't contextual
The list goes on.

cause x actually has not ever been set.

so if I get you right,  in REBOL: 

contexts are actually closures, 
functs are actually functions 
and funcs are actually procedures

;-)

We actually had a function called FUNCTOR for a while, and it really 
created functors. And it went unused for more than a year, so we 
dropped it. It turned out that what FUNCT does is really useful, 
even though the concept is unique to REBOL. Apparently functors aren't.

Brian, agreed, but e.g. "functions" are somewhat "standard" (C, ...)

FUNCTs and FUNCs are both procedure builders. Neither create functions. 
It's a common naming mistake in imperative languages.

Including C and the Pascal it was based on.

but really, I would rather we use the term proc instead of funct

Then it isn't like FUNC, and people are more likely to misunderstand 
the difference. It really is a unique concept, certainly nothing 
like the proc concept in other languages that have that term.

I think proc would make things even worse. Nothing would indicate 
that FUNC and PROC are basically the same, except for a minor (but 
important difference). And choosing which does which is absolutely 
arbitrary.

agree with Andreas

I actually preferred Ladislav's old LFUNC naming; but FUNCT is fine 
as well. There simply is no easy way to name this.

I'd probably stop using func most of the time, and I can't see myself 
typing funct  20 times a day.


everytime I write it, I feel like I'm writing a less savory femal 
genital word in a strange dialect of german ;-)

Yes. I think the only real choice we have is what behaviour we want 
to label with FUNC, which is probably the most prominent name among 
our options.

Maxim, nothing in REBOL corresponds to a closure, though the closure! 
type is closer than other function types, and many other languages 
call something similar to that a closure too. We don't have contexts 
(though "dialects" are close). Neither FUNC nor FUNCT build real 
functions, but they both build what other imperative languages incorrectly 
call functions, so people won't get confused.

The value of funct over lfunct is that it sorts in proximity alphabetically

yes, that is why I think it is quite reasonable

lfunct = Lfunc

Which is also its most prominent shortcoming, as readers pattern-match 
better at the beginning of a word then at the end.

So LFUNC is visually more different to FUNC then FUNCT is.

than*

depends on whether you want to stress the similarities or differences

I also prefer LFUNC the L actually has meaning in that word.  the 
mind unwraps the L to "Local" automatically.   while FUNCT really 
is obscure everytime you read it.

I have two reasons why I like keeping FUNC the way it is:

- FUNC is the simplest function-creating function, so giving it the 
shortest name seems appropriate.

- As a rule, we prefer to not rename old functions and then give 
their old names to new functions. That would be user-hostile.

I agree, func is the basis of just about every script out there.

But never forget bug#666.

FUNCT doesn't just gather locals ("lfunc"), it also optionally binds 
the function body to an object ("friend-func" to adapt the C++ term.

Andreas, I also don't forget bug#667.