Ik vind dat overigens dat juist het RAII voorbeeld de ‘veel complexer geworden’ Java-syntax rechtvaardigt; terwijl de syntax niet echt veel complexer wordt… ben benieuwd naar het vervolg!

Moest het wel even 2 keer lezen om het mijzelf eigen te maken.
Ik ga het binnenkort is uitproberen…

in jouw voorbeeld code is het probleem al te zien.

private static List map (List bronlijst, {X => Y} functie) {
List doellijst = new ArrayList (bronlijst.size ());

Het probleem zit ‘m in de new ArrayList. FP gaat om lazy evaluation en dat ondersteunt java niet doordat de zoals in .Net bekende Yield ontbreekt. Het komt erop neer dat de volledige lijst meteen greedy uitgerekend moet worden. En gezien elke FP functie met een lijst operatie een nieuwe lijst (of 1 enkel element) dient op te leveren betekent dat dus dat de orginele lijst niet aangepast mag worden.
Zie de map bijvoorbeeld. Alle elementen van de argument lijst worden omgerekend en in een resultaat lijst gezet. Deze resultaatlijst moet gemaakt worden, in dit geval wordt dit dus een Arraylist.

en dat is dus niet goed.

stel we hebben een lijst representatie die intern als een tree is geimplementeerd, of er gelden ordeningen, filteringe and whatnot in ons EIGEN lijst implementatie. Vervolgens gooien we deze lijst als argument in de Map functie. het resultaat is dan een Arraylist…. er gaat een Type A in en er komt een Arraylist uit. Het interne gedrag van de lijst en diens eigenschappen gaan verloren door het aanroepen van de map methode.
Het is ook verstandiger om niet List als argument te geven omdat alles wat een lijst vorm heeft (dus (x:xs)

alles wat dus itereerbaar. Enumerble of Iterable. het dient ook meteen voor arrays te werken. alles wat voldoet aan de eigenschap (x:xs). Hoe dan ook dient het return type hetzelde type te zijn als het argument type.

Kernmerk van een closure is dat het een operatie is zonder side effects. het doet 1 ding en niet meer dan dat. En met het list type probleem is er dus een side effect, de closure is dus niet puur.

Overigens zijn closures prima te maken in vrijwel elke object oriented taal. Het is enkel het “liften” van een operatie naar een class. In haskell kan je functies als argumenten aan een ander functie geven. In java kan dat niet. Je kan niet ‘+’ of ‘Math.abs(x)’ meegeven aan een andere functie (behalve met reflectie).

public interface Func{
public O eval(I input);
}

public static Iterable map(Func f, Iterable xs){
Iterable result = new ArrayList(); //

public interface Func{
public O eval(I input);
}

public static Iterable map(Func f, Iterable xs){
Iterable result = new ArrayList(); // filter(Func f, Iterable xs){
Iterable result = new ArrayList(); // even = new Func(){
public Boolean eval(Integer input){
return input % 2 == 0;
}
}

List result = map(even, Arrays.asList(1… 100);

Ik ben het niet met je eens dat een closure geen neveneffecten zou mogen hebben - soms is het juist de bedoeling om een lokale variabele van waarde te doen veranderen. Dit gaat ook ondersteund worden in de BGGA-implementatie (maar werkte nog niet toen ik dit artikel schreef).

Het is waar dat het eenvoudig is functors te schrijven (zie bijvoorbeeld Commons Functor of FunctionalJ), maar dat wil nog niet zeggen dat een taaluitbreiding met dit doel overbodig is. Maar meer daarover in het vervolgartikel.