include sanctuary-def comparison in readme

[davidchambers]

At first glance this project seems to be quite similar to sanctuary-def. A summary of the differences between the two libraries would be useful. :)

[ivenmarquardt]

Gee! I didn't even know this repo. I know Sanctuary, of course. sanctuary-def seems indeed quite similar. How do you manage all these projects? That's incredible!

I have to take a closer look at it. I am curious how you solved particular problems. I am pretty sure we can learn from each other. It seems as if Berlin is becoming a hot-spot for typed Javascript.

Give me a little time to prepare some key points about the differences.

Anyway, nice to hear form you.

[davidchambers]

I am curious how you solved particular problems.

Likewise!

I am pretty sure we can learn from each other. It seems as if Berlin is becoming a hot-spot for typed Javascript.

Let's exchange ideas. Since we're both in Berlin we could do so in person. Contact me via email if you'd like to get together. :)

[ivenmarquardt]

Here are far too many key points. This was a piece of work. I didn't intend to write down so many!

I am biased of course - maybe you can check through them and complete things. I guess I store the comparison in a separate file and only link it in the Readme.

TL;DR

sanctuary-def is less strict than ftor but more mature. While sanctuary-def provides good interop (especially with Ramda), ftor is much more radical in its adaptation of Haskell idioms and sacrifices interop for the time being. Sanctuary has a strong focus on type classes and bounded polymorphism, whereas ftor focuses on parametric and row polymorphism along with Hindley-Milner like type unification.

Status

• sdef: stable
• ftor: experimental

Interop

• sdef: Fantasy Land, Ramda
• ftor: none (I'd like to support Static Land but require curried functions)

Polymorphism

• sdef: parametric and bounded polymorphism
• ftor: parametric, rank-2 and row polymorphism

Unification

e.g. is comp(f) immediately unified to the most general type?

• sdef: no
• ftor: yes

Type Hints

e.g. comp(inc) has the intermediate type (a -> Number) -> a -> Number or append([1,2,3]) has the intermediate type [Number] -> [Number]

• sdef: ?
• ftor: yes (accessable via symbol)

Pluggable Runtime Type Checker

• sdef: yes (through ?)
• ftor: yes (through proxy virtualization)

Time of Introspection

• sdef: as soon as argument is supplied
• ftor: as soon as argument is supplied

Currying

• sdef: curried and multi-argument functions
• ftor: only curried functions (pseudo multi-argumet functions are possible, though)

Verbose Error Messages

• sdef: yes
• ftor: yes (bugy though)

Named Intermediate Functions of Curried Function Sequences

e.g. add(2).name // "add"

• sdef: ?
• ftor: yes

Partial Application

• sdef: yes (__ placeholder)
• ftor: no (curried functions only)

Type-Safe ADTs (Sums of Product)

with check of case guarantee

• sdef: ?
• ftor: yes (through Scott encoding)

Records, Tuples

• sdef: yes
• ftor: yes

Homogeneous Array, Map

• sdef: yes
• ftor: yes

Restricted Type Coercion

whenever possible in quirky Javascript...

• sdef: yes
• ftor: yes

Immutability

• sdef: ?
• ftor: no (but restricted mutability, e.g. mutation must not change type)

Duck Typing

In a typed environment you should know your types, so...

• sdef: ?
• ftor: restricted (e.g. 0 in [1,2,3] type checks but "foo" in [1,2,3] throws)

[davidchambers]

Named Intermediate Functions of Curried Function Sequences

e.g. add(2).name // "add"

sdef: ? ftor: yes

The functions returned by sanctuary-def have inspect and toString methods. For example:

> S.add
add :: FiniteNumber -> FiniteNumber -> FiniteNumber

The same applies to the result of partially applying one of these functions. For example:

> S.add (2)
add(2) :: FiniteNumber -> FiniteNumber

The functions are anonymous in both cases.

[ivenmarquardt]

@davidchambers I had a short discussion with Aadit, who has been working on a Hindley-Milner type checker for quite some time and according to him ftor is a type validator (as opposed to a tpye checker), because it assumes correct types for given implementations, instead of inferring them. I think this applies to Sanctuary as well.

[davidchambers]

It's good to know the correct terminology. The term type checking may be used more broadly in the programming community than its formal definition permits. ;)