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: <http://github.com/downloads/masak/yapsi/yapsi-2011.03.tar.gz> 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: * It is necessary for some amount of computer memory to be put aside for the purpose of keeping track of the position of the invocation, so that the instruction evaluation can proceed from there after the completion of the routine. * In fact, the scheme that allows for routines to be called from the main program may easily be extended to allow for routines to be called from other routines. This would require a push-down data structure -- something that I've tentatively chosen to call a "stack" because of the way you add and remove things from the top of it, like with a stack of plates -- to keep track of all the invocations that have been made but not yet completed at a given point in the computer program. * It is even a possibility for a routine to invoke *itself*, or for two or more routines to contain invocations of each other. While this may seem like an especially perverted idea, early investigations reveal that this phenomenon (which I have chosen to call "invocation reccurrence") might actually have real-world uses. I propose we leave the ability in for now rather than dismiss it outright. * There is also no *a priori* restriction on a routine being declared inside another routine. This notion, however, truly *is* perverse and has no possible merit whatsoever. * I have an additional idea about equipping the invocation with "arguments", values which might then be passed into the routine. This would further increase the range and utility of routines, by making them into a kind of "templates" that can then be filled in for each particular invocation. The idea appeals to me a great deal, but I haven't had time to try it out in practice. I am currently wrestling with a theoretical framework for this based on something called "the bondage of signatures". 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 42 42 >>> my $i = 10; sub foo { say $i; if --$i { foo } }; foo 10 9 8 7 6 5 4 3 2 1 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/
