[REBOL] RIP ifs-for-whomever
From: joel::neely::fedex::com at: 13-Oct-2000 8:52
Hello to Ladislav, Gabriele, and list...
[lmecir--geocities--com] wrote:
> Well, the problem is, that you are trying to disobey the KISS rule.
> That rule means, that your signed-if-for-dummies should do one
> thing and do it well. I think, that it should execute the properly
> chosen block. It shoudn't try to evaluate its first argument at any
> price, because supplying it is a work for the caller IMO. I am
> pretty sure, that the code is much more "brittle" and cryptic, than
> the proper solution, which should work for useful first argument
> values and not for any garbage. E.g. your solution has the worst
> possible property of any algorithm: there are some inputs, for
> which the algorithm doesn't stop.
>
[giesse--dsiaq1--ing--univaq--it] wrote:
> After all, what's the point in passing code to it? You are
> evaluating it once anyway (else it won't work), so you can simply
> evaluate it before passing. Let's Keep It Simple!
>
Clearly I should apologize for pushing this little experiment far
beyond the interest of anyone but myself.
Thanks for all the participation and patience!
There was a point to my madness, but anyone who's tired of this
thread is welcome to take the above apology and ignore the essay
which follows.
-jn-
REBOL definitely offers expressive power far beyond the reach of
most of the current crop of programming languages, and I find it
interesting to see just how far that can go.
For instance,
>> cyc: to-paren [change back tail :cyc (last :cyc) // 5 + 1 0]
== (change back tail :cyc (last :cyc) // 5 + 1 0)
>> cyc == 1
>> cyc == 2
>> cyc == 3
>> cyc == 4
>> cyc == 5
>> cyc == 1
>> cyc == 2
provides an interesting, compact way to cycle through a set of values
without the overhead of creating an entire object just to maintain
the state. I can imagine using this, for example, to balance the use
of resources in a larger system, as in
>> servers: [http://www.rebol.com/
http://www.rebol.org/
[ http://www.fee.com/ http://www.fie.com/
[ http://www.foe.com/ ]
== [http://www.rebol.com/
http://www.rebol.org/...
>> mirror: append copy pick servers cyc "BugList.html"
== http://www.fee.com/BugList.html
>> mirror: append copy pick servers cyc "BugList.html"
== http://www.fie.com/BugList.html
>> mirror: append copy pick servers cyc "BugList.html"
== http://www.foe.com/BugList.html
>> mirror: append copy pick servers cyc "BugList.html"
== http://www.rebol.com/BugList.html
>> mirror: append copy pick servers cyc "BugList.html"
==
http://www.rebol.org/BugList.html
And, in order for the load to be truly balanced, I can imagine a
need to pass :CYC (as opposed to CYC) around fairly freely.
So, I began to wonder how one might handle such monsters without
getting bitten.
Poor IFS happened to be the guinea pig that I fed to that monster.
(And the case-in-point for the question about using "local objects"
as a way to simulate named parameters for a function.) I would
hope to have better sense than to propose any of the increasingly
contorted IFS-FOR-whatever definitions as a general-purpose
control construct. (Although Bears of Small Brain do occasionally
take flights of fancy with VERY loose connection to common
sense! ;-)
However, again, my apologies to anyone whom I've offended/annoyed/
bored/whatever with my unclearly-explained stress tests.
Ladislav did raise an important issue, to which I feel motivated
to respond...
[lmecir--geocities--com] wrote:
> ... your solution has the worst possible property of any
> algorithm: there are some inputs, for which the algorithm
> doesn't stop.
>
As an avid reader of EWD, I assure you that I consider termination
to be a crucial part of algorithm correctness. (I toyed with adding
an additional argument to UNRAVEL as a bound on the number of
iterations before UNRAVEL would give up on an argument as being too
knotted to unravel. I chose, perhaps unwisely, not to include that
in the open discussion, thinking that it would complicate things
too much.)
However, your concern will apply WHENEVER we attempt to define new
control structures or higher-order functions! DO, REDUCE, WHILE,
and even the lowly IF all have the property that I can hand them
arguments whose evaluations fail to terminate. If, for example,
a function such as MAP (per earlier discussion on this list) gives
me the privelege of handing it an arbitrary chunk of code to be
executed under its control, then it simultaneously imposes on me
the responsibility of dealing with the termination of that code.
I know no way around this.
And (if I may have your ear just a moment longer...) there is a
negative historical precedent which is quite fascinating (to me,
at least).
The publication of Benoit Mandelbrot's _The_Fractal_Geometry_of_
_Nature_ (copyright 1977) was a great shock to many people
(including, unfortunately, some mathematicians) who perceived
the ideas (and pictures!) of that book to be an entirely new way
of looking at the world. Subsequently there has been a flurry of
excitement and activity regarding how fractal formulae and
thinking can give us powerful new models with which to work.
HOWEVER... in the introduction, Mandelbrot himself dates the
roots of fractal geometry to 1875, over a century earlier!
Why then did so many (including scientists and mathematicians)
perceive fractal geometry to be so startlingly new?
Because the mathematical establishment had dismissed earlier
investigations into "monstrousities" (such as the continuous,
non-differentiable function reported in 1875) as frivolous or
wrong-headed. My point here is not about the individuals
involved (then or now, including members of this list!), but
about how ideas become mainstreamed or marginalized.
Fractal geometry "took off" only after some really hard work to
show interesting and useful applications. Since then, a number
of powerful techniques for mastering the apparent complexity
(and detecting it in otherwise simple-looking formulae) have
been developed and put to use.
REBOL (as a von Neumann language in the company of Lisp, PROLOG,
etc.) gives us the ability to indulge in what I'll call "logical
fractals" whose behavior is *SEVERELY* unobvious if we aren't
aware of what we're getting into. Now, please hold that thought
for a moment, while I draw in one other connection...
In an essay (the ninth chapter of his book _Patterns_of_Software_,
Rich Gabriel suggests four characteristics which a programming
language must have to survive:
* Languages are accepted and evolve by a social process,
not a technical or technological one.
* Successful languages must have modest or minimal
computer resource requirements.
* Successful languages must have a simple performance
model.
* Successful languages must not require users [to] have
"mathematical sophistication."
REBOL succeeds admirably on #2, and we're all working on #1 via
this mailing list.
#3 is more problematic. I've never seen an "official" model of
REBOL semantics, but throughout my involvement with it I've
been trying to come up with pieces of one (e.g., my earlier
essays on SERIES! values). I still believe that there are many
parts of REBOL that could be explained precisely and simply,
but others that are not so clear. (Either in my poor head or
in fact -- witness the differences in behavior when mutations
are applied to BLOCK! versus LIST! values.)
#4 is the most "dangerous" to REBOL, in that *EVERY* vNL of
which I'm aware -- REBOL included -- requires at some point a
fair bit of sophistication to understand, or at least to
recognize when one is getting into deep waters.
TYING IT ALL TOGETHER (at last!)
I suspect that what we (computing folk in general) need before
vNL languages in general -- and REBOL in particular -- will be
widely accepted is the beginnings of a real grasp on "logical
fractals" that let us use their power effectively and (mostly)
safely. Of course, one approach is to say "Don't do that at
all!" If I take that approach, I begin to wonder why I don't
just stick to COBOL!
OTOH, if I can begin to get a grip on when and how to use such
monsters
as:
* mezzanine-level control constructs,
* higher-order functions,
* self-modifying, stateful values,
* ...etc...
I may be able to take advantage of REBOL's power -- using it
more effectively -- and be able to explain/communicate its
benefits more persuasively -- promoting its success more
effectively.
To that end, I'm profoundly grateful to the members of this
list for their challenges, discussions, and inspiration!
-jn-
