REBOL3 tracker
  0.9.12 beta
Ticket #0001973 User: anonymous

Project:



rss
TypeWish Statusbuilt Date27-Feb-2013 05:11
Versionr3 master CategoryMezzanine Submitted byBrianH
PlatformAll Severityminor Prioritynormal

Summary Drop current FUNCTION, make it a FUNCT synonym instead
Description 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.
Example code

			

Assigned ton/a Fixed inr3 master Last Update17-Feb-2014 22:12


Comments
(0003526)
BrianH
27-Feb-2013 06:04

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.
(0003529)
fork
27-Feb-2013 07:12

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.)
(0003530)
BrianH
27-Feb-2013 21:23

(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.
(0003539)
SomeKittens
28-Feb-2013 05:21

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.
(0003562)
maxim
3-Mar-2013 20:10

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

    funcl [
        arg 
        /external glbvar ctxvar 
    ][ 
       ; all code is local by default, except glbvar and ctxvar which keep their previous binding
    ]

this makes FUNCL use the same tidy interface used in FUNC, but inverts its globality.
(0003563)
BrianH
3-Mar-2013 20:56

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.
(0003707)
BrianH
21-Mar-2013 22:15

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.
(0003710)
BrianH
22-Mar-2013 00:14

Pull request for this and #2002 here: https://github.com/rebol/r3/pull/109

Set the ticket to pending because of the pull request.

Date User Field Action Change
17-Feb-2014 22:12 BrianH Fixedin Modified => r3 master
17-Feb-2014 22:12 BrianH Status Modified pending => built
22-Mar-2013 00:15 BrianH Status Modified submitted => pending
22-Mar-2013 00:14 BrianH Comment : 0003710 Added -
21-Mar-2013 23:11 BrianH Comment : 0003707 Modified -
21-Mar-2013 22:15 BrianH Comment : 0003707 Added -
3-Mar-2013 21:14 BrianH Comment : 0003563 Modified -
3-Mar-2013 21:14 BrianH Comment : 0003563 Modified -
3-Mar-2013 21:06 BrianH Comment : 0003563 Modified -
3-Mar-2013 20:57 BrianH Comment : 0003563 Modified -
3-Mar-2013 20:56 BrianH Comment : 0003563 Added -
3-Mar-2013 20:12 maxim Comment : 0003562 Modified -
3-Mar-2013 20:12 maxim Comment : 0003562 Modified -
3-Mar-2013 20:10 maxim Comment : 0003562 Added -
28-Feb-2013 05:21 somekittens Comment : 0003539 Added -
27-Feb-2013 21:25 BrianH Comment : 0003530 Modified -
27-Feb-2013 21:23 BrianH Comment : 0003530 Added -
27-Feb-2013 10:45 fork Comment : 0003529 Modified -
27-Feb-2013 07:13 Fork Comment : 0003529 Modified -
27-Feb-2013 07:12 Fork Comment : 0003529 Added -
27-Feb-2013 06:04 BrianH Comment : 0003526 Added -
27-Feb-2013 05:33 BrianH Description Modified -
27-Feb-2013 05:21 BrianH Description Modified -
27-Feb-2013 05:11 BrianH Ticket Added -