handling of duplicate keys in Object$prototype$concat about sanctuary-type-classes HOT 9 CLOSED

In haskell mappend of Map is "left-biased" in JS we have similar function Object.assign (R.merge has similar semantics) which are right biased, so I think is better to stick with what we have as it's more intuitive to JS developer.

from sanctuary-type-classes.

Let's stick with the current behaviour for the time being. As it's not clear that one approach is better than the other it's best to leave things as they are. We can revisit this issue if new information comes to light.

from sanctuary-type-classes.

but it is more aligned with Object.assign

Object.assign({ a: 1 }, { a: 2 }) // { a: 2 }

from sanctuary-type-classes.

It depends on whether you want

Z.concat({x: 1, y: 1}, {y: 2, z: 2}) === ({x: 1, y: 1})['fantasy-land/concat']({y: 2, z: 2})

or not.

It's somewhat related to the ordering disputes in sanctuary-js/sanctuary#239

from sanctuary-type-classes.

Would you like to chime in here, @JAForbes?

from sanctuary-type-classes.

here are couple snippets from index.js.

in this ones appropriate FL method is invoked on last argument (data last)

function reduce(f, x, foldable) {
  return Foldable.methods.reduce(foldable)(f, x);
}

function map(f, functor) {
    return Functor.methods.map(functor)(f);
}

function chain(f, chain_) {
  return Chain.methods.chain(chain_)(f);
}

In case of this ones it's hard to say that which one is data as both of them are dataish.

function concat(x, y) {
    return Semigroup.methods.concat(x)(y);
}

function equals(x, y) {
  ... Setoid.methods.equals(x)(y) ...
}

function alt(x, y) {
  return Alt.methods.alt(x)(y);
}

function of(typeRep, x) {
  return Applicative.methods.of(typeRep)(x);
}

So the issue is not in Object$prototype$concat, but in dispatching part of concat, equals and etc.
(Ii think it's fine as otherwise it's a bit unintuitive)

from sanctuary-type-classes.

@gabejohnson, I'm not at all concerned with the relationship between the order of arguments to a Z function and the order of arguments to the corresponding Fantasy Land method. The API provided by Z functions is relevant to everyone in the Sanctuary community, whereas the details of the Fantasy Land methods are only relevant to authors of algebraic data types.

So the issue is not in Object$prototype$concat, but in dispatching part of concat, equals and etc.

I don't think that's correct. See #49.

from sanctuary-type-classes.

I'd personally prefer the left argument for this function and several others (including S.alt ).

But I think that's because I often use merge to overwrite existing state. E.g pre-processing data before a server call, or update state in a Redux/Elm reducer/update fn.

But I can also see someone else wanting concat for objects to act like "ensure this object at least has these values". And that's a valid use case too.

And this is why I bring up S.alt, you can use that function to do similar things.

Currently S.alt isn't convenient for setting up a default value if both args are Just.

// overwrite if the 2nd arg is Just
var defaultVal = S.alt( S.Just('default value') )

defaultVal( S.Just('desired value') )
//=> Just('default value')
// :(

The other day in gitter I was saying the current argument order isn't conducive for point free. But on reflection, its not conducive for point free for my specific use case 😄 . Both styles are useful in specific contexts and inconvenient in others.

I'd rather the entire library is consistent. So unless we're going to be left biased for other functions, I think right biased is ( unfortunately for me ) the way to go.

But if we did switch to left biased, would that change the behavior of e.g. Array$prototype$concat ? In my mind concat order seems related to the matter of key collision preference, it would seem odd to have one order for values, and another order for conflict resolution.

from sanctuary-type-classes.

You would need to use placeholder in Purescript too (or flip)

defaultVal = _ <|> (Just "bla")

from sanctuary-type-classes.