# lambda the ultimate: advantages of pointfree?

## John Nowak — 2009-03-13 07:16:11

    http://lambda-the-ultimate.org/node/3233

    Feel free to chime in.

    - John

## John Nowak — 2009-03-15 05:18:25

    On Mar 13, 2009, at 3:16 AM, John Nowak wrote:

     > http://lambda-the-ultimate.org/node/3233

    >

    > Feel free to chime in.

     Hm, not much of a response so far. I don't mean to prod everyone (I

    do), but surely someone here has something good to say for the

    pointfree style beyond the usual "factoring is easier" argument? (I'm

    with Mr. Apter here; I'm not convinced it's of much significance.)

    J programmers try to keep programs tacit, Factor programmers try to

    avoid locals... is this just some silly game or is there a reason for

    it?

    - \x. john x

## Stevan Apter — 2009-03-15 14:19:41

    adhering to a style can look like a game, but it is not frivolous.

    the biggest challenge is not getting the computer to obey the rules,

    it's getting the meaning of the code to fit inside your head.  since

    this is impossible for most of us (for any application of significant

    size and complexity) we are constantly revisiting the code we write

    (this is one of the things that makes coding different from novel-

    writing.)

    style is just one further constraint we apply, whose purpose is to

    tame the unruliness.  point-free is a deep style, unlike, say,

    white-space or indentation rules.

    i adopt a point-free style for k in some circumstances, but i'd have

    to reflect on what leads me to do so.  at some point, you just "know"

    when it's appropriate and when not.

    i don't want to suggest that this is the only reason to go point-free.

    it's always a good thing to know that everything can be reduced to X,

    where X is simpler than the everything you're reducing.  i'm thinking

    of ken iverson's invention of "direct definition" for APL, which i

    think was popular among a small contingent of APLers back in the 70s.

    all functions had the form condition:true:false where alpha and omega

    were left and right arguments.  such reductions act to discipline

    the mind in ways we're all familiar with.

     ----- Original Message -----

    From: "John Nowak" <john@...>

    To: <concatenative@yahoogroups.com>

    Sent: Sunday, March 15, 2009 12:18 AM

    Subject: Re: [stack] lambda the ultimate: advantages of pointfree?

    >

    > On Mar 13, 2009, at 3:16 AM, John Nowak wrote:

    >

    >> http://lambda-the-ultimate.org/node/3233

    >>

    >> Feel free to chime in.

    >

    > Hm, not much of a response so far. I don't mean to prod everyone (I

    > do), but surely someone here has something good to say for the

    > pointfree style beyond the usual "factoring is easier" argument? (I'm

    > with Mr. Apter here; I'm not convinced it's of much significance.)

    >

    > J programmers try to keep programs tacit, Factor programmers try to

    > avoid locals... is this just some silly game or is there a reason for

    > it?

    >

    > - \x. john x

    >

    >

    >

## William Tanksley — 2009-03-15 15:25:39

    John Nowak wrote:

     > J programmers try to keep programs tacit, Factor programmers try to

    > avoid locals... is this just some silly game or is there a reason for

    > it?

     John, I don't know. Sorry.

    I helped start this group because I hoped to learn why concatenative

    languages were fun to program in even though the only one I knew

    thoroughly (Forth) was so amazingly primitive.

    I do know that using variables *gets in the way* somehow -- and Forth

    wasn't my first language, so I'm not just saying that because I'm only

    accustomed to point-free code.

    I know I also get a good feeling when working with applicative languages

    and passing an expression to a function ... but after some nesting that

    doesn't work anymore, and although one can make the code work by

    assigning the result to a variable the feeling's gone, gone, gone. In

    comparison, doing the equivalent in Forth (consigning the offending

    complex code to a word of its own) doesn't change the feel.

    I suspect working point-free in FP has a similar feel. I know working in

    J's tacit mode did, but I didn't ever get the feeling that J's tacit

    mode had anything near the applicability of Forth (i.e. it seemed that

    most people wouldn't recommend using it for everything); although I'm an

    admitted novice, so perhaps I simply don't _know_ how to work in it.

     > - \x. john x

     -Wm

## Stevan Apter — 2009-03-15 18:18:07

    pointfree is just one way of coding in a language that supports

    that facility.  i drop in and out of that style based on context.

    let me work through a k example of "mixed style", and you can see

    what i mean.

    you have a list of assignments:

       d:c+b

       c:-b

       e:d*a

       b:10

       a:20

    and you want to reorder them so that every variable is computed before

    it is used, e.g.:

       b:10

       c:-b

       a:20

       d:c+b

       e:d*a

    assume the statements have been parsed, and you have a dictionary x of

    variables-used by variables:

      d|`c`b

      c|`b

      e|`d`a

      b|()

      a|()

    to get the keys of x as y:

      y:keys x

      y

    `d`c`e`b`a

    the q expression to get the keys in the order we want is the expression:

      distinct reverse raze(distinct raze x@)scan y

    `b`c`a`d`e

    (the equivalent k expression is:  ?|,/(?,/x@)\y)

    which is not point free.  to get it into that form we need additional

    operators which would be the equivalent of the stack manipulation words

    of a concatenative language.  j contains operators of that type, k does

    not.

    i think this example illustrates two points, which i've made before:

    1. you don't need a lot of exotic special-case operators to do away

    with most of the cruft -- temporary variables, loops, backpointers,

    &c.  in this example, there's only one operation which is unfamiliar

    to most programmers, and that's "scan", which in this case takes a

    unary function and applies it repeatedly to a list until the result

    converges (it returns every step of that convergence.)

    2. what's left over, in this case naming the inputs to the expression,

    can be passed as arguments.  that remainder can be handled with the

    equivalent of stack-manipulation operators, or j's fork, hook, &c.,

    but (in my opinion) the result will be less clear than just using

    named inputs.

     ----- Original Message -----

    From: "William Tanksley" <wtanksleyjr@...>

    To: <concatenative@yahoogroups.com>

    Sent: Sunday, March 15, 2009 10:25 AM

    Subject: Re: [stack] lambda the ultimate: advantages of pointfree?

    > John Nowak wrote:

    >> J programmers try to keep programs tacit, Factor programmers try to

    >> avoid locals... is this just some silly game or is there a reason for

    >> it?

    >

    > John, I don't know. Sorry.

    >

    > I helped start this group because I hoped to learn why concatenative

    > languages were fun to program in even though the only one I knew

    > thoroughly (Forth) was so amazingly primitive.

    >

    > I do know that using variables *gets in the way* somehow -- and Forth

    > wasn't my first language, so I'm not just saying that because I'm only

    > accustomed to point-free code.

    >

    > I know I also get a good feeling when working with applicative languages

    > and passing an expression to a function ... but after some nesting that

    > doesn't work anymore, and although one can make the code work by

    > assigning the result to a variable the feeling's gone, gone, gone. In

    > comparison, doing the equivalent in Forth (consigning the offending

    > complex code to a word of its own) doesn't change the feel.

    >

    > I suspect working point-free in FP has a similar feel. I know working in

    > J's tacit mode did, but I didn't ever get the feeling that J's tacit

    > mode had anything near the applicability of Forth (i.e. it seemed that

    > most people wouldn't recommend using it for everything); although I'm an

    > admitted novice, so perhaps I simply don't _know_ how to work in it.

    >

    >> - \x. john x

    >

    > -Wm

    >

    >

    >