Okay, well this has continued to stick in my head, because the problems of these nouns being verbs are very pervasive. It forces you to be obscure (e.g. the comb: combinator [..] [..])
I would much prefer the freedom to call a variable combinator.
If we go with NEW and agree to drop the need for the exclamation point, then NEW OBJECT is nicer to look at than MAKE OBJECT!, so it's already an improvement right off the bat.
I don't think having to type NEW MODULE is a burden for the times you say that.
We could say that FUNC is a shortcut for NEW FUNCTION...though this would not generalize well to OBJ as a shortcut for NEW OBJECT, because OBJ is too frequently used as a variable name. Once you start thinking of it that way it makes FUNC feel like it should also be a shorthand for function instance.
So maybe new func [...] [...] ? new obj [...] ? The savings on MAKE OBJECT! might balance out the extra typing of NEW on FUNC. :-/
But this would suggest that deriving would be done with something else, like extend obj-variable [...] ... which is probably a good idea anyway.
This would lead to people being able to say:
function: new function [...] [...]
...if they wanted to. (Though more likely it would be the name of some argument or local of an arbitrary function passed from elsewhere... if you know what a function does because you're the one declaring it with instance data, you probably would name it something other than "function")
I guess that would allow us to revisit the question of whether we call these things ACTION! or FUNCTION!. I guess it depends on if we have some other idea for what an action would be?
action: new action [...] [...]
I've really found myself pretty much at ease with the likes of
type: type of value. It seemed weird at first but now completely normal.
(Sidenote: It's actually not bad to have names for entities inside the system that are different from the value names. e.g. having
String* pointers as the name of the stored data with no index, and then TEXT! values with the index being cells. So if we renamed the external type FUNCTION! I would keep
Action* as the internal name for the non-cell entity. This could also be a nice distinction between
Binary* and BLOB!. I don't have a good idea for how to distinguish
FRAME! though when they compete for variables named
frame. It's a stack level, so
How Would HELP Work?
HELP already needs to be smarter, when given a doorway to a larger universe. HELP PARSE just telling you it takes a BLOCK! of rules isn't very illuminating.
So might HELP NEW be able to give you a table of the registered new-handlers? Could you then say:
>> help new object
...and get something meaningful?
The Pattern Isn't Stopping...
We're going to be facing this same thing again with GENERATOR and YIELDER. Every time this comes up it bothers me and I find myself writing displeasing code.
People will of course be able to define things however they want, but I feel like taking a stance against verbing of nouns is likely necessary.
I'll Repeat Myself that Hiding the NEW Is Didactically Bad
For better or worse, the highly dynamic model of the language is such that you really are making a new function every time you cross a FUNC today.
Rebol [Type: module ...]
my-inefficient-2x-sum: func [x y] [ ; created once when module is made
let summer: func  [x + y] ; created each time my-inefficient-2x-sum called
return summer + summer
Other languages can do some form of static analysis and design closures more efficiently. But so long as we would just as easily let you put a COMPOSE there that was fully different, we can't do that...and need a new function identity each time.
(Ren-C and its immutability properties has some wiggle room in making it more efficient than historically the case, if it notices you are truly using the exact same block...but with MUTABLE allowing you to hack on block identities that gets in the way)
So the new helps you cognizant of the true cost--that you really are making a new function every time you cross that line.
Does this mean that DOES would have to be NEW DOES? Or we need to rename
new-> ? Er, probably not. But I'm saying that when it fits, the NEW doesn't hurt to know about.