crowdhailer / fn.js Goto Github PK

Proposal

Currently

A JavaScript library built to encourage a functional programming style & strategy

Proposed change

A library for manipulating first class functions in JavaScript.

Rational

There are several pieces that need to come together to encourage functional programming. These include some of the following.

1. Map, filter & reduce on collections.
2. Immutable data structures.
3. controlled side effects.
4. working with first class functions.

fn.js Does not try to tackle points 2 or 3 and nor should it. At the moment it tries to solve some of point 1 and all of point 4. fn.js does not tackle point 1 as well as alternatives, it is missing functionality like head, fist, last, tail, union, zip etc.

This proposal is to have fn.js NOT tackle point 1 and focus solely providing utilities for manipulating functions(i.e. point 4).

Repercussions

• fn.js drops functions such as each, and reduce (except where the make sense as a utility for the core functions)
• fn.js assumes es5 and uses reduce and map that are available on the array prototypes
• fn.js standardises method signatures. #25
  • fn always as last argument
  • takes a collection of functions

fn.somFunc(param, func) // => newFunc
// e.g. 
fn.throttle(100, myFunc) // => newFunc

fn.otherFunc([collection, of, function])  // => newFunc
// e.g.
fn.compose([myFunc, myOtherFunc]) // => newFunc

• fn.js functions are curried by default as in issue #20

the example for fn.delayFor is below;

fn.delay( 500, function () {
console.log( 'Aliens...' );
});

it should be;

fn.delayFor( 500, function () {
console.log( 'Aliens...' );
});

Current .is() API:

fn.is( value, type ) where type is a string type returned by fn.type. Having the value come before the type means you cannot create a version with the type partially applied. If the API were:

fn.is( type, value )

then you could do:

var isFunction = fn.partial( fn.is, 'function' );

This would be a breaking API change, so I want to open for discussion before making changes if anyone has any objections.

Currently fn.throttle and fn.debounce invoke their handlers after the timer. Make it so this can be configured via options similar to other libraries.

I was wondering if you'd consider changing the signature of the concat method to take an array of arrays which would match Haskell and Underscore.js. The way I see it, concat has two use cases: concatenating individual arrays, and concatenating an array of arrays.

For concatenating individual arrays the current way vs. proposed way would not be much of a change:

fn.concat(a, b)   // current
fn.concat([a, b]) // proposed

But concatenating an array of arrays would be much simpler and more readable:

fn.apply(fn.concat, collection) // current
fn.concat(collection)           // proposed

It would also be mappable without a partial application:

fn.map(fn.partial(fn.apply, fn.concat), collection) // current
fn.map(fn.concat, collection)                       // proposed

If you'd be willing to accept this change, I can submit a pull request.

Fn.js will not be perfect for every user. I have found it very helpful on some projects where they list similar projects. It helps see strengths and weakness of a library.

This issue is just to collect libraries with common areas to fn.js

For starters we have
Ramda
underscore
lodash

By default function should be passed as last argument.
Work out how to setup changelog

I think it would be beneficial to move the accumulator to be the second argument to fn.reduce:

fn.reduce(handler, accumulator, collection)

This would let us do things like:

var sum = fn.partial(fn.reduce, fn.op['+'], 0);
var product = fn.partial(fn.reduce, fn.op['*'], 1);

I think it makes sense to have the accumulator near the handler because it is almost always the identity value of the function being used to accumulate.

If you think this is a good idea, I'd be happy to submit a pull request with this change.

I'm envisioning something along the lines of:

expect( fn.op['+'](1, 2, 3, 4, 5) ).to.equal(15);
expect( fn.op['-'](8, 4, 1) ).to.equal(3);

The implementation would simply be reducing all the arguments.

I also feel that fn.op['>'] and fn.op['<'] would be incredibly useful see if a series of numbers are ascending or descending:

expect( fn.op['<'](1, 2) ).to.be.true;

// descending
var testScores = [88, 77, 66, 55]
expect ( fn.apply( fn.op['>'], testScores ) ).to.be.true;

