"Pure Functional Programming" in its formal definition is about the idea of designing computational machines whose output is purely "a function of the input to the machine". If you feed the same input into the machine, it will produce the same output. Each input is named explicitly so you know precisely what the dependencies are. A pure functional programming language enforces this rigorously.
Yet... in baseline "Rebol" you can write things like:
foo: function [value [integer!]] [
either now/date = 20-Feb-2013 [
value + 1
] [
value
]
]
Here we see a function that returns its integer input on every day but today, where you get the value plus one. It includes an invisible dependency on the date which is not formally specified as an argument to the function. It's the sort of thing that makes Haskell people and software formalists like myself scream bloody murder.
Hence Rebol is not pure functional out of the box. (...but read on...)
The less strict definition of functional programming is when functions can act as values in the language. So you can assign a function to a variable, and use it later. In that sense, you can go read the likes of is javascript a functional language and see that the dicey definition would lead some people to say Javascript is a functional language. If you're going to be that loose with the definition then this would be "functional":
>> foo: does [a + 10]
>> a: 20
>> print foo
== 30
(Note: DOES is a convenience for defining a function with no arguments, that has only a body.)
I don't know that I'd consider that (or JavaScript) to fit what people I talk to would call functional programming. YMMV.
If you spend any time in computer science you learn about things like Turing Tarpits and computability and these sort of principles of equivalences where "if you can connect X to Y then Z will be true". And just as you can write a Haskell implementation in C, and then restrict yourself to only using C calls mapped into the Haskell library, you might claim you're doing "functional programming" and be technically correct.
So if you wanted to say Rebol can be bent to functional programming styles, you might be a pessimist and say "well it's no better than pretending you're doing C when you're actually using such a confined subset of the language that you're using Haskell by proxy". The trick up Rebol's sleeve is how easily you slip from one "dialecting" paradigm to another. Writing a little domain-specific-language that happens to be functional is so easy and natural that it doesn't feel like you're twisting your language out of joint to do it. The ability to make domain specific languages that have functional character leads to the labeling of Rebol as "paradigm neutral".
Many people mix up Rebol with its most common dialect (the DO dialect) and think "that's what Rebol is". But Rebol's "essence" is more like XML, it's a data exchange format that coincidentally (okay, not coincidentally) has hyper-optimized code focusing on processing it in some certain ways out of the box. For a good background reading on how it beats the pants off XML, see Was XML flawed from the Start by Carl Sassenrath of AmigaOS (and now Rebol) fame.
