Solve RowToList#2945
Conversation
|
Looks good! What do you think about including the types along with the labels? |
|
Yeah, I'm not opposed. The two are equivalent in that we can use rowcons to look up the types. It'd probably be more convenient to have both though. In that case, what do you think about the names |
|
I was thinking class RowMap f xs ys | f xs -> ys
instance auto1 :: RowMap f () ()
instance auto2 :: (f a b, RowMap f r1 r2) => RowMap f (l :: a | r1) (l :: b | r2) |
|
Oh instead of two classes we can have the fundeps in both directions |
|
With the new bidirectional fundep, what would the instances look like if you wrote them out? Does the coverage condition hold in both directions? |
|
What I'm getting at is that a fundep doesn't just depend on the relation you're defining, but also how you define it, right? Like, numeric addition as a 3-way relation has the property that if you know two, you know the third, but in practice we define it by recursion on one or the other argument, so the coverage condition doesn't actually hold for one of the fundeps, I think. |
|
Ah yeah, because RowList doesn't have the ordering invariant it means multiple RowLists can compute the same rows. So the bidirectional fundep doesn't make sense. Thanks! |
|
I wasn't thinking about ordering so much, but that's true too, unless you require sorted lists. I was thinking more that you have to define the mapping by inspecting one argument or or other.
…Sent from my iPhone
On Jun 18, 2017, at 10:48 AM, Liam Goodacre ***@***.***> wrote:
Ah yeah, because RowList doesn't have the ordering invariant it means multiple RowLists can compute the same rows. So the bidirectional fundep doesn't make sense. Thanks!
I'll switch back to two classes when I get some time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
paf31
left a comment
There was a problem hiding this comment.
Looks great! Is it possible to add a test though?
|
Rebased on master. If I add a test now, it will either depend on my typelevel-prelude clone, or it will fail until we decide where to put the class. |
|
Thanks, looks great! |
|
A little test I did in the REPL, for reference: 👍 Looks really great! |
…2985) * Revert "Fix child decl ordering (#2984)" This reverts commit 7fdd39d. * Revert "Only build master and semver tags in Travis (#2982)" This reverts commit c41a7a4. * Revert "Include comments in child declarations in HTML docs (#2981)" This reverts commit ad6166f. * Revert "Solve RowToList (#2945)" This reverts commit 0e2d820. * Revert "Fix links to type operators in HTML docs (#2979)" This reverts commit 5fe26f2. * Revert "Re-evaluate REPL globs during :reload (#2978)" This reverts commit 50e1c68. * Revert "[purs ide] Collect data constructors (#2976)" This reverts commit c965f35. * Revert "Replace synonyms in instance constraints (#2973)" This reverts commit ee66e0d. * Revert "Require single-method instance declarations to be indented (#2965)" This reverts commit b3e470d.
Will add a test once purescript/purescript-typelevel-prelude#11 is merged.