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

RIP ifs-for-whomever

 [1/2] 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
<<quoted lines omitted: 6>>
> 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
<<quoted lines omitted: 3>>
>> 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-

 [2/2] from: vhirsch:metrohealth at: 13-Oct-2000 11:00


To Joel, Thank you for another interesting essay. For a self-described Bear of Small Brain you write well in both English and in REBOL.. I've enjoyed almost all of your thoughtful postings even when I wasn't able to follow the REBOLish details. Thanks also for mentioning Richard Gabriel. His "Patterns of Software" sat unread on my shelf for two years until you mentioned him earlier this week. Now I wish I'd picked it up sooner. Can you explain what you mean by "a von Neumann language"? Do you have a reference? I'm familiar with the notion of a von Neumann machine (von Neumann architecture, von Neumann model) but a google search for von Neumann language wasn't helpful. I assume you mean something more than a programming language which runs on a von Neumann machine since COBOL satisfies this description. Finally, what's EWD? Thanks again! Vic Hirsch
>>> <[joel--neely--fedex--com]> 10/13/00 09:52AM >>>
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-

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted