Practical application of calculus SKI and BCKW

I can understand how to create and think about the calculus of SKI and BCKW, but I can never find practical application. Maybe I'm not looking deep enough? That is, I am wondering if (an example only, please, I do not mean that it is true) Java Servlets use S a lot, and Python generators are a BCW example, and I just can not see through the forest of trees?

+7
functional-programming lambda-calculus
source share
4 answers

In Haskell, they are everywhere !

  • B - <$>
  • C - flip
  • K - pure
  • I - id
  • S - <*>
  • W - join

From the point of view of Haskell, <$> means "do in context."

  • (+2) <$> (*3) means adding two after multiplying by three.
  • (+2) <$> [1,2,3] means adding two to each item in the list.
  • (+2) <$> (read . getLine) means adding two to the number I just read.
  • (+2) <$> someParser means adding two to the number I just analyzed.

Things that have a context are called functors. All of your Java / Python / C ++ iterators are just weird top version functors.

Another mix: combinator S and K complete Turing together. In Haskell, pure and <*> together form an applicative functor.

Of course, understanding how other combinators work will require a Haskell study. But this example shows how combinators are so rooted in the language.

+8
source share

Although the lambda and SKI calculus does not reflect the input and output systems of most programming languages ​​(such as graphics, network connections, or perhaps even standard input and output data), the way to structure practical computer programming is consistent with Lambda (and therefore SKI and BCKW ), such as the idea of ​​recursion and several ways called functions. Many of these programming languages ​​have lambda abstractions for use as functions.

+3
source share

All about control.

May start at a lower level. An applicative system is simply a system in which objects can be applied to other objects. A simple example of an applicative system is bash. ls | More It can be assumed that they are in some kind of environment, and that the above means ls in the environment, and then do more. In applicative notation, this is more @ (ls @environment) However, more complex things could be done, such as ls | grep template | More So, now in applicative notation it is more @ ((grep @pattern) @ (ls @environment)). Check out the grep @ pattern. Grep is applied to a pattern that returns the program to match that pattern as a result of ls. This is the point of application, the application of the program to the arguments, the creation of new programs from "atomic" (so-called built-in) programs. However, we cannot do too much programming with just a primitive application or built-in ones. We need a way to structure our input and apply our primitives to our input.

Here is the lambda. Using lambda, you can generalize (grep @ pattern) To apply grep to any input, (grep @X) However, we must have a way to get grep input. So we usually use functions. f (X) = grep @X The above process is called abstracting the argument. But there is no reason to think that the name f is special, so we have the syntax: lambda X. grep @X Then the lambda X. grep @X can be applied to the input and the input will be replaced in the body and evaluated. However, the replacement may become erratic, the associated variables can be difficult to implement on the machine. SKI (or B, C, K, W) makes it possible to create lambda material without substitution and instead simply replaces the application.

Recall, the application is what everything is about. It is very convenient to reason at the level of application of the program to something (perhaps to another program). Lambda calculus makes it possible to structure the input and application of programs to arguments. SKI makes it possible to make lambda without explicit substitution.

It should be noted that the abbreviation SKI is inherently lazy, so you may need some consideration in the actual use of SKI to structure your application. Indeed, the arguments can now be fully evaluated and can also be a partial application. You can get around this with type theory and only evaluate the program at its input if the program is in the main position of the application. Ie, if you write with closed lambda terms translated into SKI, then p @ arg1 @ .... It must be if p is a primitive program, then the rewriting is complete, and therefore all arguments 1) are available, 2) are fully appreciated. However, I have not proved this, and this may not be true with a sufficiently strong type theory ...

+2
source share

The SKI and BCKW calculuses are different from the lambda calculus (which has well-known applications in the concept of functional programming), because they are in point-free form . See also tacit programming . They form the basis of understanding how to create functional programs without the named arguments.

We see its applications in certain languages ​​(for example, Joy and Cat ). I once posted on Lambda-the-Ultimate.org about the relationship of SC calculus with Cat and Joy.

What is its value for: BCKW and SKI (or SK) calculations are almost identical, but the basis of BCKW has fallen out of fashion.

+2
source share

All Articles