Skip to content
Browse files

[doc/announce/2011.03] added

  • Loading branch information...
1 parent 745a83a commit 0cf3d516c8c7bc175d1576e5f65a6048ec19ccc2 @masak committed
Showing with 117 additions and 0 deletions.
  1. +117 −0 doc/announce/2011.03
117 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:
+ <>
+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/

0 comments on commit 0cf3d51

Please sign in to comment.
Something went wrong with that request. Please try again.