I've been reading this thread as a relative novice. Does it matter that
practically every Rebol statement returns a value that can be an argument
for a subsequent (chronologically, preceding in the line). I.e., functions
and assignments do "evaluate", rather than merely cause side effects.
>> a: b: 10
== 10
>> a
== 10
>> b
== 10
>>
b: 10 left a value for the a: assignment statement, rather than merely
having the side effect of setting b's value to 10.
No flames, please. I plead ignorance of computer science!
Russell [EMAIL PROTECTED]
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 19, 1999 5:55 PM
Subject: [REBOL] pros and cons. Re:
>
> Hey now, pilgrim. You can call me guru, or you can call
> me goof ball, but don't call me Sherman! ;-)
>
> > Triple howdy, and two pilgrims, O REBOL guru.
>
> [ . . . ]
>
> > Jeff said:
> > Your aim is to bash REBOL for it's lack of functional
> > purity, no? :-)
> >
> > Actually, no. I'm not bashing REBOL. If I'm bashing
> > anything, it is your description of REBOL as a functional
> > language (no personal insult intended).
>
>
> It seems to me that you could not, with out great
> difficulty, write the functional code that I provided in an
> imperative language. I strain to imagine how to do those in
> Java. The definition of "functional", as I read it, has a
> bit of slack, though your definition doesn't seem to. (:
>
> Does elisp meet your definition of "functional"? It sure
> has a lot of functions in it aimed at emacs-ee-tasks. I
> have a fair amount and have seen plenty of elisp code that
> reads as a sequence of COMMAND structures for control flow
> and data manipulation, to borrow your statement below.
>
> Speaking of elisp-- we've got a half complete REBOL emacs
> mode that was started by a nice bright fellow named Joe. It
> still gets the closing braces wrong and it chokes on curly
> braced strings, but it's done okay for us up till now. Wish
> someone could fix it up . . .
>
>
> > The point I'm trying to make is that REBOL *discourages*
> > functional programming because it provides numerous COMMAND
> > structures for control flow and data manipulation, and there
> > is a paucity of non-side effecting natives that can be
> > combined in EXPRESSIONS. This encourages an imperative
> > programming style much like BASIC where statements are
> > executed for their effect, rather than a functional style
> > where expressions are evaluated for their value. A quick
> > perusal of the script archive bears this out.
>
>
> Hmm.. you feel there are "too many imperative forms" in the
> language to be called functional. Okay, so what do you
> prefer it be called? Procedural?
>
> REBOL is a hybrid-- the message that you are bashing me for
> was just an attempt by me to give a friend of mine a quick
> and dirty run down of the many awesome features of REBOL.
>
>
> > While you can write functional natives in REBOL, as your
> > code so nicely shows, these functions are not built-in and
> > readily available: why build a screwdriver when you are
> > provided with a complete selection of hammers?
>
> How do you feel about REBOL's referential transparency?
>
> > Jeff said:
> > value? 'Hair-splitting == true
> >
> > No, if I were hair splitting I would point out the
> > following:
> >
> > 1. Your version of map, filter, and interleave bomb out
> > on very large blocks (size > 1500)
> >
> > 2. These versions consume memory like it is going out
> > of style. When I filter a block of 1000 items, the
> > memory usage of REBOL grows by almost 10K.
> >
> > 3. These versions seem to leak memory. Even after
> > calling recycle, the memory usage never quite gets
> > back to where it was. A long-running REBOL process
> > would cause problems.
>
> Submit a bug report, aye? :-)
>
> > Jeff said:
> > Can't please 'em all... )-:
> >
> > I don't want you to. Just me.
>
> How am I to please you? You seem harder to please than
> most, O nameless one.
>
> -jeff
>
