Is IN too good a variable name? vs (WITH, FIND?)

Development Naming
1

@rgchris suggested WITH for virtual binding, as in do with context [...].

I said that the historical IN operator--which is used to bind words to contexts, wouldn't have any alternate purpose for blocks. So it was economical to consider it the virtual binding operator.

But that took for granted that IN was a good name to take for an operator. Is it, really? Or are people likely going to want to have local variables called in and out so often that this would be inconvenient? (You can say lib/in but would you want to?)

We've switched INPUT as a verb to ASK TEXT! and I think that's much better, so pushing IN out of the way seems like it might be good as well.

This occurred to me while noticing that virtual binding chains can do something regular binding can't do, which is be removed. You can peel off layers of virtual binding to get a view of the thing before. Naming that out seemed bad, which drew my attention that we've taken for granted that in is an annoying word to be taking for such a common use. And without seemed kind of like a good "virtual unbinding" operator.

But when you compare if in obj word [...] against if with obj word [...], the WITH doesn't make a lot of sense for searching to see if the key is present.

But could FIND be used for that? It's not totally clear what FIND on an object would do, but Rebol2 made it search the keys, not the vars:

rebol2>> find make object! [x: 10] 'x
== true

rebol2>> find make object! [x: 10] 10
** Script Error: Invalid argument: 10

That FIND could work on ANY-WORD!, and return the bound word in the case of objects instead of true. I'm not sure if it would be any more weird than returning a LOGIC! instead of a position...arguably more consistent (the key is the "position" in an object, because it can be used as a cache for re-retrieving what you found).

So that would give you if find obj word [...], and then you could use any of find obj word or with obj word or bind obj word to get the bound word.

(If we want to stress BIND is mutating, then maybe it shouldn't take WORD!s as arguments...but PATH!s with nested GROUP!s/BLOCK!s throw a bit of a wrench into everything.)

Anyway, just challenging if the word IN is a bad thing to take as a native.

1 Like
2

I've taken such a long time to learn in that with is a mission too far!

3

I suggest we replace IN with INSIDE which frees IN for use as a variable. The number of times I normally use IN is not so great to make the extra typing a hassle.

2 Likes
4

There are pros and cons about this. As stated INPUT has been freed for use. For streams you can use INSTREAM. Because Rebol is interpreted a short name is good for speed but then I and O are shorter than IN and OUT. For output I often use RESULT. For the input I consider a meaningful name to be preferred over IN or INPUT.

5

Actually not a bad suggestion... however...

Maybe we're overlooking the obvious, here. What about USE?

use [x] [x: 10, ...]  ; when you pass it a block

obj: make object! [x: 10]

do use obj [...]  ; when you pass it an object

Because really, what else would USE do if you pass it an already-made object?

Hmmm...though if we believe you can specify a chain of things to bind, the fact that USE already has meaning for blocks gets in the way. You can't say:

use [obj1 obj2] [...]

You'd have to write:

use obj1 use obj2 [...]

It could be a dialect, like function specs:

use [var1 var2 <in> obj1 obj2] [...]

And then just assume that if you passed an OBJECT! you meant <in> (?)

6

We could also say that IN is an abbreviation for INSIDE and then if you're the sort who prefers to take the short name for variables then at least you won't have to invent your own longer name for accessing the operation.

That might split the difference.

Another Musing... Take BIND for Virtual Bind

BIND has mutated the bindings of blocks when you pass them, and traditionally Rebol makes the thing being modified the first argument. (See this discussion of parameter order)

IN was also mutating (though no longer). But it reversed the parameters so you could have a long block after a short context reference:

do in context [
    this block
    could be
    very long
    ...
]

That looks better than using BIND's order:

do bind [
    this block
    could be
    very long
    ...
 ] context  ; "huh, what's this about" (have to scroll up to figure it out

If we rethought mutating BIND to be something else, then we could reorder BIND's parameters:

do bind context [
    this block
    could be
    very long
    ...
]

This would make more sense for WORD!s, because all bindings of words are effectively "virtual" (binding a word does not impact the word you passed in--it can't because words are passed by value, not references like series are).

It doesn't look quite as coherent for testing if a word is "in" a context as IN did:

if bind context word [...]
if in context word [...]   ; this does make a bit more sense

But maybe that's just a matter of how we've learned to think of BIND as being mutating. If we read that as "bind this context ONTO word" it might be okay.

I don't know what you'd call the mutating operation. bindify? contextualize? :-/

Anyway, just a thought I had to add to the mix...I'm not really convinced of anything yet, and the historical IN usage kind of looks the best...so I'm leaning to the IN+INSIDE middle ground.

1 Like