REBOL3 tracker
  0.9.12 beta
Ticket #0002119 User: anonymous

Project:

Previous Next
rss
TypeWish Statuspending Date28-Feb-2014 03:43
Versionr3 master CategoryMezzanine Submitted byBrianH
PlatformAll Severitymajor Prioritynormal

Summary WRAP function
Description The main motivation for this function is to completely replace the CONTEXT function where it is being used to organize code rather than return an object (see also #2123).

Basically, it's like USE but with FUNCTION's set-word gathering.

Used like USE for doing a block of code with local variables, but without needing to declare those variables. In this case we want the local context to have 'self like a normal object, just for utility. Similar to doing the code in an object's spec block, but deep-collecting set-words instead of shallow, returning the results of the evaluation and throwing away the object. Keeps the uninitialized-words-error advantage of objects too.

Subject to #539 unless it's made native, but there's no other reason it can't be mezzanine (doesn't need a selfless object).
Example code
wrap: func [
    "Evaluates a block, wrapping all set-words as locals."
    body [block!] "Block to evaluate"
] [
    do bind/copy/set body make object! 0
]

Assigned ton/a Fixed in- Last Update27-Aug-2014 05:58


Comments
(0004302)
abolka
5-Mar-2014 01:30

I don't think that's a particularly useful function, but that may also be just because of me not having had it available before. Trying to reflect on the past and projecting into the future as neutrally as possible, I still don't see me using this much, though. (UPDATE: Changed my opinion on the utility, see one of my more recent comments further down the line.)

Irrespective of the actual utility, I think this is rather badly named. Again, totally subjective. But the name isn't an action / verb (even though "to scope something" seems to be picking up as an colloquialism for "to estimate the scope of something"). Further, some in this community seem to be rather picky about "Rebol having no scope". In front of that background, naming this function SCOPE may be a bit misleading. I strongly suggest that we try find a better name.

To not end on this negative note, some suggestions for a better name: LOCALIZE, CONFINE, CURTAIL.
(0004304)
BrianH
5-Mar-2014 01:59

Well, the main motivation for this function is to completely replace the CONTEXT function where it is being used to organize code rather than return an object (see #2118 for the displacement of the other use of CONTEXT, and #2123 for the overall goal). This is the CONTEXT function that we could have written in Rebol 1 or 2 if we had expandable objects and BIND's /set option.

This function is meant to be a core control function that does what USE does, but locals-gathering so you don't have to keep track of the list of words - a popular new code pattern in Rebol and Red. We don't want to call it USE because it's taken by something we don't want to get rid of, and the name USE implies that something to use will be provided as an argument.

If it needs a better name, it needs a better name. LOCALIZE tends to have localization implications which will just confuse people; CONFINE and CURTAIL seem too negative; we can't use LOCAL because of /local; we need something else. The reason we called it SCOPE is because it serves the same function as a local variable scope in languages that have scopes, and it works the same way as well, at least as far as apparent behavior is concerned. This is like nested { ... } blocks in C, or do ... end blocks in Ruby. If you can come up with another name that implies that local-variable-scope use, which is a nice enough name that we could use it in every single code example that currently uses CONTEXT and ignores the return value, then please suggest the new name.

This is towards the goal of deprecating the CONTEXT function altogether (#2123), because the name "context" is a bad name for an object, and makes conversations about real context difficult. So, we won't really benefit from calling this function CONTEXT.
(0004305)
abolka
5-Mar-2014 02:30

Thanks for expanding on motivation. (Please lift that to the description as well; just the first sentence of your comment, without the paren).

Your description of the intended use immediately elicited encapsulation and therefore ENCAPSULATE from my mind. ENCAPSULATE may have an undesired OO connotation, but I think thats's actually quite nice. It may be considered a bit long, though. Shorter variants on that theme: ENCLOSE, ENCASE.

Other ideas: SEPARATE, ISOLATE.

(I'll also rethink SCOPE under this additional aspect of "replacing one particular use CONTEXT". Will take a few days to settle. Currently, I'd still suggest we need a better name.)
(0004306)
BrianH
5-Mar-2014 02:38

Remember, the name needs to be short. Comparable names in other languages: do, begin, {. The name SCOPE is actually a bit too geeky. It needs to seem like a primary feature of the language, at the same level as IF, since it will be the go-to local-variable-scope control structure for example code that we want to show off the language. And assume that the name would be used for the primary non-function-scope, non-loop, non-conditional local scoping control function for Red as well.
(0004308)
BrianH
5-Mar-2014 06:37

As another naming suggestion, we can call this function CONTEXT. As long as #2118 is implemented in the way mentioned in #2123 (both mezzanine and native), this function can be the new CONTEXT. Then this function can be seen as a an enhancement of CONTEXT, giving it a sensible return value and more thorough protection from unintended modifications outside of the context. It's a win-win.
(0004310)
pekr
5-Mar-2014 07:55

I vote for the name to stay as a CONTEXT.
(0004328)
Ladislav
7-Mar-2014 04:09

I dislike the SCOPE name for the proposed function as well. All other proposed names look more reasonable.
(0004329)
Ladislav
7-Mar-2014 04:12

Also, this is not a minor change, influencing the code that is already written and using the CONTEXT function.
(0004330)
BrianH
7-Mar-2014 05:30

Yeah, "influencing the code that is already written and using the CONTEXT function" is definitely the point here. If all cases where the object return value of the CONTEXT function is not ignored, are changed to use the OBJECT function instead (#2118), we can call that a victory for the Rebol community. We need to stop calling objects "contexts". The main upside of calling this function CONTEXT would be to make that happen sooner rather than later. If we use a different name, it will take longer to achieve that goal.

The old CONTEXT function, like the old FOR function (as of #884) and a lot of old functions, will still be around for those who need them. You've heard of R3-Backward, it's the way to have backwards compatibility where needed by old code, while keeping the new Rebol language clean and bright.

"dislike the SCOPE name" ... "All other proposed names look more reasonable." - but not reasonable enough. The other names proposed so far are too constraining-feeling for what is intended to be a core function to replace CONTEXT, except LOCALIZE (which would be confusing, due to it being a common term for something else). I don't like SCOPE either, but the best suggestion other than that has been CONTEXT. Even better would be LOCAL, but I can't think of a way to make that work in functions which use /local.

Please, suggest something else, I've run out of ideas.
(0004332)
Graham
7-Mar-2014 07:11

I'm suggesting WRAP instead of SCOPE
(0004333)
BrianH
7-Mar-2014 07:25

And we have a winner! WRAP is short, it has positive connotations (more blanket than straight-jacket), and we can have a good story for its meaning. It's very modern.

Changing the ticket accordingly, and the PR. #2123 will be a slower deprecation.

Implemented in https://github.com/rebol/rebol/pull/207
(0004357)
rebolek
8-Mar-2014 08:27

+1 for WRAP just in case there's still opposition :)
(0004414)
fork
6-May-2014 04:28

Decided WRAP is fine, if that expedites getting what I wanted. :-/

To truly appreciate that you are getting the result of an evaluation it might be cast as "DO/WRAP". Then again it's not "DO/WHILE" or "DO/UNTIL" or "DO/IF"...there's no shortage of implicit DO'ing in operations. It's just that *usually* there's some other parameter or condition, here there isn't one.

Main thrust of all of this was to let CONTEXT go. There is no separate context type...so OBJECT suffices, and CONTEXT only confuses matters. I suppose SCOPE would be bad in the sense that you wouldn't be sure if you would expect it to return a value from the evaluation or something representing the scope; the same problem CONTEXT had. OBJECT is clear: you do some stuff, and get an object. WRAP is arguably clearer that it is isolating code... you might expect a "wrapper" back from it... but you don't expect a while! back from a WHILE loop, so. DO/WRAP is the only thing that I might think would be more explicit.

WRAP as a word is at least not a bad choice.
(0004494)
abolka
27-Aug-2014 05:58

+1 for the name WRAP.

Having used this for a while now, I can report that it is very (contrary to my initial belief). In my experience so far, WRAP is the better USE in many (but not all) cases.

Date User Field Action Change
27-Aug-2014 06:19 abolka Comment : 0004494 Modified -
27-Aug-2014 05:58 abolka Comment : 0004494 Modified -
27-Aug-2014 05:58 abolka Comment : 0004494 Added -
27-Aug-2014 05:54 abolka Comment : 0004302 Modified -
27-Aug-2014 05:54 abolka Comment : 0004302 Modified -
6-May-2014 04:28 Fork Comment : 0004414 Added -
8-Mar-2014 08:27 rebolek Comment : 0004357 Added -
7-Mar-2014 07:54 BrianH Comment : 0004333 Modified -
7-Mar-2014 07:53 BrianH Comment : 0004300 Removed -
7-Mar-2014 07:27 BrianH Code Modified -
7-Mar-2014 07:27 BrianH Summary Modified SCOPE function => WRAP function
7-Mar-2014 07:25 BrianH Comment : 0004333 Added -
7-Mar-2014 07:11 Graham Comment : 0004332 Added -
7-Mar-2014 05:41 BrianH Comment : 0004330 Modified -
7-Mar-2014 05:30 BrianH Comment : 0004330 Added -
7-Mar-2014 04:12 Ladislav Severity Modified minor => major
7-Mar-2014 04:12 Ladislav Comment : 0004329 Added -
7-Mar-2014 04:09 Ladislav Comment : 0004328 Added -
5-Mar-2014 07:55 pekr Comment : 0004310 Added -
5-Mar-2014 06:40 BrianH Comment : 0004308 Modified -
5-Mar-2014 06:37 BrianH Comment : 0004308 Added -
5-Mar-2014 02:59 BrianH Comment : 0004304 Modified -
5-Mar-2014 02:56 BrianH Comment : 0004306 Modified -
5-Mar-2014 02:55 BrianH Comment : 0004304 Modified -
5-Mar-2014 02:40 BrianH Comment : 0004306 Modified -
5-Mar-2014 02:39 BrianH Comment : 0004306 Modified -
5-Mar-2014 02:38 BrianH Comment : 0004306 Added -
5-Mar-2014 02:34 BrianH Description Modified -
5-Mar-2014 02:33 BrianH Comment : 0004304 Modified -
5-Mar-2014 02:30 abolka Comment : 0004305 Added -
5-Mar-2014 02:17 BrianH Comment : 0004304 Modified -
5-Mar-2014 02:15 BrianH Comment : 0004304 Modified -
5-Mar-2014 02:00 BrianH Comment : 0004304 Modified -
5-Mar-2014 01:59 BrianH Comment : 0004304 Added -
5-Mar-2014 01:30 abolka Comment : 0004302 Added -
5-Mar-2014 00:39 BrianH Comment : 0004300 Added -
5-Mar-2014 00:38 BrianH Status Modified submitted => pending
5-Mar-2014 00:38 BrianH Category Modified Unspecified => Mezzanine
28-Feb-2014 03:52 BrianH Code Modified -
28-Feb-2014 03:52 BrianH Description Modified -
28-Feb-2014 03:43 BrianH Ticket Added -