# Re: [stack] comments - 3

## Louis Madon — 2000-07-13 01:45:59

    phimvt@... wrote:

     >     Also under the same heading, some discussion on closures, and

    > the clarification that they belong with lambda-calculus languages

    > which do have formal parameters ("variables") for substitution

    > when the function is applied to actual parameters ("arguments").

    > But it is not correct that closures make sense for all applicative

    > languages - in combinatory logic there are functions which can

    > be applied to arguments, but there are no variables and hence no

    > closures.

     How would you describe curried functions in combinatory logic? Are they

    not a kind of closure?

     >     There is something somewhat close to closures (pun not intended).

    > Suppose we have a program

    >     a b .. k l m  [..]  ?  n o  ..  x y  i

    > where a..m create some items on the stack, then a program [..]

    > is pushed, and now we want a "closure-like-maker" ? which

    > will wrap up the stack together with [..] which is then passed

    > along (but not modified) by n..y . At  this point the final i

    > is supposed to execute the wrapped up version of [..] with

    > the earlier stack.

    >    I think the required effect can be achieved by

    >        ?   ==   [stack] dip [infra] cons cons

    > Then what exists in the period n..y is

    >        [ [oldstack]  [..]  infra ]

    > All sorts of variants are possible. I still do not know when such

    > a beast would be useful, but I'd be glad to hear suggestions.

     Another variant would be the existing "b" combinator:

    [C] [P] b

    where C is the "context" and P is the program being closed over. In

    general, I think that any kind of parameterisation of program

    construction is closure-like (depends on what exactly is meant by

    "closure" I guess).

    --

    Louis.