Jeff made a list of the `functional' and `side-effecting' procedures
in REBOL. I disagree with his assessment on a number of the
procedures:
1. Commands such as recycle and trace, return no value,
and are called solely for effect.
2. Copiers have an important `side effect' on the memory:
a copier is *never* allowed to return the same value twice.
3. Control flow natives such as all, any, break, catch, exit,
halt, quit, etc. etc. can't easily be lumped into the
`functional' category.
4. i/o commands such as about ask confirm help echo licence
load read write open source what etc. etc. etc. Clearly
side effect the console.
5. Procedures such as dir? exists? get now query size? etc.
measure external state and are thus not `functional'
But I don't want to get into a pissing contest with Jeff. I'll
concede that REBOL, as shipped, has about half-again as many
`functional' natives as `side-effecting' ones.
But the static count of the number of natives that don't modify
their arguments has little to do with whether the language is
procedural or functional. The point I was trying to make is that
the large majority of scripts people write in REBOL are procedural
in style rather than functional. The control-flow natives,
the emphasis on using blocks as the primary data structure, the
powerful procedural natives APPEND, CHANGE, INSERT, REMOVE, etc.
and the lack of efficient, non-destructive natives encourage users
to program in a procedural style.
Am I wrong? Perhaps REBOL does encourage a `functional' programming
style but all the people who submit scripts stubbornly refuse to
adhere to the `natural' style of REBOL. Or perhaps REBOL is closer
to classic procedural languages such as Pascal and Basic, than
it is to classic `functional' languages such as Erlang, Haskell.
John
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
