Design for Something Like FLIP To Reverse Arguments

Development Functions
1

The design of a FLIP-like operation raises some questions.

If it were an operator that acted on functions, it wouldn't retrigger them. You'd have to say:

>> append 'd [a b c]
== [a b c d]

>> run flip append/ [a b c] 'd
== [a b c d]

Alternately, I guess you could use slash to run a GROUP!, but then you'd have a disabling slash and a running slash:

>> /(flip append/) [a b c] 'd
== [a b c d]

If it were instead something along the lines of RUN, where applying the flipped function was implicit, you could write:

>> flip append/ [a b c] 'd
== [a b c d]

I don't think flip/append being a synonym for /(flip append/) is a generically useful idea, compared to the likes of not/even?/ for cascading.

But if the weird idea of dialected CHAIN! ever came to pass, FLIP could go into a distinct mode based on receiving a function in the place other functions have refinements...

>> append/
== ~#[frame! [value series]]~

>> flip append/
== ~#[frame! [series value]]~

>> flip:append [a b c] 'd
== [a b c d]
1 Like
Parameter Order in Rebol
2

One Solution: REFRAMER And INTEGER Indexing

The REFRAMER is something that lets you get a chance to hook a function call after it has accumulated its arguments, but before it has done typechecking:

Introducing REFRAMER: Close Cousin to ENCLOSE

Then, FRAME! now supports INTEGER! indexing... as a way of accessing non-refinement parameters as they would be seen on the interface:

Picking Function Arguments By Integer

So just make a REFRAMER that adds no arguments, and does a parameter switcheroo before executing the frame:

flip: reframer lambda [f [frame!]] [
    let temp: f.2
    f.2: f.1
    f.1: temp
    eval f
]

>> flip append [a b c] [d e]
== [d e [a b c]]

>> flip divide 10 20
== 2

The Definition Could Be Briefer...

Right now, the SWAP operation doesn't act on variables... it acts on series, and errors on WORD!s. I kind of feel like swapping variables is the more common intent, not entirely sure what the ramifications of overloading the SWAP operation to do something that different are.

But it could be this short, for those who seek brevity:

flip: reframer f -> [swap $f.1 $f.2, eval f]

cc: @bradrn

1 Like
3

Maybe the distinction could be FLIPPED vs. FLIP? I don't know.

>> append [a b c] [d e]  ; <-- today's concept of append
== [a b c [d e]]

>> flip append [a b c] [d e]
== [d e [a b c]]

>> fappend: flipped append/

>> fappend [a b c] [d e]
== [d e [a b c]]

I can't think of it being totally obvious why one name would be used for one vs. the other. Though the impromptu FLIP is probably something that would be used more often, hence probably deserves the shorter name.

The function-generating FLIPPED could be done with a conventional ENCLOSE vs. a REFRAMER, because you know the function you're operating on in advance:

flipped: lambda [action [<unrun> frame!]] 
    enclose action f -> [swap $f.1 $f.2, eval f]
]
1 Like
4

This is an interesting way of doing it, but has a flaw... namely parameter conventions.

Although type checking isn't done until you actually run the function, if parameters are taken literally then you'd run into trouble if you tried to FLIP a function whose arguments weren't both the same convention.

So unfortunately, a real FLIP/FLIPPED would have to use a deeper mechanic. But, interesting to see how close some of these things can get...and the integer-based indexing is definitely useful.

1 Like