On Dec 8, 2010, at 2:10 PM, Haswell, Joe wrote: > Coming from a Haskell background, I really miss non-strict semantics in Java, > and it seems that functor's support for them is fairly limited (I do note > that it exists). It'd be fairly easy to implement them either over existing > functor interfaces or as a separate package. > > Also, it seems that there could be expanded support for built-in functions > (scans, filters, maps, grouping, etc.) . I think these could be implemented > naturally making use of just the standard Java Iterable<> interface > > > For example, I've implemented a fairly simple infrastructure that allows you > to write code like: > > > Iterable<BigInteger> allTheFactorials = scanl( > BigInteger.ONE, > BigInt.multiply, > unfold(BigInt.N()) > ); > List<BigInteger> first30 = strict(take(30, allTheFactorials), new > LinkedList<BigInteger>()); > System.out.println(join(first10, "\n")); > > And am wondering if this sort of thing might be a useful addition to the > library. >
Hi, Joe--I have modified the subject line of your original mail to align with the preferred means of categorizing threads on the (shared) Commons lists. [functor] hasn't seen a lot of love over the course of its existence, and I'm not sure how deeply indoctrinated in FP those of us who still care about it are. That said, [functor] is, in my experience, wide open to compatible-in-spirit Java-based implementations of common FP algorithms, which would seem to be an apt categorization based on my reading of your proposal. In [functor]'s existing structure, each of the functions you've shown above would typically be implemented as a separate functor or provided in an "algorithm" class in the case that none of the existing, basic Nullary|Unary|Binary-Functor interfaces would apply. Contributions are welcome, although a contribution exceeding an arbitrary measure of "bigness" is best brought through the Apache Incubator. Smallish contributions can be submitted as JIRA tasks with attachments granted permission for inclusion through the UI, though in either case I would urge you to include, for the sake of your audience, a summary of what functions are being submitted, so that their functionality can be checked against available definitions of the function in FP circles. HTH, Matt > Joe H. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
