World: r3wp

And in lowercase it's too close to func while being very different...

I rarely agree with Fork  ;-)  on this one I TOTALLY agree.

Too close in uppercase too, actually.

Ah... so what's it like to finally feel some common sense?  :-)

Pretty soon this will become clear, too: http://hostilefork.com/2010/07/18/clocks-that-run-backwards/

I'd rather use something purposefully obscure like FCT.


if you're going to make a name shorter for the sheer reason of making 
it shorter... at least make it different.  


I would much prefer FUNCTOR.  its obscure, yes, but caries a sense 
of "find out what is the difference".  'FUNCT will go unnoticed for 
the majority of users.

I wouldn't mind if FUNCT was a shorthand for FUNCTOR.

Rebol doesn't make a habit in general of short names, and when it 
does I always wonder "why those".  Found some odd ones while working 
on Rebmu:

http://github.com/hostilefork/rebmu/blob/master/rebmu.r#L191

Carl says, he likes to use longer names, if the function is not meant 
to be used by end-users.

Fork, I won't say you're wrong on names, but you can't be right. 
:-) Naming is subjective, and there is no such thing as intuitive; 
unless you use natural language as the reference.

I like to feel like there's some matter of principle driving why 
the language doesn't define "app" for append or "rev" for reverse 
by default.  So yes, I'd use natural language as the reference in 
this case, but only because it seems like a convention which is *almost* 
followed but with these few exceptions that do not seem necessary.

REBOL is not about being as terse as possible. That's for Perl and 
Rebmu. I don't agree with all the designer's choices, but I can at 
least understand most of them. We all have things we don't like, 
and those things are different for each of us.

I feel like it's almost possible to teach people non-idiomatic Rebol 
and have it make sense from the get-go, where you can really focus 
on the code.  There are ways to keep from triggering "WTF" responses, 
like putting in parentheses when they're not strictly necessary. 
 And it seems so close that it's a shame the last little bit isn't 
done.

The catch is that "the last little bit" is not little at all. It's 
fundamental. I know you know that, but if we change REBOL to work 
like C and PHP people expect, that's what it will be.

experienced programmers have learnt to accept idioms like the requirement 
of parens on function calls.


they have to understand a different set of idioms.  "unlearning" 
that some of what they perceive as "fundamental" in programming is 
hard.


new programmers will have it the other way round if they learn REBOL 
first... why do we needs comas, and parens everywhere.... seems like 
waste.

where are refinements, things like that.

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