Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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: [
[ [ ] == [
>> mirror: append copy pick servers cyc "BugList.html"
>> mirror: append copy pick servers cyc "BugList.html"
>> mirror: append copy pick servers cyc "BugList.html"
>> mirror: append copy pick servers cyc "BugList.html"
>> mirror: append copy pick servers cyc "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-