Re: [stack] Why is point-free form so interesting?

for clarity, nothing beats a 2-d notation with peirce's "lines
of identity" connecting input and output.  for example, consider
some set of functions f ... each having n arguments and returning
m results, and suppose that the f's are arranged in some call
tree.  so f calls g with two arguments, which returns three,
two of which go to h and one to i, each of which returns a
single result, both of which go to j, which returns two results.
in a k-like syntax for lambdas, something like

    f:{
     [a;b;c]:g[x;y]
     [d;e]:j[h[a;c];i[b]]
    }

now on a sheet of paper, write down g, h, i, and j in any
orientation with slots for arguments and results:

        _ _ _ g _ _

        h _ _      i _

        _ _ j _ _

now draw lines connecting inputs and outputs (i won't attempt 
that here!)

if any of the functions have "internal structure", replace the
name of the function with a similar graph.  (extra credit:
how do you diagram recursion?)

death to linear notation -- long live the diagram!
     

----- Original Message ----- 
From: "William Tanksley, Jr" <[email protected]>
To: <[email protected]>
Sent: Tuesday, July 10, 2007 9:18 AM
Subject: Re: [stack] Why is point-free form so interesting?


> John Carter <[email protected]> wrote:
> > Christopher Diggins wrote:
> > Is there a representation of a program where the mechanism of moving
> > parameters to values in expressions is...
> >    * Explicit (ie. Can be reasoned about / transparent on inlining)
> >    * Trivial (Adds almost nothing to the code / vanishes in
> >      this representation)?
> 
> Not in general. If the data transport mechanism is explicit, then the
> written data transport will vanish only when the data transport needs
> are simple in the given notation.
> 
> Stack notation is NOT the simplest possible data transfer notation; it
> imposes a total ordering on data, when often a partial ordering is
> sufficient. Adding support for arrays helps a lot; Ripple's support
> for simultaneous return values is another interesting experiment in
> this area.
> 
> So there's plenty of research to be done on this topic.
> 
> I will add that although in general explicit data transfer can't
> vanish, it's sometimes (often?) the case that it can be made simpler.
> 
> > John Carter                             Phone : (64)(3) 358 6639
> 
> -Billy
>