Recalling that my argument is
1. A functional language encourages functional programming, a
procedural language encourages imperative programming. (as per
the functional language FAQ)
2. REBOL encourages a procedural/imperative style of programming.
(as evidenced by the examples and the script library)
3. Therefore REBOL would be better described as a procedural
language rather than a functional language.
Jeff said:
The constraints to earn your
"Functional" certification seem exceedingly daunting. It
would seem Lambda Calculus itself would barely merit your
designation.
Not at all. Except for toy languages, `functional' languages have
imperative operations. They are necessary for I/O, and frequently
useful for performance reasons. The mere presence of imperative forms
doesn't mean the language is imperative, no more than the presence
of functional forms means the language is functional.
Jeff said:
REBOL is a first class functional language (with a good deal of
support for proceedural style programming).
I don't know what you mean by `1st class'. Is it a technical term
or an opinion? I would say that REBOL is a procedural language
that can support some `functional' programming.
If you disagree with this assessment, show me how REBOL encourages a
functional style of programming. I simply don't see it in the
example code or the script library.
Elan said:
Perhaps REBOL - like Haskell - supports a "new style of functional
programming called monadic programming."
I see no evidence of monads in REBOL. Monads are essentially a
kludge to allow you to use imperative functions in a strictly
functional language. They rely on the idea that you can model state
by `reifying the world', then noting that if you serialize access to
the `world', you need not address the problems of undoing state
transitions. Essentially, a monad is a `read once' kind of object.
The side-effecting natives in REBOL seem to be the mundane ones that
you would expect to find in any language that supports imperative
operations.
Elan said:
Erlang, a language whose designers confess to having
avoided "many features commonly found in modern functional
languages", should not be considered as protoype for functional
languages.
Ok.
Elan said:
With catch and throw (see Erlang op. cit. chapter 7/7.1) -
amongst other mechanisms - Erlang contains some of those
language constructs you quote as an objection to Jeff's
statement that REBOL is a functional language.
I'm not saying that the mere presence of catch and throw disqualify
REBOL as a functional language. Jeff asserted that
`throw' (and `break' and `return') "do NOT produce side effects, to
their operands or the interpreter at large", and "REBOL ... is
strongly biased towards non side effect producing expressions."
I claim that these control-flow constructs are not functional.
Recall that one property of a function is that it returns the same
value given the same inputs. THROW, BREAK, and RETURN don't even
return values to the containing expression!
Nonetheless, I am willing to concede that REBOL has a larger
number of `functional' natives than `procedural' ones. However,
the static count of `functional' natives is meaningless. It is how
REBOL is used in actual programs that is an indication of whether
REBOL is more `functional' or `procedural'. The REBOL examples
and scripts, on rebol.com and rebol.org, make heavy use of
assignment, printing, appending, inserting, copying, and deleting.
My point is not that REBOL cannot be used for functional programming.
Nor is it that functional programming languages cannot have
imperative operations. My point is that describing REBOL as
a `functional' language is disingenuous because, although it can
support `functional' programming, it encourages an `imperative'
style. The vast amount of `imperative' code present in the examples
and the script library are evidence of this bias.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
