Sum tags map

[wclr]

This PR adds typed tag mapping feature discussed earlier.

sum'   
  { "Foo": "foolery"
  , "Bar": "bar"
  , "Baz": "bazinga"
  }
  { "Foo": ...
   , "Bar": ...
   , "Baz": ..
  }

I wonder what do you think about it, API and implementation. @garyb @m-bock

[m-bock]

How about this API:

sum' 
  { "Foo": { label: "foolery", codec: ... }
  , "Bar": { label: "bar", codec: ... }
  , "Baz": { label: "bazinga", codec: ... }
  }

Maybe in the future there may be more options "per case", then this could be easily extended.

[m-bock]

How about defining the class without method if the only thing it does is unsafe coerce?
This operation could be done once in sumWith where its called.

Another thought: You could avoid the unsafeCoerce if you add the Homogeneous constraint and then use: https://pursuit.purescript.org/packages/purescript-foreign-object/4.1.0/docs/Foreign.Object#v:fromHomogeneous

[wclr]

Potentially we could construct this Object safely, also we could use Map, Object and unsafeCoerce just for performance reason. Object.fromHomogeneous is unsafeCoerce anyway, though if we add Homogeneous r String constraint we can use fromHomogeneous. I also thought about how this would work in the new codec-json lib, should we convert this mapping record to safely constructed Map String String or unsafely coerced JObject (for speed)?

[garyb]

I also thought about how this would work in the new codec-json lib, should we convert this mapping record to safely constructed Map String String or unsafely coerced JObject (for speed)?

(I know this isn't necessarily the place to discuss it just here, but unsafeCoerce is not allowed in codec-json - we can implement something in the FFI to do the conversion and just have it return the input, so essentially unsafeCoerce, but using unsafeCoerce directly is a no-go. The purpose of JObject, JArray, etc. is to uncouple the representation of JSON from the representation the language uses for map-like and array-like things, so that in theory it's usable by other backends too where the shared representation may not be viable).

[wclr]

Well, really this tags' map is constructed once when the codec is declared, so I believe we can just use Map String String (if Object String is not available) here, it shouldn't have much impact with Map.lookup when converting tags.

[wclr]

How about this API:

sum' 
  { "Foo": { label: "foolery", codec: ... }
  , "Bar": { label: "bar", codec: ... }
  , "Baz": { label: "bazinga", codec: ... }
  }

Maybe in the future there may be more options "per case", then this could be easily extended.

I am not in favour of such complicated API without paticular (potential) need, what per case options else could be needed? I think typed tags mapping is supposed to be straightforward. TagsMap for tags, GCases (codecs) for values, I don't think there is a reason to compilcate more -)

Another thought it could be a more dynamic option, function instead of const String:

sum'   
  { "Foo": const "foolery"
  , "Bar": identity
  , "Baz": identity
  }

[m-bock]

@wclr Got your point. Maybe the API you suggests makes more sense.
Yes, a function String -> String I would prefer, too instead of just String.
Regarding the "unsafe coerce", I just suggest to only perform it at one place.

What about the name sum'? Can we find something more descriptive?

[wclr]

I'm not sure what would be a good descriptive naming heresumWithTagsWith -)? ~With is a good convention for passing options, ' reasons are more ambiguous, just another version. Currently I think it is ok in the context, sum is more commonly used for working with only values, sum' for working with tags and values, considering that needed API capabilities are covered.

I wonder if we can come up with a more appropriate variant.