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

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" <[email protected]>
To: <[email protected]>
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
> 
> 
>