1. Predefined functions Munge() and MungeConsistently() will be available.
   • Munge calls MungeConsistently, but passes in the count of how many calls to Munge have already been made, so it is essentially random but still reproducible.
   • MungeConsistently takes a number as its first parameter, which will be used to pick the sub to call.
2. Everybody is given a random number from 0..1, indicating their position in the program. (so that early code can do more input, and late code can do more output)
3. PASS 1: Everybody then submits a small block of code that does something "useful", PLUS a small subroutine to be included in the Munges
4. PASS 2: Each person is given the task of gluing together two adjacent pieces of code, NOT including their own. (One player is chosen to glue the command line to the first block by choosing the input parameters, so there are N glues for N players)

I don't believe programs can handle as much randomness as you're suggesting... [...] The second pass to glue things together should change the result from a twitching mass of random code to something that at least runs to completion.

I personally believe that... whoa! what you describe is an entirely different game altogether: which is not to say it wouldn't be interesting or fun. But I explained the goals of the game as I see them in my reply to graff's comment, which expressed similar concerns as yours: to be fair I'm specifically interested and I think that people who would like to play an autenthically "Exquisite Corpse" version of the game should be specifically interested in the "twitching mass of random code" getting out of it! (Thank you for contributing this very illuminating expression!)

Since both you and graff, reasonably, point at subs, I recognize that as an alternative to the "last statement rule" a player may give a sub call of a sub he didn't include in his portion of the script, for the next one to write one. But I wonder if that couldn't be too restrictive of his freedom of could turn the game, if all players choose to handle "continuations" that way into a boring series of nested sub calls... Perhaps a restriction should be imposed to the effect that this kind of continuation can not be given for more than one turn. Thus a player writing the "requested" sub may or may not actually end it or leave it open, and write further code beyond it or not: scary! ;)

--
If you can't understand the incipit, then please check the IPB Campaign.

That said, I think the exercise as a whole might stand a better chance of successful execution (and might even be more amusing) if the participation were more "modular".

Imagine that the goal of the exercise is to build a filter, comprising some finite (pre-established) number of steps, with each step implemented as a subroutine call that takes, say, one or two variable parameters (plus, if you like, one or more literal args), and returns something that can be used as input to a subsequent subroutine.

The first player gets to provide the data input operation, which could include some comment about the expected nature of the input (e.g. "list of English words, one per line"), or could be "self evident" (e.g.  @input = <*.txt>;). The first player could also provide the first filtering step (subroutine call).

Each successive player sees only the previous two lines (sub calls whose return values are assigned to variables), and must add the next filtering step, using one or both of the two variables set by the two visible steps from previous players (along with literal args, if desired).

