gcanti / flow-static-land Goto Github PK

I just installed [email protected] and am getting the following errors from Flow (Flow version is 0.37.1):

node_modules/flow-static-land/lib/Aff.js.flow:97
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
                           ^^ E1. This type is incompatible with
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
            ^ some incompatible instantiation of `E2`

node_modules/flow-static-land/lib/Aff.js.flow:97
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
                           ^^ E1. This type is incompatible with
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
            ^ some incompatible instantiation of `E`

node_modules/flow-static-land/lib/Aff.js.flow:97
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
                               ^^ E2. This type is incompatible with
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
            ^ some incompatible instantiation of `E1`

node_modules/flow-static-land/src/Aff.js:97
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
                           ^^ E1. This type is incompatible with
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
            ^ some incompatible instantiation of `E2`

node_modules/flow-static-land/src/Aff.js:97
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
                           ^^ E1. This type is incompatible with
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
            ^ some incompatible instantiation of `E`

node_modules/flow-static-land/src/Aff.js:97
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
                               ^^ E2. This type is incompatible with
 97: export function chain<E1, E2, E: E1 & E2, A, B>(f: (a: A) => Aff<E1, B>, fa: Aff<E2, A>): Aff<E, B> {
            ^ some incompatible instantiation of `E1`


Found 6 errors

Let me know if I can provide any other info

https://github.com/rpominov/static-land/blob/master/docs/spec.md#plus

This plugin reports flow errors as ESLint errors, which useful for literally everyone who doesn't use nuclide.

Demo:

Note: In this demo, I am using atom with the packages 'linter' and 'linter-eslint'

Would a PR for updating the documentation, regarding this plugin, be welcome?

I'm trying get accustomed to this library, which I find awesome, but I think I hit a bug.

I want to sequence an arr of maybes to a maybe of an arr but it doesn't work the way I want. Here's a test case: https://gist.github.com/frontsideair/78b42850858f58105377f09f8e0ec792

I also write comparable code in Haskell, which seems to work the way I wanted:

Prelude> sequence [Just 3, Just 4, Just 5]
Just [3,4,5]
Prelude> sequence [Just 3, Just 4, Nothing]
Nothing

The problem may not be in traversable but one of the dependencies of traversable.

https://github.com/rpominov/static-land/blob/master/docs/spec.md#chainrec

Disclaimer: This is a general question and not a bug report.

This library implements most of the data type such as Maybe and Either using primitive values:

maybe.of(3) // <- 3!

Most of the (monad related) literature on the internet uses classes:

var Maybe = function(val) {
    this.__value = val;
};

Maybe.of = function(val) {
    return new Maybe(val);
};

var maybeOne = Maybe.of(1); // <- this is a Maybe instance

The advantage of classes is that can be chained very easily:

function getUserBanner(banners, user) {
    return Maybe.of(user)
        .map(prop('accountDetails'))
        .map(prop('address'))
        .map(prop('province'))
        .map(prop(R.__, banners));
}

Whereas in the case of this library, I'm forced to compose all my data types.

Don't get me wrong, I understand this is the same. It's just that I see the class approach as battery included whereas your approach needing... a little bit of help.

I found your approach intriguing, but I don't understand why I would use it over a class.

Would you mind sharing why you opted for this approach?

inj / prj are just identity functions at runtime, they could be stripped out by a babel plugin

The name of this package is really awkward to me. You have a project called fp-ts. What do you think about changing this project's name to something simple like fp-js?

Thoughts on currying by default a-la Haskell, PureScript, Elm?

Hello! I'm pretty new in fp, and I have some some misunderstanding how to resolve cases like this:

const load(/* ... */): Promise<AsyncData> => {
  const data: Maybe<Promise<AsyncData>> = maybe.map(
    loadAsyncData,
    someOtherMaybe    
  )
  
  return maybe.fromMaybe(
    Promise.reject(new Error(/* ... */)), // <-- causes "Uncaught (in promise) Error"
    data
  )
}

It throws "Uncaught (in promise) Error" to the console every time, because then data is just - I have no chance to handle promise error... It there something like this:

return maybe.fromMaybe(
    () => Promise.reject(new Error(/* ... */)), // <-- function instead of value
    data
  )

For example in scala -

maybe.getOrElse(new Error('...'))

argument will be executed only if maybe is nothing (call-by-name style (x: => Any))

This may be a n00b question, but what is the reason getSemigroup, getMonoid, _get_Setoid are implemented differently than map / Functor?

Monoid:

export function getSemigroup<A>(semigroup: Semigroup<A>): Semigroup<Maybe<A>> {
  return {
    concat(fx, fy) {
      const x = prj(fx)
      const y = prj(fy)
      if (x == null) {
        return fy
      }
      if (y == null) {
        return fx
      }
      return of(semigroup.concat(x, y))
    }
  }
}

Map / Functor

export function map<A, B>(f: (a: A) => B, fa: Maybe<A>): Maybe<B> {
  const a = prj(fa)
  return a == null ? Nothing : inj(f(a))
}

It seemed weird that we're not type checking for Monoid...making me wonder how to implement it differently or better understand why it's not possible.

Type Checks:

if (false) { // eslint-disable-line
  ({
    map,
    ap,
    of,
    chain,
    reduce,
    alt,
    pempty,
    extend
  }: Monad<IsMaybe> &
     Foldable<IsMaybe> &
     Alt<IsMaybe> &
     Plus<IsMaybe> &
     Alternative<IsMaybe> &
     Extend<IsMaybe>)
}

Proof of concept (borrowed from fp-ts)

// @flow

interface HKT<F, A> {
  __hkt: F,
  __hkta: A
}

interface Functor<F> {
  map<A, B>(f: (a: A) => B, fa: HKT<F, A>): HKT<F, B>
}

type URI = 'Option';

type HKTOption<A> = HKT<URI, A>;

class None {
  __hkt: URI
  __hkta: any
  map<B>(f: (a: any) => B): Option<B> {
    return ((none: any): Option<B>)
  }
  inspect(): string {
    return this.toString()
  }
  toString() {
    return 'None'
  }
}

class Some<A> {
  __hkt: URI
  __hkta: A
  value: A
  constructor(value: A) {
    this.value = value
  }
  map<B>(f: (a: A) => B): Option<B> {
    return some(f(this.value))
  }
  inspect(): string {
    return this.toString()
  }
  toString() {
    return `Some(${JSON.stringify(this.value)})`
  }
}

type Option<A> = None | Some<A>;

const none = new None()

function some<A>(a: A): Option<A> {
  return new Some(a)
}

export function map<A, B>(f: (a: A) => B, fa: HKTOption<A>): Option<B> {
  return ((fa: any): Option<A>).map(f)
}

const double = (n: number): number => n * 2
const length = (s: string): number => s.length

function lift<F, A, B>(functor: Functor<F>, f: (a: A) => B): (fa: HKT<F, A>) => HKT<F, B> {
  return fa => functor.map(f, fa)
}

const maybeDouble = lift({ map }, double)

console.log(maybeDouble(some(10))) // Some(20)

console.log(some(1).map(double)) // Some(2)
console.log(none.map(double)) // None
// console.log(some(1).map(length)) // error: number. This type is incompatible with the expected param type of string

Original library: http://julien-truffaut.github.io/Monocle/

• Fold
• Getter
• PSetter
• PTraversal
• POptional
• PPrism
• PLens
• PIso

I needed this today, Functor and Monad can be added too.

Related to #24.

As well as the getSemigroup method, one can also

export function concat<A>(semigroup: Semigroup<A>): (fx: Maybe<A>, fy: Maybe<A>) => Maybe<A> {
  return function concat(fx, fy) {
    const x = prj(fx)
    const y = prj(fy)
    if (x == null) {
      return fy
    }
    if (y == null) {
      return fx
    }
    return of(semigroup.concat(x, y))
  }
}

And type check with (<A>(a: Semigroup<A>) => ({ concat: concat(a) }: Semigroup(<Maybe<A>>))

I slightly prefer this API, but was wondering if you had strong feelings about it / reasons to avoid it

See static-land v1.0.0 release https://github.com/rpominov/static-land/releases/tag/v1.0.0

For consistency with the other files

Just a general question, how would one go about handling things like Node streams with this lib?

Hi everyone,

I don't know if you all are aware that flow added $Compose as a new utlity type.

I am opening this issue to discuss if it worth to refactor Fun/compose to use this new utility type, or if it would be better to leave it as it is to maintain backwards compatibility.

I would really appreciate to hear your thoughts, thanks!

Not coming from a Purescript background, it'd be super useful to see how to use 'Canceler' to invalidate a long-running computations.

I'm having a hard time understanding what is going while looking through source. If you have time—thanks!

export interface Pointed<F> extends Functor<F> {
  of<A>(a: A): HKT<F, A>
}

export interface Copointed<F> extends Functor<F> {
  extract<A>(ca: HKT<F, A>): A
}

And then

export interface Applicative<F> extends Apply<F>, Pointed<F> {}

export interface Comonad<F> extends Functor<F>, Extend<F>, Copointed<F> {}

Hello, I'm trying to figure out what's going on here.

class IsSignal {}

export type SignalV<A> = {
  subscribe(subscriber: (a: A) => any): void,
  get(): A,
  set(a: A): void
};

export type Signal<A> = HKT<IsSignal, A>;

export function inj<A>(a: SignalV<A>): Signal<A> {
  return ((a: any): Signal<A>)
}

export function prj<A>(fa: Signal<A>): SignalV<A> {
  return ((fa: any): SignalV<A>)
}

I'll attempt to break down what's going on here based on my current understanding.

• Signal is the declared type for the Signal "class" we're creating, and will be an instance of Applicative, Functor, etc. (as seen later in the file)
• SignalV (for Signal variant?) is the type signature for the object with functions subscribe, get, etc. which has the unique behavior of this object
• inj (inject?) is an identity function that takes an object of type SignalV and casts it to a Signal for typechecking purposes
• prj (project?) is an identity function that takes an object of type Signal and casts it to a SignalV for typechecking purposes

I'm assuming the separate Signal and SignalV types as well as the need for inj and prj functions are all code acrobatics to get around Flow's limitations for the purposes of the typechecking involved. You're faking polymorphism using variant types because Flow's type system does not allow polymorphic types that are not classes of the same structural shape. In the case of a call to inj the type Signal is present on the value returned, and vice versa for prj. Is this correct?

It seems like flipping between variants like this is a lot of mental complexity where a more direct solution could be possible. Would you care to comment on whether it might be possible to make this less boilerplate-y for creating new types like this?

Finally, is there a reason why map, of, etc can't be static members of the Signal class? It seems like there are really multiple things in play here: a Signal type which is used to characterize what these instances of map, of, and so on are valid for, while SignalV represents the actual data structure that they work for.

I'm trying to find a solution that lets one implement these patterns as non-members without having to declare variants for each class, I'll let you know if I find anything in the meantime.

Thank you for the library! It's very impressive.
I'm trying to wrap my head around validation but struggling to do so. It does seem to be similar to scalaz validation but I'm not sure how would I use it. Any chance for an example?
Thank you again

Not sure what the fix is (other than removing the .flowconfig file on a build step), but wanted to bring this to your attention.

Flow 0.32.0

Error:

This modules resolves to "<<PROJECT_ROOT>>/../assert/package.json", which is outside both your root directory and all of the entries in the [include] section of your .flowconfig. You should either add this directory to the [include] section of your .flowconfig, move your .flowconfig file higher in the project directory tree, or move this package under your Flow root directory.

Files:
test.zip

Read up on something similar here: facebook/flow#1891

Before removing .flowconfig in /node_modules/flow-static-land/

After removing .flowconfig in /node_modules/flow-static-land/

eg: task.js's require still refer to ..src so you get errors bc those are still in es6 modules