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.