On Fri, 6 Jun 2003 15:25:04 +0900 John Carter <john.carter / tait.co.nz> wrote: > On Fri, 2003-06-06 at 17:13, Ryan Pavlik wrote: > > and that any > > language with goto is pure evil. > > Now for your next trick... A "come from". > > No, wait, we've got that already. > > It's called the Observer pattern. <snip> Actually, COME FROM isn't equivalent to Observer, as the former is an assertion as to flow control, requiring the current statement to have been reached from the specified line or label. It acts as a "trapdoor", _causing_ code to be reached from the given line or label with no visible interaction at the specified origin. An Observer, on the other hand (and especially in a hand which happens to be writing Ruby), does not require a particular unique origin (an observer may observe multiple things) or provide an invisible trapdoor. Unfortunately, Ruby seems to lack important features that could be used to implement COME FROM, at least without heavy use of eval(). These features include (but are not limited to) the following: * Code preevaluation. If ruby code was evaluated, and the result of this evaluation able to in turn be evaluated before execution, one could search for COME FROM statements and set up the proper execution path. * Dry run. If ruby code could first be run without effect, thus triggering COME FROM statements, allowing them to be recorded, they could be implemented without much trouble. * Reverse execution. If ruby code could be evaluated, and then run backwards from finish to start, the given "goto" package would, effectively, be COME FROM, as the last code would be executed first, followed by the call to the actual GOTO. Proper aliasing of "goto" to "come_from", a feature already supported by ruby, would ensure proper semantic aesthetics. With this feature, one could simply write his or her ruby code backwards, except for aliased gotos. As you can see, this analysis of COME FROM vs Observer, and the features required to implement it, show that I have far too much free time. This should be remedied by an upcoming "time" module, which will allow ruby threads to have been executed at a given time. I just need a few things added to Ruby first... -- Ryan Pavlik <rpav / users.sf.net> "It's like I'm at least *twice* as evil as I used to be!" - 8BT