roadmap?

[pasviegas]

Would be nice if you could share some roadmap or direction that you want to take the library, so it would be easier to contribute.

[DrBoolean]

Hey! I'd love contributions.

The goal was to provide some wrapper methods that made point free programming possible with fantasy land.

It got a little tricky when i didn't want to extend built-in's prototypes. That had bit me before when some lib somewhere did a "for in". So these instances crept into the library that probably shouldn't be there.

@robotlolita's https://github.com/folktale is what I'm rooting for as a fully functional environment in js. So the hope would be to compliment that or any other fantasy land library.

For this https://github.com/DrBoolean/lenses library, traversable and foldable (foldMap for sure) would be nice to have. I'd also love to support Alternative. I wonder though when to draw the line though. So far it's just the base level fantasy land spec.

Maybe a good start it to remove identity, const, and maybe and add some optional includes like traversable's functions.

What do you think?

[pasviegas]

I also think that using the built-in types might be a problem.

What I like about https://github.com/folktale is that it is modular and I can pick the most basic set if I want to.

If you ask me, what I am looking for is a library that provides a small and concise toolchain that allows functional programming dealing with abstract types and instead of concrete ones.

The desirable things would be:

Abstract Types

• Functor
• Applicative
• Monads
• Monoids
• MonadPlus
• Foldable
• Traversable

Functions

• compose
• filter (on abstract type)
• find (on abstract type)
• curry

Types (maybe in a different packages)

• Maybe
• Identity
• Either
• List
• Any
• All
• Future

Lenses would also be awesome, but I think you are right in keeping it in a different package.

I also don't know yet about immutable structures, David Nolen project https://github.com/swannodette/mori brings them to js, but I don't think they are extensible to comply with the List Type.

Sorry for the long post hehe.

[pasviegas]

Just to clarify, I don't exactly care about the actual type, I liked the way you exposed with Pointy =)

[robotlolita]

I've tried providing instances of fantasy-land's algebraic types for Mori (which is fairly awesome, btw!), but the operations don't preserve the types, as most operations use a lazy sequence type that doesn't preserve the semantics, and since putting it back in the right type would double the complexity I've decided to write my own persistent structures instead once I have some time, which will more likely after I finish my QuickCheck port :)

[pasviegas]

For that one possible alternative could be using the same trick Mori does and implementing the algebraic types in clojurescript and exporting together. :P

[DrBoolean]

I agree completely with you on what the library should provide.

For me, I wanted two things:

First, to be able to plug in any fantasy-land compliant object and be able to write code like:

compose(fmap(f), someFnThatReturnsAFunctor)

The second goal was to avoid extending built-in prototypes to avoid seeing things like:

console.log([1]) // [1, ap: function(){}, of: function(){}]

It appears it achieves the first goal. I made a quick example for @folktale's data.either https://gist.github.com/DrBoolean/8357229

But the second goal is dependent upon the built-in instances using the lookup table.

So my thinking for the roadmap here would be:

1. Remove const, identity, maybe, etc.
2. Create wrappers for traverse, sequence, mapM, foldMap, etc
3. Update applicative functions to fallback on monad instances if missing. Maybe do the same for traversable w/ fmapDefault.
4. Leave the array and function instances and maybe extend them for traversable and foldable? Come up with a different solution?

What do you think?

[DrBoolean]

One last thought. I'd been seeing output like:

console.log(Maybe(Sum(2))) // { val: {val: 2} }

If we provided a Show typeclass interface, we could use a "print" method to make output like: Maybe(Sum(2))

We could overwrite inspect for console.log to work in node environments, but that doesn't work in the browser.

Also, we might as well expose lodash's curry since it depends on it.

[robotlolita]

Show is just toString, but console.log prints the structure of the objects, rather than its toString representation (which is understandable, since built-in object's toString is usually not helpful).

[DrBoolean]

Ah, duh! Good call. So maybe an Inspectable interface with just the inspect method?

That could just be:

var inspect = function(x) {
  return x.inspect ? x.inspect() : x;
};

Nothing.prototype.inspect = function() {
  return "Nothing()";
}
Just.prototype.inspect = function(f) {
  return "Just("+inspect(this.val)+")";
}

console.log(Just(Just(2))) // Just(Just(2))

But then we'd need a log helper function for the browser. I find that extremely useful in composition anyhow.

var log = function(x){ console.log(inspect(x)); return x; }
var test = compose(toUpperCase, log, Maybe, first)
test("hello")
//=>  Just("h")
=> Just("H")

Maybe this is a little much, but I'm liking it...

[pasviegas]

Yeah, I actually ended up doing the same while doing some tests here.

I don't think we need an interface for that, because anyways for javascript wouldn't make much difference =P

[pasviegas]

As you said I agree completely that we should focus on this:

1. Remove const, identity, maybe, etc. and create them in separate modules.
2. Create wrappers for traverse, sequence, mapM, foldMap, etc

;)

[DrBoolean]

I'm working on fantasy-constant so i can get it out of here and my lens lib will still work. Fantasy-identities was plug and play so no need for "identity". I'll be on that for the day so anything's up for grabs.

[leoasis]

This is awesome work, I'll definitely start playing with this and see how I can contribute!

[DrBoolean]

Sweet!