Re: ANN: ruby-goto, your evil for the evening

On Fri, 6 Jun 2003 15:25:04 +0900
John Carter <[e-mail]> 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 <[e-mail]>

"It's like I'm at least *twice* as evil as I used to be!" - 8BT