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
