" Pura programmazione funzionale" nella sua definizione formale riguarda l'idea di progettare macchine computazionali il cui output è puramente "una funzione dell'input alla macchina" . Se si alimenta lo stesso input nella macchina, produrrà lo stesso output. Ogni input è chiamato esplicitamente in modo da sapere esattamente quali sono le dipendenze. Un linguaggio di programmazione funzionale puro lo impone rigorosamente.
Eppure ... nella baseline "Rebol" puoi scrivere cose come:
foo: function [value [integer!]] [
either now/date = 20-Feb-2013 [
value + 1
] [
value
]
]
Qui vediamo una funzione che restituisce il suo input intero ogni giorno ma oggi, dove ottieni il valore più uno. Include una dipendenza invisibile dalla data che non è specificata formalmente come argomento della funzione. È il genere di cose che fa sì che le persone e i formalisti software di Haskell come me urlino un sanguinoso omicidio.
Quindi Rebol non è un prodotto funzionale pronto all'uso . (... ma continua a leggere ...)
La definizione meno rigorosa di programmazione funzionale è quando le funzioni possono agire come valori nel linguaggio. Quindi puoi assegnare una funzione a una variabile e usarla in seguito. In questo senso, puoi leggere come javascript è un linguaggio funzionale e vedere che la definizione rischiosa porterebbe alcune persone a dire che Javascript è un linguaggio funzionale. Se stai per essere così libero con la definizione, questo sarebbe "funzionale":
>> foo: does [a + 10]
>> a: 20
>> print foo
== 30
(Nota: DOES è una comodità per definire una funzione senza argomenti, che ha solo un corpo.)
Non so che lo prenderei in considerazione (o JavaScript) per adattarsi a ciò che le persone con cui parlo chiamerebbero programmazione funzionale. YMMV.
Se passi del tempo in informatica, scopri cose come Taring di Turing, la calcolabilità e questo tipo di principi di equivalenza in cui "se riesci a connettere X a Y, allora Z sarà vero". E proprio come puoi scrivere un'implementazione di Haskell in C, e quindi limitarti a usare solo le chiamate C mappate nella libreria di Haskell, potresti affermare che stai facendo "programmazione funzionale" ed essere tecnicamente corretto.
Quindi, se volessi dire che Rebol può essere piegato a stili di programmazione funzionale, potresti essere un pessimista e dire "beh, non è meglio che fingere di fare C quando in realtà stai usando un sottoinsieme così limitato del linguaggio che" riutilizzando Haskell per procura " . Il trucco della manica di Rebol è la facilità con cui scivoli da un paradigma "dialettale" a un altro. Scrivere un piccolo linguaggio specifico per un dominio che sembra essere funzionale è così facile e naturale che non sembra che tu stia distorcendo la tua lingua per farlo. La capacità di rendere linguaggi specifici di dominio che hanno carattere funzionale porta all'etichettatura di Rebol come "paradigma neutrale" .
Molte persone mescolano Rebol con il suo dialetto più comune (il dialetto DO) e pensano "questo è Rebol". Ma l '"essenza" di Rebol è più simile all'XML, è un formato di scambio di dati che per coincidenza (va bene, non a caso) ha un codice iper-ottimizzato che si concentra sull'elaborarlo in alcuni modi fuori dagli schemi. Per una buona lettura di base su come battere i pantaloni dall'XML, vedi Was XML imperfetto dalla fama Start di Carl Sassenrath di AmigaOS (e ora Rebol).