Re: [stack] Fwd: [Factor-talk] Currying cleave/spread combinators

John Nowak <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On Feb 2, 2009, at 10:28 PM, Adam wrote:

> Cross-posting Slava's email to the concatenative crowd.
>
> ...

I'm not sure how much of a step forward this is.

How many words/combinators are we up to now that do nothing else but  
shove values around? We have the basics like dup, drop, swap, dip,  
keep, and slip. We also have 2dup, 3dup, 2drop, 3drop, 2dip, 3dip,  
2keep, 3keep, 2slip, and 3slip. We have derived functions like nip,  
2nip, swapd, dupd, pick, tuck, over, 2over, spin, etc. Then we get  
into the more symmetrical things like bi, 2bi, 3bi, bi@, 2bi@, 3bi@,  
bi*, 2bi*, tri, tri@ 2tri, and tri*. Now we're adding to that bi-curry  
and tri-curry, bi-curry*, tri-curry*, bi-curry@, and tri-curry@.

I'm sorry, but this just sucks. We shouldn't need dozens of words that  
do nothing else but shove data around. This isn't nearly as big of an  
issue in Forth where you don't have quotations: Eight or so functions  
is enough for moving data into the right place. Factor's higher order  
nature, however, has enabled (required?) several dozen words that all  
do really boring things. I'm sure after some period of time I'll be  
able to think in terms of 'bi-curry@' and 'tri-curry*' and so on, but  
this all seems pretty unfortunate.

At the very least, it's going to be hard to convince new programmers  
to buy into this. Slava has already stated that getting new  
programmers to use the existing combinators instead of the basic  
shuffles is hard enough. Adding more combinators probably isn't going  
to help things. Making the traditional shufflers like 'rot' harder to  
get at in an attempt to lightly force people into the more symmetrical  
combinators is likely only going to frustrate new programmers.

It seems to me that there has to be a better way of doing this stuff.  
At this point, I'd be willing to just go for some sort of shuffle  
syntax.

Here's an idea for such a syntax: The input is on the left side of a  
'/' and the output is on the right side. Capitals are used only on the  
right side and indicate that a particular value is "called". For  
example:

    dip  = xf/Fx
    swap = xy/yx
    drop = x/
    dup  = x/xx
    slip = fx/Fx
    bi   = xfg/xFxG
    2bi@ = wxyzf/wxFyzF
    keep = xf/xFx
    ...

You get the idea. I think it is possible that, with just a bit of  
practice, these will be no harder to read than the mnemonics currently  
used. Yes, they're longer, but we'd often be able to get away with  
using less of them since they're more powerful.

We can actually make these shorter if we assume all values on the left  
side are named starting with 'z' and the top and 'y', 'x', etc going  
down the stack. I use '~' instead of '/' here to indicate the shorter  
variant is used:

    dip  = ~Zy
    swap = ~zy
    drop = ~y
    dup  = ~zz
    slip = ~Yz
    bi   = ~xYxZ
    2bi@ = ~wvZxyZ
    keep = ~yZy
    ...

These have the upside of letting us do away with all of the current  
"boring" words if we so desired. They'd also make it easier for new  
programmers to get involved with concatenative languages because there  
wouldn't be an initial wall of useless words to learn in order to be  
able to read existing code. The downside, obviously, is that they're  
completely unpronounceable.

- John
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.