Strangely Consistent

Theory, practice, and languages, braided together

Yapsi 2011.03 Released!

Dear members of the committee,

I hereby present for your scrutiny the fruits of a month's intense labor. I call it "Yapsi", and label it the March 2011 release.

You can peruse it here.

You will recall my earlier submissions on the same topic. To my great disappointment, they were rejected by the esteemed fellows of the committee, on the grounds that they didn't advance the state of the art of Computer Science. Though immensely saddened by this verdict, I am compelled, in retrospect, to agree. The previous submissions were all "official and complete", though hardly ground-breaking.

However, this month I bring before you an invention that I believe has the potential to change how we think about computing machines and the entering of program code to same. Let me take a few moments to explain my new device to you.

In essence, what I have created is a tool for abstracting a sequence of program instructions into self-contained "routines", each of which is identified by a name. I know this may seem like an odd idea to some of you; why not (you may ask) list the program instructions from start to finish, in one single chain of thought? Though on the surface the new routines may not seem to add anything of value, I submit to you that they nevertheless have distinct advantages. I will enumerate some of these advantages for you, but let me first instruct you on how to employ a routine in practice.

A computer program may have zero, one, or even several routines. The names of the routines must be unique — exactly why this is will become clear in a few moments. The flow of program instruction evaluation does not automatically "visit" the routines; they are standalone and apart from the main flow of the program instructions. Instead, flow is moderated through a mechanism called "invocation", which I will now describe.

(Pardon? Oh, yes please. Milk, two lumps.)

At any point in the normal instruction flow, one may then refer to one of the routines by name, and that routine will be executed in the place of that invocation. I'm sure you all see the immediate benefit of such a scheme; instead of having the same sequence of program statements be repeated in different parts of a vast program, one may now instead simply repeat the same (relatively short) routine identifier. The actual code, which is invoked from different places, is then written down only once, inside the routine. This is in accordance with a general principle I've evolved, that of "Not Repeating Oneself".

However, there is also a secondary psychological benefit to this scheme: if the name of the routine is well-chosen, it may act as a mnemonic and make the computer program easier to read and understand. (Thus, for example, a routine to perform multiplication might be named "perform_multiplication".) The abstraction, one might say, works not only on the level of the computer, but also on the level of the human reader. It is yet unclear to me exactly how important a role this secondary effect will play, but I suspect it will be quite noticeable.

After the routine has finished running, the instruction evaluation proceeds from the point after the invocation. Thus, one might say, the program behaves as if the routine had actually been positioned in the place of the invocation. This is the nature of my abstraction.

A few points of clarification are in order:

In showing these ideas to a few select people, I have come to understand that there is some concern as to the speed impact of maintaining the above-mentioned "stack". While I concede that there is indeed an unavoidable cost involved at the boundaries of each routine, I believe that it can be made very small, such that only the most speed-stipulating computer programmers will care for the difference. In the long run, I predict that the benefits of the abstraction mechanism itself will dwarf concerns about performance.

I believe that routines in computer programs are here to stay. In a few decades, we might see them as something commonplace, almost mundane.

In the present release, I also wish to highlight the excellent work of my associate, Tadeusz Sośnierz (tadzik++). He has provided Yapsi with a feature called a "REPL", which I also believe will be of importance.

For a complete set of changes to this release, please refer to doc/ChangeLog.

In fact, if you will allow me to perform an "instantaneous demonstration"... you will? Oh good.

$ bin/yapsi
>>> sub foo { say 42 }; foo; foo
>>> my $i = 10; sub foo { say $i; if --$i { foo } }; foo

With that, I bid the esteemed colleagues of the committe a good evening, with what I believe to be fitting farewell:

Have the appropriate amount of fun! \o/