Drop current FUNCTION, make it a FUNCT synonym instead

[rebolbot]

Submitted by: BrianH

The current FUNCTION function is almost never used, and not really useful - it's just a version of FUNC with unnecessary overhead. The FUNCT function with its local word gathering is used much more often, especially in R3 code, about as often as FUNC.

However, as Fork likes to remind us several times a day for months on end, FUNCT is a bit of an ugly name, especially for so useful a function. In Red they agree, and have made their FUNCTION act like R3's FUNCT (or at least a subset without the options, I haven't checked recently) including its local words gathering.

We should considering doing the same in R3. Make FUNCTION a synonym for FUNCT, and drop its old useless behavior; keep FUNC, DOES and HAS as they are now. We'll likely want to keep FUNCT as well (though Fork would object) because of all the code that is written to use it, and because it got added to R2 with that name. If the FUNCT name doesn't get included in a minimalist R3 build, you won't get many objections.

Requested by several people in AltME and SO chat, but really often by Fork.

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Mezzanine Reproduce: Always Fixed-in:r3 master ]}

[rebolbot]

Submitted by: BrianH

This request may have been written in a humorous way, but it is a serious compatibility issue and a somewhat less serious marketing issue. There seems to be a bit of a community consensus building around not liking the name "funct", but liking what it does quite a bit. And no-one seriously uses the FUNCTION function anymore. Even the people who have admitted to using FUNCTION (like Ladislav) have also said that they wouldn't be sorry to see it go. People still seem to like FUNC though, or at least accept it in the aftermath of the #1625 discussion.

It is a good community relations idea to be somewhat compatible with Red in this issue. There is a large overlap between our communities, and we are working hard to make sure that the languages are compatible where compatibility makes sense. R3 has a big head start on the design discussions, but Red will occasionally implement a good idea that we haven't done first, and that makes sense for R3. I think that this is one of those occasions.

Red would still need to implement the options though if they want to get the full benefit of FUNCT (by whatever name). The local word gathering is nice, but the options are really useful.

[rebolbot]

Submitted by: fork

You mock me. I will not be mocked. http://www.hulu.com/watch/19312

But while I try to recover from the mockery, I will do a little dance because I'm happy this flag is getting picked up...finally. I don't know whether Red made the change because of me talking about this all the time, or just independent realization. Doesn't matter, it adds another reason to why it's a good idea, now more than ever.

And function as it is today, is weird:

   >> foo: function [/local x] [y] [x: 3 y: 4]
   ** Script error: duplicate variable specified: /local
   ** Where: make function...

If people want to make that kind of mess when they take Rebol out of the box, that's their business, but I don't think such a thing belongs in the box.

If this transition is done, it adds solidity to the argument that Rebol is about writing literate English-style code. I always said that FUNC was a fly in that ointment...and it's such an early thing people encounter. But if it's a more fundamental building block... something "lower than" FUNCTION, that has coherence when they learn about it later, then that's okay and even kind of cool.

(I once had a little thought in my head about how you might actually build something called a TION that is the other half.  So that if you wrote "FUNC TION [] []" you would get the same behavior as FUNCTION.  Think like DEF FN and DEFN.  But I think I decided that was impossible to do.)

[rebolbot]

Submitted by: BrianH

(Back to the humor...)

For replicating the old definition of FUNCTION, to be used with FUNC as FUNC TION, or with FUNCT as FUNCT ION:

    ion: tion: func [spec [block!] vars [block!]] [compose [(spec) /local (vars)]]

That constructs the real spec block from separate spec and local vars, like the old FUNCTION. Whether additional locals are gathered depends on where you put the space (using FUNCT's other features would look silly with ION). You have to love function building functions :)

You can't use a trick like this to replicate the locals gathering feature of FUNCT or any of its other tricks because those require scanning or otherwise processing the body block, which means consuming it as a parameter. You can't return that parameter to FUNC because FUNC takes two parameters, and Rebol doesn't have real multi-value returns. We could return something that could be passed to MAKE function!, but that doesn't have the same flair.

[rebolbot]

Submitted by: SomeKittens

As a newcomer, I think this change needs to be made. It lowers the barrier to entry using something that most programmers should be familiar with. FUNCT is Yet Another Rebol Thing, and there's already enough of those. Let's make it easy for the new guys.

[rebolbot]

Submitted by: maxim

YAY! let's make a fire and dance around it ... this is a joyous event... the death of abysmal R2 'FUNCTION .

Though even in R2, I haven't used FUNC for about 2 years. I've been using a modified version of FUNCT and it makes ALL code much better.

I know I'm not in the mainstream, but I'd go even further and say that FUNC should be local by default (in fact, FUNC is the one we should replace and make FUNCTION use FUNC's spec, as its much longer to write down all the time).

As such, I don't like the interface to FUNCT, because the external words are defined AFTER the body, which is bad in many ways.
I prefer it use an /external refinement and remove the extra argument...

here is how I use my version of FUNCT... called FUNCL

<pre>    funcl [
        arg 
        /external glbvar ctxvar 
    ][ 
       ; all code is local by default, except glbvar and ctxvar which keep their previous binding
    ]
</pre>
this makes FUNCL use the same tidy interface used in FUNC, but inverts its globality.

[rebolbot]

Submitted by: BrianH

As we discussed before Maxim, your FUNCL makes it impossible to define functions that themselves have an /external option and awkward to have an `external local variable or parameter. If you used external: instead that would solve that problem, and it wouldn't matter that it's not a refinement because the external words would need to be removed from the function spec (since that's the whole point of that option :). If you like I can write up a proposal for the change. We'd still want FUNCTION to have an /extern option because the list of external words might be the result of an expression - the total list of external words would be the union of both sets of words.

FUNCTION would still need the /with option though because the single case where you would be using a literal block instead of an expression that block would be passed to MAKE object!, so it's not a good idea to put into the spec argument.

[rebolbot]

Submitted by: BrianH

See #2002 for a similar proposal for CLOSURE. No worries about backwards compatibility on that one, since it only got added to R2 recently and AFIAK hasn't really caught on in R2 code yet.

[rebolbot]

Submitted by: BrianH

Pull request for this and #2002 here: rebol/rebol#109

Set the ticket to pending because of the pull request.

[hostilefork]

Was implemented in the last build of R3-Alpha, and is also the meaning of FUNCTION in Red.