Rewrite #41

rpominov · 2017-04-15T14:47:59Z

Fixes #32
Fixes #34
Fixes #9

polytypic · 2017-04-15T16:08:44Z

docs/spec.md

@@ -113,20 +96,30 @@ For example:
 - Two promises are equivalent when they yield equivalent values.
 - Two functions are equivalent if they yield equivalent outputs for equivalent inputs.

+Note that these examples are not universal, in some cases differnet


s/differnet/different/

dead-claudia

Appologies for the splattering of comments, but I thought I'd go through the spec and offer a few suggestions, primarily in how the types are presented in code.

dead-claudia · 2017-04-15T20:53:32Z

README.md

-Specification for common algebraic types in JavaScript
-based on [Fantasy Land](https://github.com/fantasyland/fantasy-land).
+Specification for common algebraic structures in JavaScript
+based on [fantasy-land](https://github.com/fantasyland/fantasy-land).


The spec's name is actually spelt "Fantasy Land".

Yeah, I'm going back and forth with this. I like how lower case "static-land" looks (except in titles), but if I use lower case "static-land" then "Fantasy Land" next to it looks off.

dead-claudia · 2017-04-15T20:54:12Z

README.md


-In Static Land a type is just a collection of static functions, and instances
+In static-land we use static functions, and instances


In static-land, we use ...

Note the added comma.

dead-claudia · 2017-04-15T20:56:16Z

README.md


-Simply expose some [Type Objects](docs/spec.md#type) that work with types that your library provides or with types defined in another library or with native types like Array.
+Simply expose some [module](docs/spec.md#module) that work with types that your library provides or with types defined in another library or with native types like Array.


Simply expose ~~some~~ a module ...

Note the edit.

dead-claudia · 2017-04-15T20:58:06Z

docs/spec.md

@@ -1,104 +1,87 @@
 # Static Land Specification


You should either change this to "static-land specification" or change all the instances of "static-land" elsewhere to "Static Land", for consistency. Otherwise, it looks very off.

dead-claudia · 2017-04-15T21:06:31Z

docs/spec.md

@@ -1,104 +1,87 @@
 # Static Land Specification

-This is a specification for common algebraic types in JavaScript based on
-[Fantasy Land Specification](https://github.com/fantasyland/fantasy-land).
+This specification describes JavaScript interfaces and laws


Try something like this:

This specification describes a set of JavaScript interfaces and algebraic laws that are common in some other functional languages like Haskell.

I feel this could also be improved, but I think you might see what I'm getting at.

dead-claudia · 2017-04-15T22:05:56Z

docs/spec.md

+Foldable<T> {
+  reduce: ((a, b) => a, a, T<b>) => a
+}
+```


Maybe this?

interface Foldable<T<*>> { reduce: ((a, b) => a, a, T) => a; }

dead-claudia · 2017-04-15T22:06:31Z

docs/spec.md

+Extend<T> {
+  extend: (T<a> => b, T<a>) => T<b>
+}
+```


Maybe this?

interface Extend<T<*>> { extend: (T<a> => b, T<a>) => T; }

dead-claudia · 2017-04-15T22:07:19Z

docs/spec.md


-#### Methods
+```js


Maybe this?

interface Comonad<T<*>> extends Functor<T>, Extract<T> { extract: (T<a>) => a; }

dead-claudia · 2017-04-15T22:09:24Z

docs/spec.md


-#### Methods
+In the following signature `Applicative<U>` means that a value must
+not only match `Applicative` signature, but also fully support `Applicative` algebra.


How about this? Probably not optimal, but it's a little more specific, and ties to my suggestion below.

In the following signature, U<*> extends Applicative means that values of that type must be modules that both implement the Applicative signature and follow its laws. U itself represents the type of such values.

dead-claudia · 2017-04-15T22:13:21Z

docs/spec.md

+Traversable<T> {
+  traverse: (Applicative<U>, a => U<b>, T<a>) => U<T<b>>
+}
+```


Maybe this?

interface Traversable<T<*>, U<*> extends Applicative> extends Functor<T>, Foldable<T> { traverse: (U, a => U, T<a>) => U<T>; }

Here U is a function level variable, we don't want to make it signature level variable. There is an important distinction:

Also notice that signature level type variables are fixed for a module, while a function level variable can be substituted with a different concrete type in each function application. In other words we must choose what T stands for when we create a module, and we must choose what a stands for only when we apply baz to some value.

Although maybe U should be lower case then 🤔

Then this?

interface Traversable<T<*>> extends Functor<T>, Foldable<T> { traverse: <U<*> extends Applicative>(U, a => U, T<a>) => U<T>; }

This doesn't seem right. U<*> extends Applicative suggest that U is a module, then a => U and U<T> are wrong, these functions are not returning modules.

To clarify, in my current version U is a type like Array, e.g. if second argument of traverse() is a function that returns arrays, then first argument must be a module that supports Applicative with T=Array.

To clarify, I mean U represents the module, but U<a> is an instance. Similarly, Maybe is a type class, and Maybe a is an instance's type.

Yeah, I understand your point of view. I just don't think we should use a module name as a type name. If I have a module called Maybe, the values it's working with won't be automatically of types Maybe<number>, Maybe<boolean> etc. It could use arrays for example under the hood ([1] for some, and [] for nothing), so the values that module works with would be of family of types Array<something>. Or it could be working with instances of class Maybe {...} then, values would have types Maybe<something> after all, but that name "Maybe" will refer to a class name, not to a module name.

This way of thinking seems more correct to what we're dealing with. Modules are not types. In principal some methods of a module can work with different types from another. Or we even may have an algebra which signature parametrized with two or more types.

Btw, current version of the spec calls modules "types", that was a mistake, and to fix it was the initial inspiration for this rewrite 🙃

I'm now starting to see why you use Applicative instead - the value's type would be Maybe<T>, while the module type would be Monad<Maybe<T>>. So I'll go with it.

Well because in notation that I made up Applicative in that position means "a module that matches Applicative signature for type U" :)

Check out section that describes the notation.

Yeah. I caught that, but I didn't read it as such. I'd read it as "a module that implements Applicative for type U".

rpominov · 2017-04-18T12:29:09Z

Ok, I'm going to merge this. Thanks for help @isiahmeadows and @polytypic !

rewrite

fa893d7

rpominov mentioned this pull request Apr 15, 2017

Better term for what we currently call Type or Type Dictionary #32

Closed

minor

8075389

polytypic reviewed Apr 15, 2017

View reviewed changes

typo

17fef06

dead-claudia reviewed Apr 15, 2017

View reviewed changes

rpominov added 8 commits April 16, 2017 10:40

fantasy/staic-land -> Fantasy/Static Land

5c6cca8

fix grammar, improve wording

7706907

missing T

8809fa2

acknowledge that c is parametric in chainRec

a8402ba

better clarification of Traversable signature

73612e3

coma

46b33eb

minor

81696fe

minor

33feb5a

rpominov merged commit ecb743f into master Apr 18, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rewrite #41

Rewrite #41

rpominov commented Apr 15, 2017 •

edited

Loading

polytypic Apr 15, 2017

rpominov Apr 15, 2017

dead-claudia left a comment

dead-claudia Apr 15, 2017

rpominov Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

dead-claudia Apr 15, 2017

rpominov Apr 15, 2017

dead-claudia Apr 16, 2017

rpominov Apr 16, 2017

dead-claudia Apr 16, 2017

rpominov Apr 17, 2017 •

edited

Loading

rpominov Apr 17, 2017 •

edited

Loading

dead-claudia Apr 17, 2017

rpominov Apr 17, 2017

dead-claudia Apr 17, 2017

rpominov commented Apr 18, 2017


		In Static Land a type is just a collection of static functions, and instances
		In static-land we use static functions, and instances


		Simply expose some [Type Objects](docs/spec.md#type) that work with types that your library provides or with types defined in another library or with native types like Array.
		Simply expose some [module](docs/spec.md#module) that work with types that your library provides or with types defined in another library or with native types like Array.


		#### Methods
		```js

Rewrite #41

Rewrite #41

Conversation

rpominov commented Apr 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dead-claudia left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rpominov Apr 17, 2017 • edited Loading

Choose a reason for hiding this comment

rpominov Apr 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rpominov commented Apr 18, 2017

rpominov commented Apr 15, 2017 •

edited

Loading

rpominov Apr 17, 2017 •

edited

Loading

rpominov Apr 17, 2017 •

edited

Loading