Names of subs and variables should be "suggestive" (used to "good advantage" in the game, according to each player's understanding of "good"). At the very least, the variable name being assigned the return value from a sub should indicate the nature of the value (array_ref, hash_ref, or whatever).

Code for each subroutine must be provided by the player who adds that sub call to the sequence, and would be known only to the person who adds the sub call.

(A player could re-invoke one of the two subs visible to him/her, providing different input args, but this would usually be considered bad form (i.e. lame), and might run the risk of causing "undefined behavior" -- or a crash -- since that sub's internals are known only to the previous player who first put it in.)

I think games of this sort typically involve two or more rotations, and as many distinct compositions as there are players -- e.g. if there are 6 players, the game begins with each person supplying an input line and an initial sub of their own invention. Each script then rotates around the group, and eventually comes back to the player who started it. If the players are reasonably sober, they might be aware of the point where they are adding to a script that they started, though they might not remember exactly how they started it, and in any case, they don't know what happened to the data during four intervening steps (they only see the lines added by the previous two players).

That said, I think I would respectfully decline the opportunity to play. Just about all my "idle amusement" time (meager amount that it is) is spent on sudokus, crosswords, and SoPW. (Now that I think of it, timing issues might turn out to be a problem in this game...)

Update: Naturally, in the process of adding a given statement to the filter sequence, a player is not constrained to merely assigning the return value of a sub to a variable; any single-line flow control mechanism is fair game, along with using perl built-ins, logical operators/conjunctions, etc, but again, if the player doesn't actually include a sub call of his own (to hide some code from the next players), this could be viewed as a cop-out.

Dude, I fear that you must have way too much free time on your hands...

Read more... (2 kB)

Now, back to the actual game: it was in fact just an idea. The single word that's been stressed more in replies is "useful" which I think to be an error and a wrong POV to start with. Golf and Obfu are focused on writing programs that do something useful for some definition of "useful" and the interesting part is to see how they accomplish that. Here, the relationship is quite the opposite: the game, which is admittedly much less interesting, is about doing something, in surreal way: but have you ever heard about something surreal being useful? Except for the intellectual pleasure of seeing it existence by itself? Indeed a large part of the latter is about seeing if the game is feasible at all.

To make a comparison, if you stick with the "standard" graphical version of Exquisite Corpse, players could arrange things so that necessarily the end result is a human figure: just with pieces drawn by different individuals with different styles. But in the spirit of the game, it "works well" when what you get is... well, say a human head sticking out of a boot with flames surrounding it. Or something similarly weird. I would say that as with bizarro, although the latter is a much more recent genre, the main interest should be weirdness itself. As far as I'm concerned, I think there should not be any "goal of the exercise" but doing the exercise per se.

Of course, a big issue, which is also a cause of concern to the other monk who replied to me is to make the overall script work at all both in the sense that it must compile and not fail at runtime: (but the latter is much a minor problem, considering that we know we couldn't do anything for it even if we were writing "seriously...") after all there's not stated rule thus far prohibiting me from having a while (1) { ... } loop in the hidden part of my portion of the program. Your considerations are certainly useful in this sense, but I still regard them as far too restrictive wrt the spirit of the game as I interpret it, although just not as much as that other poster's. Thank you for the time you contributed thinkering about this crazy idea of mine!

--
If you can't understand the incipit, then please check the IPB Campaign.

I'll play

[duelafn ~]$ wc corpse-2.pl 
  7  35 212 corpse-2.pl
[duelafn ~]$ md5sum corpse-2.pl 
4e92ccfcbfc69686bb1687824efc0733  corpse-2.pl
[duelafn ~]$ tail -n2 corpse-2.pl
say $c;
my %h = (split /\s+/, $c);
[download]

One open curlie.

Update Fri Nov 21 13:23:15 EST 2008: Well, this is code, we don't really read linearly so I'll give you a line in the middle this time.

[duelafn]$ wc corpse-4.pl
  9  32 187 corpse-4.pl
[duelafn]$ md5sum corpse-4.pl
054c44f5cb2460eae1b1107ae31fd6e9  corpse-4.pl
[duelafn]$ tail -n4 corpse-4.pl | head -n1
  burn($fat);
[download]

No open curlies.

I personally believe I should thank you for taking part to the experiment: if nobody else joins say within tomorrow morning, I'll propose the next step myself, if you like, as an update to this very post. Then I'd go as far as corpse-6.pl and see which kind of "twitching mass of random code" got out of it!

Update: [Fri Nov 21 15:56:53 2008] here it is, and sorry for the minimality, but aqs you can see I've been procrastinating so much that I was beginning to think I wouldn't have done it any more if not so. Still, I think something moderately interesting may get out of it. I hope that the names of the variables are either illuminating or... pleasantly misleading enough! ;)

C:\temp>wc corpse-3.pl
      6      23     142 corpse-3.pl

C:\temp>md5sum corpse-3.pl
773de225d9053be5e311d9a4ed54bc43 *corpse-3.pl

C:\temp>tail -n2 corpse-3.pl
    $c = trim("@tmp", $lastlen) or last;
}
[download]

No open curlies!

--
If you can't understand the incipit, then please check the IPB Campaign.

Sounds good. Though, pretending that we don't know what happened in the n-2 chunk will be somewhat hard. Hopefully we find some other adventurous souls.

Good Day,
    Dean

Blazar, I know you know that, confused why you cited it.

I personally believe I did it for completeness, and to prevent some smart guy from popping up and pointing out the circumstance: I acted in advance.

--
If you can't understand the incipit, then please check the IPB Campaign.