[EMAIL PROTECTED] wrote:
>
> ... I'm going to have to play with them a bit before I can tell
> whether I'll want to use them regularly, but the ideas behind
> them are definitely worth pondering.
>
Although I've used them quite a bit in algorithm design, I certainly
want a much richer set of control structures myself, and find the
idea that we can define new ones as needed a VERY attractive aspect
of REBOL.
Dijkstra was originally going for a minimal set of structures that
would allow program proof, rather than trying to define all the
features that would make for a complete, convenient language. For
example, I'm quite partial to foreach , and would really hate to
give it up.
OTOH, it's kind of like writing sonnets or haiku -- sometimes it is
very enlightening to see how much you can get done with the fewest
parts, simplest tools, or tightest restrictions.
>
> Just a thought, but EWD/DO might be useful as a control structure
> for servers - waiting for input and responding to it each time in a
> non-deterministic way, to keep the clients interested. I think it
> could be used in this way as-is, by sandwiching a wait-for-input
> instruction into the first condition with ALL, but perhaps it would
> be nicer to have a more explicit way to do this.
>
Interesting idea!
Another practical application of ewd/do is in the loop-and-switch
pattern that shows up in interpreters, state machines, and formerly
unstructured code that has been "structurefied" by brute force:
while any [case = 'first case = 'second case = 'third ...] [
switch case [
'first [...]
'second [...]
'third [...]
...
]
]
just seems a bit tedious compared with
ewd/do [
case = 'first [...]
case = 'second [...]
case = 'third [...]
...
]
(and avoids the need to duplicate the guards , which helps with the
long-term maintenance).
>
> Also, just for the sake of a little more non-determinism it would
> be nice to have _REDUCE evaluate the conditions themselves in a
> random order, but I don't think DO/NEXT would be quite up to the job.
>
Fortunately, the ordering of conditions doesn't affect the outcome,
unless the conditions involve expressions with side-effects (and
none of us would *ever* do that, right? ;-)
>
> I've played around a little more with Ladislav's PIF to get it more
> to my liking. It doesn't go beyond C-style if ... else if ... else,
> but at least it's more flexible than SWITCH and easier to read than
> nested EITHERs. Doubt this will be of use to you - it succumbs to
> the "fall through the default" temptation ...
>
Actually, I've been wishing for a long time for a language in which
I could conveniently experiment with the effectiveness, readability,
etc. of a variety of control structures. And then along came REBOL!
loop 3 [send [EMAIL PROTECTED] "Hip, hip, hooray!"]
Given a collection of guard/command pairs, there are quite a few ways
to do something interesting with them:
1) Find the first true guard, evaluate the corresponding command,
and consider yourself done. This is essentially what 'pif and
the old 'cond structure from LISP are doing.
2) Evaluate an arbitrary command whose guard is true. This is
what ewd/if does.
3) Evaluate an arbitrary command whose guard is true, and keep
doing so as long as at least one guard is true. This is what
ewd/do does.
4) Make one pass through the list, evaluating all commands whose
guards are true. This is equivalent (but slightly more compact
and formal) to a series of consecutive if expressions.
5) Do #4 repeatedly until no guards are true. I don't recall seeing
(or reading about) this one in any language, but it's obviously
equivalent to the consecutive if expressions wrapped in a
while whose control expression is any [...of the if guards...]
(but, as mentioned earlier, has the advantage that each guard
only has to be written in one place -- next to its command).
6) Evaluate an arbitrary command whose guard is true. Then remove
that guard/command pair from the list and try again. Continue
until no guards are true (which happens -- at the latest -- when
all guard/command pairs have been removed). I played with this
one with paper and pencil a few years ago. This generalizes the
on the idea that actions can safely be performed concurrently if
they could be performed sequentially but in an arbitrary order.
Of course, the real questions are, "What other possibilities are
there?" and "When -- if at all -- does each of these become a handy
thing to have in the toolkit?"
For example, foreach nicely manages all of the tedium of walking
through a series. Are there other such cases? What if (thinking of
the result from parse-xml ) we had a control word that could walk
through a tree made out of blocks?
Any more ideas from anyone?
-jn-
