WRAP function

[Siskin-Bot]

Submitted by: BrianH

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).

wrap: func [
    "Evaluates a block, wrapping all set-words as locals."
    body [block!] "Block to evaluate"
] [
    do bind/copy/set body make object! 0
]

---

^{Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Mezzanine Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#2119}

Comments:

Rebolbot commented on Mar 5, 2014:

Submitted by: abolka

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.

---

Rebolbot commented on Mar 5, 2014:

Submitted by: BrianH

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.

---

Rebolbot commented on Mar 5, 2014:

Submitted by: abolka

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.)

---

Rebolbot commented on Mar 5, 2014:

Submitted by: BrianH

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.

---

Rebolbot commented on Mar 5, 2014:

Submitted by: BrianH

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.

---

Rebolbot commented on Mar 5, 2014:

Submitted by: pekr

I vote for the name to stay as a CONTEXT.

---

Rebolbot commented on Mar 7, 2014:

Submitted by: Ladislav

I dislike the SCOPE name for the proposed function as well. All other proposed names look more reasonable.

---

Rebolbot commented on Mar 7, 2014:

Submitted by: Ladislav

Also, this is not a minor change, influencing the code that is already written and using the CONTEXT function.

---

Rebolbot commented on Mar 7, 2014:

Submitted by: BrianH

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.

---

Rebolbot commented on Mar 7, 2014:

Submitted by: Graham

I'm suggesting WRAP instead of SCOPE

---

Rebolbot commented on Mar 7, 2014:

Submitted by: BrianH

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 rebol/rebol#207

---

Rebolbot commented on Mar 8, 2014:

Submitted by: rebolek

+1 for WRAP just in case there's still opposition :)

---

Rebolbot commented on May 6, 2014:

Submitted by: fork

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.

---

Rebolbot commented on Aug 27, 2014:

Submitted by: abolka

+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.

---

Rebolbot mentioned this issue on Jan 12, 2016:
Deprecate the CONTEXT function

---

Rebolbot mentioned this issue on Jan 22, 2016:
[Epic] Holes in our evaluation model

---

Rebolbot mentioned this issue on Feb 11, 2016:
Replace CONTEXT function(s) with OBJECT

---

Rebolbot added Type.wish and Status.important on Jan 12, 2016

---

[Oldes]

>> a: 1 wrap [probe a: 2] a
2
== 1

Closing this as wrap is there for quite a long time.