Idea for Naming Function Arguments Out of the Way

Development Functions
1

As part of Rebol's contention-for-short-names problem, there are many instances where refinements have names like :ALL where they conflict with common natives or lib functions.

When this happens, I tend to do something to name them out of the way and put the lib function back:

foo: function [
    bar [block!]
    :all "foo all the bars"
][
    all_FOO: all
    all: lib.all/
    ...
]

Clearly we need a better pattern.

Maybe there could be two features that work together on this. One would be the ability to ask that the function's frame be passed in as a variable, and another would be to suppress binding of an argument in the body.

foo: function [
    bar [block!]
    <hide> :all "foo all the bars"
    <frame> f
][
    all [...]  ; would be the ALL from LIB
    if f.all [print "Fooing all the bars"]
]

It's already kind of necessary to be able to get the FRAME! of a function into a variable (asking for binding of 'return is clunky, and you have no way of doing it with a lambda that has no parameters or locals). Then the dot could mark arguments as being "member-access-only" via the dot.

I think this is better than trying to name things out of the way. It could work for normal arguments too:

foo: function [
    <hide> bar [block!]
    <hide> :all "foo all the bars"
    <frame> f
][
    ; use f.bar and f.all, with BAR and ALL left as-is
]

It might not be the most beautiful thing in the world, but this is a real problem that is very frustrating when it comes up. And when you encourage people to play with words, they shouldn't be afraid to reuse them in refinements if they make sense.

Objections? Better ideas? :cricket: :cricket:

Maybe we could use TUPLE! to do it?

foo: function [
    .bar [block!]
    :.all "foo all the bars"
    <frame> f
][
    ; use f.bar and f.all, with BAR and ALL left as-is
]

It's a little hard to see on refinement args, but it would help hint "you are supposed to use dots".

We'd want it to be :.all and not .:all, because the latter has no TUPLE! in it... that's a 2-WORD! CHAIN! with a dot in the first position.

1 Like
8

While reading this, I had the thought, that tuples might be useful here, so I think this is in support of your idea.

I'm a bit surprised at how integral tuples seem to become to the features of whatever ren-c morphs into :wink: as tuples have been one of the lesser useful datatypes of Rebol (at least to me).

2 Likes
Testing TUPLE! + CHAIN! + PATH! Structuring
9

So I thought it couldn't work for a second, because I was thinking about .:foo, and I was like "oh, that's not a tuple"... and so I ripped this all up to start thinking about new ideas.

But then I put the thread back together and thought, it does work as :.foo

It's saying the right thing. I guess the catastrophe here would be if you can't see the dot, and so you wind up calling the library function when trying to name the variable. :frowning:

Maybe... two birds with one stone?

This way there doesn't have to be <frame>... the name of your frame is just whatever is in the first spot of the tuple. It enforces that you use the same name every time (I guess it could let you have multiple variables for the frame, but, that's not a very interesting axis...)

And if you just want a local for a frame not connected to anything, maybe... uh... some syntax for that in the object creation dialect?

 bar: function [
     "sample function with no arguments that still gets a frame"
     {f <self>}
 ][
 ]

This Looks Pretty Coooool

I think it may be time to take the plunge.

2 Likes