La « programmation fonctionnelle pure » dans sa définition formelle concerne l'idée de concevoir des machines de calcul dont la sortie est purement «fonction de l'entrée de la machine» . Si vous introduisez la même entrée dans la machine, elle produira la même sortie. Chaque entrée est nommée explicitement afin que vous sachiez précisément quelles sont les dépendances. Un langage de programmation purement fonctionnel applique cela rigoureusement.
Pourtant ... dans la ligne de base "Rebol", vous pouvez écrire des choses comme:
foo: function [value [integer!]] [
either now/date = 20-Feb-2013 [
value + 1
] [
value
]
]
Ici, nous voyons une fonction qui renvoie son entrée entière tous les jours, mais aujourd'hui, où vous obtenez la valeur plus un. Il inclut une dépendance invisible à la date qui n'est pas formellement spécifiée comme argument de la fonction. C'est le genre de chose qui fait que les gens de Haskell et les formalistes des logiciels comme moi crient un meurtre sanglant.
Par conséquent, Rebol n'est pas purement fonctionnel hors de la boîte. (... mais lisez la suite ...)
La définition moins stricte de la programmation fonctionnelle est lorsque les fonctions peuvent agir comme des valeurs dans le langage. Vous pouvez donc affecter une fonction à une variable et l'utiliser plus tard. Dans ce sens, vous pouvez aller lire le javascript comme un langage fonctionnel et voir que la définition risquée conduirait certaines personnes à dire que Javascript est un langage fonctionnel. Si vous allez être aussi lâche avec la définition, ce serait "fonctionnel":
>> foo: does [a + 10]
>> a: 20
>> print foo
== 30
(Remarque: DOES est une commodité pour définir une fonction sans arguments, qui n'a qu'un corps.)
Je ne sais pas si je considérerais cela (ou JavaScript) pour s'adapter à ce que les gens à qui j'appellerais appelleraient de la programmation fonctionnelle. YMMV.
Si vous passez du temps en informatique, vous apprenez des choses comme Turing Tarpits et la calculabilité et ce genre de principes d'équivalences où "si vous pouvez connecter X à Y, alors Z sera vrai". Et tout comme vous pouvez écrire une implémentation Haskell en C, puis vous limiter à n'utiliser que des appels C mappés dans la bibliothèque Haskell, vous pourriez prétendre que vous faites de la "programmation fonctionnelle" et être techniquement correct.
Donc, si vous vouliez dire que Rebol peut être plié aux styles de programmation fonctionnels, vous pourriez être pessimiste et dire "eh bien, ce n'est pas mieux que de prétendre que vous faites du C lorsque vous utilisez réellement un sous-ensemble aussi restreint du langage que vous" en utilisant Haskell par proxy " . L'astuce dans la manche de Rebol est la facilité avec laquelle vous passez d'un paradigme de "dialecte" à un autre. Écrire un petit langage spécifique au domaine qui se trouve être fonctionnel est si facile et naturel qu'il ne semble pas que vous tordiez votre langage pour le faire. La possibilité de créer des langages spécifiques au domaine qui ont un caractère fonctionnel conduit à étiqueter Rebol comme "paradigme neutre" .
Beaucoup de gens confondent Rebol avec son dialecte le plus commun (le dialecte DO) et pensent "c'est ce que Rebol est". Mais "l'essence" de Rebol ressemble plus à XML, c'est un format d'échange de données qui, par coïncidence (d'accord, pas par coïncidence), a un code hyper-optimisé se concentrant sur le traitement de certaines façons hors de la boîte. Pour une bonne lecture de fond sur la façon dont il bat le pantalon hors XML, voir Was XML a été vicié dès le début par Carl Sassenrath de la renommée d'AmigaOS (et maintenant Rebol).