The core feature of Y (pronounced: "why") is introspection. During bootstrap Y questions its own existence, and from that the parser is generated. Y does not translate to C or assembly or machine code. Instead it materializes directly into RAM because of its declarative nature.

Y does not have source code. It materializes out of self-doubt.

Each line needs to start with "Y".

The Y parser runs in two processes, y and y_not. Each statement is simultaneously parsed by y and y_not. They will formulate theorems in an attempt to convince each other, until one runs out of questions and yields y continue.

Y generates itself. To bootstrap Y, run:

Y Y

Y can translate your entire C/C++ project. To convert, execute:

Y c++

You can generate Y code to C++ with:

Y not c++

Y's resource model is based on a question heap. The Y parser consumes questions from the heap until it is depleted, in which case it produces a y continue exception. As such, it is important to always keep your heap populated with a healthy amount of questions. Questions are in turn generated from controversy, which is a finite but replenishable resource typically produced by Hacker News and/or Reddit threads (although Y parsers can be their own source of controversy- see garbage recollection).

If you are writing code in Y, you do well to follow these well-established patterns that ensure your code is at all times questionable:

The key challenge to writing code for a Y parser is to ensure it has access to a healthy supply of questions. Bikeshedding is a cheap and effective method for generating large amounts of questions without consuming a lot of controversy. While bikeshedding by itself is unlikely to produce information that is of much utility, it is an important technique to emulate progress (also see: procrastination).

To ensure that Y's parser can run tasks in parallel, a developer should employ over-promising where possible. With this technique, the Y parser can return answers with questionable confidence levels in response to difficult questions. This allows the consumer of the answer to continue its work while the parser may (or may not) continue to work on the question.

To avoid running out of questions while addressing a particularly hard question, a good technique is to wait an undeterminate amount of time while doing nothing in the hope that the question heap repopulates fast enough. Procrastination is particularly effective when used in combination with bikeshedding.

In a real-time system, a parser may need to finish before a certain communicated time and date. To satisfy these kinds of restrictions, parsers can employ the "pre-emptive release" pattern. With this pattern, the Y parser terminates at said date and releases its current state. While similar to over-promising, it is not the same as a pre-emptive release is not required to produce a result that answers the posed question.

An advanced technique combines pre-emptive releasing with over-promising to generate maximum controversy by over-promising the release date, and then following this up with a pre-emptive release.

Garbage recollection ensures that all statements generated by a parser must be preserved and presented as truth, even when verifiably wrong. Producing large quantities of conflicting statements is a well-known technique for increasing the amount of controversy in a system, thus keeping your parser populated with fresh questions at all times.

To find out Y's release date, run this statement:

Y release