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

I'm tempted to cross-post.

John Nowak <[email protected]> wrote:
> I'm not sure how much of a step forward this is.
> 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.

I agree with you; and most of those words seem hard to parse. The *
and @ and 2 and 3 are easy to skim over, but are actually crucial to
understanding the words' behaviors, and worse yet, crucial to
understanding the purpose and behavior of the quotations PRECEDING
those words. You wind up having to look back too often to figure out
what's going on.

I think cleave and spread are one of the biggest advances in practical
concatenativity in a long time; I'm very impressed with Eduardo's
inventiveness, and I'm glad Slava took the plunge and converted the
entire Factor library to use them. There's no doubt in my mind that
they entirely CRUSH the usual run-of-the-mill stack shuffles for many,
perhaps most, purposes. They document intention much better than stack
shuffles for most cases. But there's something missing, as outlined
above.

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

This has been suggested before; I've been a strong proponent. The
problem with it -- if I may be so free as to complain (ha) -- is that
it's merely a better naming convention for shuffles, with all the
resulting problems with documenting intent. When you add in the
ability to execute within the shuffle you get a LOT more power, but
the naming burden becomes too much for the syntax to bear; every
shuffle becomes a "stop and think about it" moment, at least long
enough to see whether there are upper case letters.

From what I can see, adding the ability to run functions eliminates
the readability of shuffle notation, thereby removing the one thing
they originally did best: providing clear names for complex data
rearrangements. And they're certainly not clear names for documenting
dataflow intent.

Factor has, I think, proven that dataflow intent is more expressive
than general stack shuffling. Therefore, I think we ought to be
looking more along the lines of clarifying dataflow intent... And on
this point I clearly agree with you that cleave/spread aren't the
final solution.

[...later, John added:]
> Perhaps I should clarify this. If Factor did not have quotations, it
> would be sensible to offer an n-ary "cleave" syntax, "spread" syntax,
> etc. For example, we might write this:
>   [ + ] [ - ] 2bi
> As this:
>   (| + , - |)
> The problem with doing this in Factor is that they can only be used
> with constant functions; you can't use them with functions passed in
> as quotations. Accordingly, you'd still need the usual pile of
> combinators.

Actually, they might be enough to handle the vast majority of use
cases (just as cleave/spread were enough to handle the vast majority
of stack shuffles). For times when passed functions are required, a
combinator will also be needed -- that's a common shortcoming with
syntax.

I wonder if Factor's impressive code-querying tools are powerful
enough to answer the following question: "How common is it to pass
literal quotations to 'cleave' and 'spread'?" If it happens a
reasonable amount (and if Factor can automatically tell us where!), it
might be worth our time to start converting those examples to see if
there's a decent readability increase.

> - John

-Wm