[doc/announce/2011.03] added

doc/announce/2011.03

@@ -0,0 +1,117 @@
+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.
+
+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 it 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 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 good 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 some importance.
+
+With that, there's only one thing that I wish to say to my esteemed
+colleagues in the committee:
+
+Have the appropriate amount of fun! \o/