I'd implement fn.op['>'] and fn.op['<'] with simple recursion.

What are your thoughts?

As I do not have the time to maintain fn.js as I should, I would like to propose two options. By the end of next month, I will decide which option to take depending on community outcry.

1. Deprecate fn.js in favor of Ramda. I've been using Ramda pretty regularly now and enjoy it. I would be content with deprecating and recommending it.
2. Transfer ownership to someone else who can commit more time to it.

Thoughts? I'd like to make my decision and take action prior to November 30, 2015.

is

var fullName = fn.curryRight(function ( firstName, middleName, lastName ) {
    return firstName + ' ' middleName + ' ' + lastName;
});

var smithName = fullName( 'Smith' );

smithName( 'Damon' )( 'Bill' ); // "Bill Damon Smith"
smithName( 'Jefferson', 'Bill' ); // "Bill Jefferson Clinton"
fullName( 'Cochran', 'Anne', 'Jenn' ); // "Jenn Anne Cochran"
fullName( 'Cochran', 'Anne' )( 'Jenn' ); // "Jenn Anne Cochran"

should be (second result)

var fullName = fn.curryRight(function ( firstName, middleName, lastName ) {
    return firstName + ' ' middleName + ' ' + lastName;
});

var smithName = fullName( 'Smith' );

smithName( 'Damon' )( 'Bill' ); // "Bill Damon Smith"
smithName( 'Jefferson', 'Bill' ); // "Bill Jefferson Smith"
fullName( 'Cochran', 'Anne', 'Jenn' ); // "Jenn Anne Cochran"
fullName( 'Cochran', 'Anne' )( 'Jenn' ); // "Jenn Anne Cochran"

I'm switching out the build process to Gulp. I also plan to add a few steps to the build process.

• Switch build tool to Gulp
• Versioning
• UMD building
• Bower generation
• npm and Bower publishing

https://github.com/fantasyland/fantasy-land produced great specifications for creating functors and monadic functionality. I had originally planned to bake this functionality into the core of fn.js, but had removed it at the time because of the size of scope. I would like to see this functionality make it back in, and I think the fantasy-land specification is a good basis for planned functionality, with the exception that fn.js methods should avoid mutating state on user-land objects, and containing state to monadic objects generated by the library.

The delay/delayFor test is looking to ensure that the delay was at least the provided timeout value (of 50). However it is possible (on my i5 os x 10.8.2 MBA, node 0.8.16) for the callback to trigger such that the two Date.now() calls to occur with only 49ms elapsed.

I think this test should be updated to reflect that the underlying setTimeout mechanism can have varying behaviour based on when the event loop gets a processor timeslice. Perhaps allowing values like 49 <= elapsed <= 51 to pass the test.
e.g.:

Project is small enough to not require gulp as a build step

After using fn.js for a bit now, I'm starting to wonder if I regret not making most methods auto-currying. I'm considering making this change for 1.0 and would welcome comments for or against based on your experience.

Hi there! Just discovered fn.js. Looks awesome!! :)

I noticed that fn.curry ends up currying the arguments from left to right. I'm wondering how you'd feel about currying right-to-left. Standard partial applications already go left to right, so I figure currying right to left would be more composable.

What are your thoughts?

This is library seems like a good start to push people to program their js more functionally. +1 to that. However, I think if you truly want to push people in that direction you should consider adding some classes like ConsList, Vector, etc.

var list = new ConsList([1,2,3]);

I'd be happy to start contributing some of theses classes.

What is the plan for browser support? Using defineProperty can help make these structures less likely to be mutated by evil.

Guys at Fantasy Land made a specification for Algebraic objects in JavaScript. https://github.com/fantasyland/fantasy-land

It helps a lot to understand how to organize objects so the library can act upon them, its also good that teaches functional programming concepts. However, they have no documentation for their modules. I would like to know if this library is compliant so I can read the concepts there and but use the functions over here.

Thanks!