http://qs321.pair.com?node_id=723342


in reply to [Fun] Exquisite Corpse in Perl?

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

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.

Replies are listed 'Best First'.
Re^2: [Fun] Exquisite Corpse in Perl?
by blazar (Canon) on Nov 13, 2008 at 11:52 UTC
    Dude, I fear that you must have way too much free time on your hands...

    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.